Início / unix / Perguntas / 778279
Accepted
Harald
Asked: 2024-06-13 18:44:39 +0800 CST

Descriptografando vários arquivos mais rapidamente com gpg

  • 772

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:

  1. A inicialização 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.
  2. 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).

gpg

1 respostas

  1. Best Answer

    KDF são funções de derivação de chave que convertem uma senha em uma chave criptográfica. Ele precisa disso para descriptografar suas senhas. Para evitar que as senhas sejam adivinhadas, todas elas são intencionalmente lentas quando projetadas pela primeira vez.

    Geralmente, o GPG armazena em cache uma chave privada depois que você digita a senha ou a usa recentemente. No entanto, acho que só faz isso por chave. Se essas chaves forem realmente criptografadas com a mesma chave do KDF (e não incorporando informações exclusivas da própria chave em cada chamada do KDF), você poderá manter os resultados do KDF provavelmente apenas escrevendo seu próprio código do gcrypt up. A alternativa seria usar uma chave mestra no GPG que é desbloqueada com um único KDF e depois usada para descriptografar as chaves e senhas individuais enquanto está armazenada em cache.

    Não tenho ideia se algum deles funciona com o seu sistema.

    • 1

relate perguntas