Os engenheiros de criptografia estão gritando sobre as deficiências do PGP há décadas . Quando desenvolvedores comuns ouvem isso, ficam extremamente surpresos. Como, PGP não é bom? Por que, então, é aconselhável usá-lo? A resposta é: PGP não é realmente bom e nunca deve ser recomendado a ninguém. Ele deve desaparecer.

Como você verá em breve, o PGP tem muitos problemas. Se você não entrar em detalhes, o principal motivo é que o programa foi desenvolvido nos anos 90, antes do advento da criptografia moderna séria. Atualmente, nenhum engenheiro de criptografia competente desenvolverá um sistema dessa forma e não tolerará a maioria de seus defeitos em nenhum outro sistema. Criptografadores sérios basicamente abandonaram o PGP e não passam mais tempo nele (com algumas exceções notáveis ). Portanto, os problemas conhecidos no PGP permanecem sem solução por mais de dez anos.

Duas notas pequenas. Primeiro, o artigo foi escrito para engenheiros, e não para advogados e ativistas. Segundo, “PGP” pode significar muitas coisas, desde o padrão OpenPGP até a implementação de referência no GnuPG. Usamos o termo "PGP" para tudo isso.

Os problemas

Complexidade absurda

Por razões que ninguém entende agora, o PGP é baseado em pacotes. A mensagem PGP (no arquivo .asc) é um arquivo de pacotes digitados. Existem pelo menos oito maneiras diferentes de codificar o tamanho de um pacote, dependendo de você usar pacotes de formato "novo" ou "antigo". Pacotes do "novo formato", como o BER, têm um comprimento variável (tente escrever uma implementação PGP, e o padrão de codificação ASN.1 parecerá bom para você). Pacotes podem ter subpacotes. Algumas opções de pacotes se sobrepõem. O último ataque ao servidor de chaves se deve ao fato de que, devido a esse formato irresponsável, a análise de chave do GnuPG acidentalmente sai em tempo quadrático .

E isso é apenas uma codificação. O sistema real é muito mais complicado. Existem chaves e ficha. Identificadores de chave, servidores de chave e assinaturas de chave. As chaves são apenas para assinatura e somente para criptografia. Inúmeros chaveiros. Revogação de certificado. Três formatos de compactação diferentes. Que ainda não alcançamos o suporte de cartões inteligentes.

Design de canivete suíço

Se você se perder na floresta e ... eu não sei, por exemplo, você precisa cortar as lapelas nos jeans - sim, é muito conveniente que você tenha uma tesoura na faca. Mas, para um trabalho sério, ninguém usará essas tesouras regularmente.

Um canivete suíço faz muitas coisas e tudo está ruim. O PGP é uma ferramenta muito medíocre para assinar documentos; criptografa relativamente mal com senhas e funciona muito mal com chaves públicas. O PGP não é particularmente bom para transferências de arquivos seguras. Essa é uma maneira desajeitada de assinar pacotes. Não é muito bom para proteger backups. Essa é uma maneira extremamente perigosa de trocar mensagens seguras.

Na era do MC Hammer, quando o PGP apareceu, a "criptografia" era algo especial em si; havia uma ferramenta para enviar arquivos, backups, para criptografar e assinar arquivos. A criptografia moderna não funciona assim, precisamos de ferramentas especializadas. A criptografia para mensagens seguras é diferente da criptografia para fazer backup ou assinar pacotes.

Pântano de compatibilidade com versões anteriores

O PGP precede a criptografia moderna e está muito desatualizado nesse período. Se você tiver sorte, seu GnuPG, por padrão, terá uma chave RSA de 2048 bits, uma cifra CAST5 de 64 bits no CFB e uma soma de verificação OpenPGP MDC (sobre a qual mais adiante). Se a criptografia for feita com uma senha em vez de uma chave pública, o protocolo OpenPGP estabelecerá o algoritmo de geração de chave S2K para PGP. Para dizer o mínimo, essas não são as primitivas que um engenheiro de criptografia escolherá para um sistema moderno.

Aprendemos muito desde que o nerd Steve Urkel decorou o horário nobre da ABC. Aprendemos que os textos criptografados devem ser autenticados (e o modo CFB evitado), que as cifras de bloco de 64 bits são ruins, que o RSA não é perfeito, que uma combinação de compactação e criptografia é perigosa e que os KDFs devem ser gerados estritamente tanto no tempo quanto na memória.

