Gerei uma nova chave GPG para uso pessoal usando o gpg --full-generate-keycomando no FreeBSD. O nome do sistema operacional onde a chave foi criada está armazenado na própria chave? Posso usar esta chave em uma máquina Debian como se ela tivesse sido criada no Debian?
O programa pass é um utilitário de linha de comando para armazenar senhas e dados extras de formato livre em pequenos arquivos criptografados com gpg. Ele fornece um subcomando grep em particular para encontrar senhas por meio de dados extras.
Mas esse subcomando grep é dolorosamente lento na minha máquina. Tenho quase 200 senhas armazenadas e internamente cada arquivo é descriptografado gpgassim (sem a timefrente, é claro):
% time gpg -d --quiet --yes --compress-algo=none --no-encrypt-to stackoverflow.gpg
the password output
user=0,000 sys=0,006 wall=0,382 (1,61)
O tempo de parede é de quase 0,4 segundos, o que equivale a cerca de 1 minuto para percorrer todos os arquivos.
O gpg-agentestá rodando e eu tenho esta versão:
gpg (GnuPG) 2.2.27
Duas suspeitas de por que isso é lento:
gpge a comunicação gpg-agentsão lentas, apoiadas pelo fato de que os tempos de usuário + sistema são pequenos em comparação.gpg-agenté lento, apoiado pelo fato de que após uma pass grepexecução seu tempo cumulativo de CPU aumenta em 60 segundos, correspondendo perfeitamente ao tempo total da execução completa.Juntos, ambos apontam para gpg-agent, embora eu não tenha ideia de por que o agente deveria ser tão lento. Com pseu vejo isso funcionando como
/bin/gpg-agent --sh --daemon
Alguém pode esclarecer se ~ 0,3 segundos de CPU é razoável para o agente por arquivo ou se há uma maneira de melhorar isso?
EDITAR: Outras descobertas
Anexando straceao agente, encontro isto:
20200 14:57:03.701648 getrusage(RUSAGE_SELF, {ru_utime={tv_sec=133, tv_usec=890780}, ru_stime={tv_sec=0, tv_usec=99975}, ...}) = 0
20200 14:57:03.701666 clock_gettime(CLOCK_PROCESS_CPUTIME_ID, {tv_sec=133, tv_nsec=990762100}) = 0
20200 14:57:04.063523 getpid() = 18035
onde temos 360ms entre clock_gettimea getpidchamada.
E com ltrace:
20472 15:04:55.035574 strlen("my-password-here") = 10
20472 15:04:55.035641 gcry_kdf_derive(0x7d884b82c008, 10, 19, 2) = 0
20472 15:04:55.394727 gcry_cipher_setkey(0x7d884b82cbc0, 0x7d884b82c030, 16, 0x7d884b83c000) = 0
Então gcry_kdf_deriveleva 360ms. Faça o que fizer, posso armazenar em cache o resultado por alguns segundos com alguma configuração. (... vai buscar o código fonte).
Preciso alterar a chave gpg originalmente usada para passar meu sistema para uma chave recém-gerada.
No entanto, quando sigo o conselho que encontrei neste tópico: https://unix.stackexchange.com/questions/226944/pass-and-gpg-no-public-key, as coisas não parecem funcionar como deveriam. O comando usado e sua saída ao tentar substituir a chave gpg original por uma chave gpg alternativa foi:
$ pass init -p .password-store GPG-id
mkdir: created directory '/home/naphelge/.password-store/.password-store'
Password store initialized for GPG-id (.password-store)
[master 8d65cea] Set GPG id to GPG-id (.password-store).
1 file changed, 1 insertion(+), 1 deletion(-)
Portanto, o comando parece estar apenas criando um novo diretório, .password-store no diretório original .password-store e criando um novo arquivo .gpg-id com o ID GPG da minha nova chave nele, e não procedendo à criptografação novamente todos os arquivos gpg em .password-store com a nova chave gpg.
O mesmo conselho é fornecido neste tópico em relação a um objetivo semelhante:https://askubuntu.com/questions/929307/how-to-change-the-gpg-key-of-the-pass-password-store
Percebi que no arquivo .gpg-id original no diretório ~/.password-store é a impressão digital da chave gpg original (sem espaços entre os (10) blocos de 4 dígitos) que é salva. Então tentei o mesmo comando acima, pass init -p .password-store FINGERPRINT-idusando a impressão digital da nova chave (sem espaços), além de tentar apenas especificar o endereço de e-mail associado à chave, para tentar iniciar a recriptografia dos arquivos gpg em .password- store com a nova chave gpg, mas sempre com o mesmo resultado.pass init -p .password-store [email protected]
Portanto, não tenho certeza, olhando outras postagens e a página de manual do pass, o que mais tentar fazer para que isso funcione. Qualquer sugestão ou conselho será apreciado. Obrigado.
Quando eu crio um par de chaves com gpg, ele armazena a chave secreta dentro de
~/.gnupg/private-keys-v1.d
Ele armazena a chave pública dentro de um arquivo de chaveiro - posso nomeá-lo ou ele usa o local padrão.
Se eu der uma olhada ( --list-public-keys e --list-secret-keys ) em minhas chaves públicas e secretas, posso ver qual par corresponde. A string/hash de 40 caracteres na saída é a mesma para ambos.
O arquivo da chave secreta é diferente desta string. Também tem 40 caracteres, mas é diferente.
Como descubro qual arquivo de chave secreta corresponde à minha chave pública?
Usando gpg 2.2.40 no Debian 12.
Estou executando o Ubuntu (via Regolith) e minha chave gpg é desbloqueada quando eu faço login. Estou executando várias operações de descriptografia em paralelo e notei que, se eu ultrapassar 7, gpg-agentvou "esquecer" que a chave já está desbloqueada e sou solicitado a fazer uma pinentry.
❯ gpg --version
gpg (GnuPG) 2.2.27
libgcrypt 1.10.1
Fiz um exemplo mínimo de trabalho para demonstrar isso em python.
Crie um arquivo de teste para descriptografar com: echo "something" | gpg --encrypt -o test.gpg. A execução gpg --decrypt test.gpgno shell não solicita a senha.
Usando o script abaixo, se WORKERNUMestiver definido abaixo de 8 (na minha máquina, mas defini-lo como 1, acho que deve funcionar para qualquer máquina), o script será descriptografado com satisfação, sem solicitar uma senha longa. Mas se eu aumentar para 8 ou mais, começo a receber solicitações para inserir minha senha, embora pareça que não é de todos os processos, apenas de alguns deles. A execução dos processos também obviamente começa a travar (presumo que eles estejam aguardando gpg-agent).
import subprocess
import multiprocessing as mp
import time
the_queue = mp.Queue()
WORKERNUM = 7
def worker_main(queue):
while True:
msg = queue.get(True)
print(time.time(), msg)
out = subprocess.run(["gpg", "--decrypt", "test.gpg"], capture_output=True)
print(msg, time.time(), out.stdout)
the_pool = mp.Pool(WORKERNUM, worker_main, (the_queue,))
counter = 0
while True:
counter += 1
the_queue.put(counter)
print(the_queue.qsize())
while the_queue.qsize() > 10:
time.sleep(0.1)
Tentei passar --batchpara o comando decrypt, mas isso não mudou nada. Estive pesquisando as páginas de manual para gpgver gpg-agentse há algo mencionado que possa estar relacionado a isso, mas não consegui encontrar nada. Eu tenho duas perguntas:
a) por que isso acontece eb) há algo que eu possa configurar para que, em vez de ter que descobrir o tamanho máximo do pool de processamento para evitar isso, gpglide com isso e não receba uma pinentry
Eu tenho uma licença com a qual estou assinando:
gpg --default-sig-expire "2024-02-14" --sign licence
Isto resulta em:
$ gpg --verify licence.gpg
gpg: Signature made Tue 13 Feb 2024 08:18:39 AM CET
gpg: using RSA key 1234567890ABCDEF1234567890ABCDEF
gpg: issuer "[email protected]"
gpg: Good signature from "Stewart <[email protected]>" [ultimate]
gpg: Signature expires Wed 14 Feb 2024 12:00:00 PM CET
Esse 12:00:00 PM CETé o meu problema. Geralmente vou almoçar nesse horário. Prefiro não receber ligações sobre sistemas off-line enquanto estou almoçando. É possível especificar o horário? Prefiro que expire em 13:00:00 PM CET.
--ask-sig-expiresolicita apenas o número de dias/semanas/anos:
$ gpg --ask-sig-expire --sign licence
Please specify how long the signature should be valid.
0 = signature does not expire
<n> = signature expires in n days
<n>w = signature expires in n weeks
<n>m = signature expires in n months
<n>y = signature expires in n years
Signature is valid for? (0)
ISO 8601 não parece compatível:
$ gpg --default-sig-expore "2024-02-14T13:00:00+02:00" --sign licence
gpg: '2024-02-14T13:00:00+02:00' is not a valid signature expiration
A man systemd.timeespecificação não parece suportada
$ gpg --default-sig-expire "2024-02-14 13:00:00" --sign licence
gpg: '2024-02-14 13:00:00' is not a valid signature expiration
A página de manual também não sugere que um momento seja possível:
--default-sig-expire
The default expiration time to use for signature expiration. Valid values
are "0" for no expiration, a number followed by the letter d (for days),
w (for weeks), m (for months), or y (for years) (for example "2m" for two
months, or "5y" for five years), or an absolute date in the form
YYYY-MM-DD. Defaults to "0".
A única solução que encontrei foi alterar o fuso horário do meu sistema para o próximo fuso horário a oeste de mim, assinar e definir o fuso horário do meu sistema de volta ao meu horário original.
$ sudo mv /etc/localtime{,.backup}
$ sudo ln -s /usr/share/zoneinfo/Europe/London /etc/localtime
$ gpg --default-sig-expire "2024-02-14" --sign licence
$ sudo mv /etc/localtime{.backup,}
$ gpg --verify licence.gpg
gpg: Signature made Tue 13 Feb 2024 08:18:39 AM CET
gpg: using RSA key 1234567890ABCDEF1234567890ABCDEF
gpg: issuer "[email protected]"
gpg: Good signature from "Stewart <[email protected]>" [ultimate]
gpg: Signature expires Wed 14 Feb 2024 01:00:05 PM CET
Estou tentando descriptografar um arquivo gpge para isso estou executando (com sucesso) o seguinte comando:
gpg --passphrase "12345678" --batch --yes --no-symkey-cache filename.tar.gz.gpg
O resultado da execução do comando é:
filename.tar.gz.gpgé descriptografado corretamente e é criado o arquivo filename.tar.gz;--passphrase "12345678" --batch --yes
a GUI para inserção da senha não está aberta.--quietAviso e opção GPGMas há um problema: a gpgexecução do comando anterior produz o seguinte aviso:
gpg: WARNING: no command supplied. Trying to guess what you mean ...
e a saída correta:
gpg: AES256 encrypted data
gpg: encrypted with 1 passphrase
Por este post , sei que pela opção --quieto comando anterior gpgnão produz nenhuma mensagem de saída.
O aviso parece dizer que no meu comando não está presente a solicitação para descriptografar o arquivo filename.tar.gz.gpg.
Então, minha pergunta é:
existe uma maneira de saber gpgse é necessário descriptografar um arquivo para evitar o aviso no command supplied.?
A caixa de diálogo de prompt da senha do GnuGPG expira após 60 segundos.
Como faço para aumentar o período de tempo limite?
(Só para esclarecer que não estou procurando default-cache-ttlapenas o tempo limite da própria caixa de diálogo da senha. Estou usando o GnuPG v2.2.23 no Fedora 33).
Usei a configuração yubikey do Dr. Duh há cerca de 20 dias sem problemas. Eu o examinei novamente ontem à noite em um Mac M1 com Brew e, quando criamos a chave de autenticação expirada, a lista de chaves mostra [AR] para a chave onde normalmente mostraria apenas [A] para autenticação. Eu consultei as man pages em gnu.org e enquanto posso ver os outros códigos (E,S,A) - não vejo nenhuma definição para R. O que é R?
Isso é algo parecido com o que vejo na etapa da lista (copiado do guia do Dr. Duh e alterado para adicionar o R):
$ gpg -K
/tmp.FLZC0xcM/pubring.kbx
-------------------------------------------------------------------------
sec rsa4096/0xFF3E7D88647EBCDB 2017-10-09 [C]
Key fingerprint = 011C E16B D45B 27A5 5BA8 776D FF3E 7D88 647E BCDB
uid Dr Duh <[email protected]>
ssb rsa4096/0xBECFA3C1AE191D15 2017-10-09 [S] [expires: 2018-10-09]
ssb rsa4096/0x5912A795E90DD2CF 2017-10-09 [E] [expires: 2018-10-09]
ssb rsa4096/0x3F29127E79649A3D 2017-10-09 [AR] [expires: 2018-10-09]
A seguinte mensagem de aviso aparece durante meu apt-get update && apt-get upgradeprocedimento no Linux Mint 21:
W: https://repo.skype.com/deb/dists/stable/InRelease: Key is stored in legacy trusted.gpg keyring (/etc/apt/trusted.gpg), see the DEPRECATION section in apt-key(8) for details.
Pesquisei na seção de download do Microsoft Skype sem mencionar absolutamente nada sobre suas chaves ou como gerenciá-las.
Existe uma solução para isso?