Não importa o que o RFC do OpenPGP diz, você provavelmente não fará nada nesta lista se usar o PGP, e é impossível saber quando as recomendações começarão a ser implementadas. Pegue as cifras AEAD: o Sequoia PGP em Rust foi padronizado no modo AES-EAX AEAD. Isso é ótimo. Mas agora ninguém pode ler suas mensagens, porque a maioria das versões do PGP não sabe o que é o modo EAX, e isso não é muito legal. Em todo sistema de criptografia ruim, o resultado final é uma extensão RFC que suporta curvas elípticas ou AEAD, para que seus apoiadores possam gritar nos fóruns que suportam criptografia moderna. RFC não importa: apenas configurações reais. Inventamos a criptografia autenticada há 20 anos e o PGP se aposentará em breve; desculpas suficientes.

Ou você tem compatibilidade com o programa dos anos 90 ou possui boa criptografia; você não pode obter os dois .

Nasty UX

É difícil formulá-lo melhor do que Ted Unangst:

Alguns anos atrás, foi realizado um estudo de usabilidade do PGP, no qual um grupo de especialistas técnicos foi colocado em uma sala com um computador e solicitado a configurar o PGP. Duas horas depois, nenhum deles ainda havia respondido.

Se você precisar de seus próprios dados empíricos para confirmar isso, aqui está um experimento que você pode fazer: encontre um advogado que esteja longe de computadores e ajude-o a instalar o Signal por telefone. Ele provavelmente vai lidar sem histeria. Agora tente fazer isso com o PGP.

Segredos de longo prazo

O PGP pede que os usuários mantenham a chave raiz vinculada à sua identidade quase para sempre. A geração e troca de chaves é complicada com essas “partes assinantes da chave” e a “rede de confiança”, onde as chaves dependem de outras chaves.

Chaves de longo prazo são quase sempre desconfortáveis . Se você continuar usando a chave, ela se tornará pública. Do ponto de vista de um projeto de sistema competente, é necessário minimizar os danos e garantir que o usuário não hesite por um segundo ao pensar em gerar uma nova chave, se houver pelo menos algumas preocupações com a segurança da atual.

Os fãs do PGP responderão imediatamente: "É por isso que você precisa manter as chaves no Yubikey". Mas, de acordo com uma rápida estimativa aproximada, quase ninguém no mundo usa Yubikeys caros, e é improvável que isso mude no futuro (mal podemos implantar o U2F, e essas chaves são descartáveis). Não podemos aceitar sistemas de criptografia ruins apenas para tornar os nerds do Unix mais confortáveis ​​brincando com seus brinquedos.

Autenticação quebrada

Mais informações sobre as primitivas arcaicas do PGP: em 2000, o grupo de trabalho OpenPGP percebeu que era necessário autenticar texto criptografado e que as assinaturas PGP não. Portanto, o OpenPGP inventou o sistema MDC : as mensagens PGP com MDC anexam o texto sem formatação SHA-1 ao próprio texto sem formatação, que é então criptografado (como de costume) no modo CFB.

Se você está curioso para saber como o PGP lida com isso quando os sistemas modernos usam esquemas AEAD relativamente sofisticados (porque eles não podem simplesmente conectar o SHA-1 ao texto sem formatação), essa é uma boa pergunta. Como você descreveria esse desenho animado? O PGP MDC pode ser limpo de mensagens - ele é codificado de tal maneira que é bastante simples cortar os últimos 22 bytes do texto cifrado. Para manter a compatibilidade com as mensagens antigas não seguras, o PGP introduziu um novo tipo de pacote que sinaliza a necessidade de verificação do MDC. Se você usar o tipo errado, o MDC não será verificado. Mesmo se você o fizer, o novo formato de pacote SEIP estará bastante próximo do formato inseguro SE, o que poderia induzir o destinatário a reduzir a cifra; Trevor Perrin reduziu o SEIP para apenas 16 bits de segurança .

Por fim, mesmo que tudo dê certo, a implementação de referência PGP produzirá texto sem autenticação, mediante solicitação, mesmo que o MDC não corresponda .

Identidades inconsistentes

O PGP é um aplicativo, um conjunto de integrações com outros aplicativos, um formato de arquivo, uma rede social e uma subcultura.

O PGP apresenta o conceito de identidade criptográfica. Você cria uma chave, salva-a em um chaveiro, imprime sua impressão digital em um cartão de visita e publica-a no servidor de chaves. Você assina as chaves de outra pessoa. Eles, por sua vez, podem ou não confiar em suas assinaturas para verificar outras chaves. Algumas pessoas tentam se encontrar com outros usuários PGP pessoalmente para trocar chaves e se registrar com mais segurança nessa "rede confiável". Outros organizam as principais partes contratantes. Se você imaginar toda essa atividade, fica claro o quão difícil é para os fãs dedicados de PGP mudarem para novas tecnologias.

Mas todo esse sistema não funciona na prática. Nem uma rede confiável com assinaturas de chaves, nem servidores de chaves nem partes. As pessoas comuns confiarão em tudo que se parece com uma chave PGP, não importa de onde ela veio - como elas não podem confiar, mesmo que seja difícil para um especialista formular como avaliar a chave? Os especialistas não confiam nas chaves que eles não receberam pessoalmente. Todo mundo depende de serviços de distribuição de chaves centralizados. Os mecanismos de distribuição de chaves PGP são um circo.

Vazamentos de metadados

Por um segundo, esqueça o desastre por e-mail (voltaremos a isso mais tarde). O próprio PGP pode vazar metadados. No uso normal, as mensagens são diretamente associadas aos identificadores de chave associados ao identificador de usuário em toda a rede confiável PGP. Além disso, uma proporção bastante grande de usuários de PGP usa servidores-chave que emitem para a rede os usuários de PGP que trocam mensagens entre si.

Sem sigilo direto

Caso em questão: a criptografia para mensagens seguras requer sigilo à frente. Segredo direto significa que, se um invasor receber sua chave, ele ainda não poderá ler as mensagens anteriores. Na criptografia moderna, assumimos que o adversário escreve tudo no armazenamento infinito. Opositores do PGP incluem governos mundiais. Claro, alguns deles fazem isso. Contra adversários sérios, a criptografia de hackers sem sigilo direto é apenas uma questão de tempo.

Para garantir sigilo direto na prática, você geralmente mantém duas chaves secretas: uma chave de sessão de curto prazo e uma chave confiável de longo prazo. A chave da sessão é efêmera (geralmente um produto de troca DH) e a chave confiável a assina, para que a pessoa no meio não possa usar sua própria chave. Teoricamente, o sigilo direto pode ser alcançado com as ferramentas PGP. Claro, quase ninguém faz isso.

Chaves de machado

A chave pública de significação do OpenBSD é uma string Base64 curta o suficiente para caber no meio de uma frase em um email; uma chave privada que não é um formato de troca é apenas uma string. E a chave pública PGP é um gigantesco documento Base64; se você os usou com frequência, provavelmente já está acostumado a colá-los em um anexo em vez de colá-los em mensagens para não danificá-los. A chave signify é gerada pelo algoritmo Ed25519 avançado e PGP pelo RSA mais fraco.

Você pode pensar que isso não importa, mas é importante; ordens de magnitude mais pessoas usam o SSH e gerenciam chaves SSH do que o PGP. As chaves SSH são fáceis de manusear; PGP - não.

Reconciliação

O PGP suporta as curvas p ElGamal, RSA, NIST, Brainpool, Curve25519, SHA-1, SHA-2, RIPEMD160, IDEA, 3DES, CAST5, AES. Esta não é uma lista completa do que o PGP suporta.

Se nos últimos 20 anos aprendemos três coisas importantes sobre criptografia, pelo menos duas delas, é que a reconciliação e a compatibilidade são más. Como regra, as deficiências dos sistemas de criptografia aparecem nas implementações, em vez de primitivas, e a compatibilidade expansível com criptografia aumenta o número de implementações. Protocolos modernos, como o TLS 1.3, buscam se livrar da compatibilidade com arcaísmos como o RSA, em vez de adicioná-lo. Os sistemas mais novos suportam apenas um conjunto de primitivas e um número de versão simples. Se uma dessas primitivas falhar, você se livra dessa versão e descarta imediatamente todo o protocolo antigo.

Se não tivermos sorte e depois de 20 anos as pessoas ainda usarem o PGP, continuará sendo a única razão pela qual o padrão CAST5 será aplicado pelo menos em algum lugar. Não podemos dizer isso de forma mais clara, e precisamos repeti-lo várias vezes: ou você tem compatibilidade com o programa dos anos 90 ou possui boa criptografia; você não pode obter os dois.

Código da lixeira

A implementação padrão de fato do PGP é o GnuPG. Este programa não está muito bem escrito. Existe uma extensa base de código na linguagem C com duplicação de funcionalidade (por exemplo, na descrição de um ataque recente de negação de serviço na análise do SKS, é dito que ele possui vários analisadores de chave) com um longo histórico de CVE, variando de corrupção de memória a ataques criptográficos através de canais de terceiros. Às vezes era possível remover a autenticação das mensagens, mas o GnuPG não percebeu isso. Você poderia alimentar as chaves sem a impressão digital correta. Em 2018, a vulnerabilidade do Efail foi causada pelo fato de o GnuPG fornecer texto sem autenticação, mediante solicitação. GnuPG não é bom.

O GnuPG é a implementação de referência para PGP e a base para a maioria das outras ferramentas de integração de criptografia PGP. Ele não vai a lugar nenhum. Confiar no PGP significa confiar no GPG.

As respostas

Para convencer uma pessoa a desistir do PGP, é importante explicar a ele que o PGP não tem nada para substituir, e isso é normal . Uma ferramenta alternativa depende da tarefa.

Conversas

Use sinal. Ou Wire, WhatsApp ou outro mensageiro seguro com base no protocolo Signal.

Os mensageiros seguros modernos são projetados especificamente para mensagens. Eles usam handshakes de autenticação confidenciais, cancelamento de mensagens, catracas criptográficas que dão uma chave para cada troca de mensagens e, é claro, primitivas de criptografia modernas. Os mensageiros são trivialmente fáceis de usar, sem problemas com chaves e subchaves. Se você usa o Signal, obtém ainda mais: fica com um sistema tão paranóico ao salvar metadados privados de servidores que até encapsula as consultas de pesquisa Giphy para evitar ataques de análise de tráfego e, até recentemente, nem sequer suportava perfis de usuário.

Criptografia de email

Não faça isso.

O email não é seguro . Mesmo com o PGP, isso é texto sem formatação por padrão, ou seja, mesmo se você fizer tudo corretamente, algum destinatário completamente razoável da carta, fazendo coisas absolutamente razoáveis, necessariamente citará o texto sem formatação da sua mensagem criptografada para outra pessoa no CC (não conhecemos o usuário do email Correio PGP, que não se deparou com isso). Não há segredo direto no email do PGP. Os metadados do email, incluindo o assunto (que é literalmente o conteúdo da mensagem), são sempre transmitidos em texto não criptografado.

Se você precisar de outro motivo, leia o artigo sobre vulnerabilidade do Efail . A comunidade GnuPG, que não divulgou informações sobre o Efail , critica este artigo violentamente, mas foi aceito na Usenix Security (um dos principais centros acadêmicos de segurança de software) e na Black Hat USA (a principal conferência de segurança de software). Este é um dos melhores ataques criptográficos dos últimos cinco anos - e uma bomba bastante destrutiva contra o ecossistema PGP. Como você verá no artigo, S / MIME não é melhor.

Isso nunca será consertado. Para criar um email realmente seguro, você precisa encapsular outro protocolo por email (você ainda estará vulnerável a um ataque com análise de tráfego). Esse é exatamente o ponto, por que fingir?

Criptografar e-mail está clicando em problemas. Incentivar os usuários a criptografar e-mails se algo os ameaçar é negligência excepcional. Qualquer pessoa que fale sobre a segurança da comunicação por email com criptografia PGP coloca suas estranhas preferências acima da sua segurança.

Enviando arquivos

Use o buraco de minhoca mágico . Os clientes Wormhole usam autenticação de chave única com autenticação de senha (PAKE) para criptografar arquivos. É fácil (pelo menos para os nerds), seguro e divertido: todos para quem mostramos o "buraco da toupeira" imediatamente começaram a passar por ele todos os arquivos seguidos, como fazemos.

Alguém inicia imediatamente o instalador do Windows on Rust or Go, é um programa muito legal para não usá-lo.

Se você conversar com advogados, não com engenheiros, o Signal faz um ótimo trabalho de transferência de arquivos. Para relatar erros, publique o número do sinal, não a chave PGP.

Criptografia de backup

Use Tarsnap. Colin explicará como o Tarsnap é otimizado para proteger backups . Ou, de fato, use qualquer outra ferramenta de criptografia de backup; não será tão bom quanto o Tarsnap, mas ainda será melhor que o PGP.

Precisa de backups offline? Use criptografia de imagem de disco; está incorporado nas versões modernas do Windows, Linux e macOS. A criptografia completa do disco não é muito boa, mas faz um excelente trabalho nessa tarefa, e é mais simples e segura que o PGP.

Assinatura do pacote

Use Signify / Minisign. Ted Unangst vai lhe contar tudo . Esta ferramenta é usada para assinar pacotes no OpenBSD. É muito simples e aplica assinaturas modernas. Frank Denis Minisign (um dos desenvolvedores da libsodium) implementa o mesmo design no Windows e no macOS; Possui ligações para Go, Rust, Python, Javascript e .NET; É ainda compatível com o Signify.

Criptografia de dados do aplicativo

Use libsodium : esta é uma biblioteca universal com uma interface na qual é difícil cometer um erro e você não precisa de um binário para funcionar.

Criptografia de arquivo

Isso é realmente um problema. Se você possui / not / backup, / not / archive para armazenamento offline de longo prazo, / not / criptografia de arquivos para transferência e / not / criptografia de discos virtuais que você monta / desmonta conforme necessário, não há uma boa ferramenta para criptografar arquivos. Para outros fins, Filippo Walsorda está desenvolvendo uma ferramenta de idade , parece promissora, mas ainda não está pronta.

Espero que este seja um caso de uso bastante restrito. Trabalhamos no campo da segurança de software e processamos dados confidenciais, incluindo relatórios de erros (outro caso muito comum quando gritam “Precisamos de PGP!”), Mas quase nunca usamos o PGP.