Werner Koch, principal desenvolvedor e criador do projeto GnuPG (GNU Privacy Guard), fundou o projeto LibrePGP, focado no desenvolvimento de uma especificação atualizada, alternativa ao padrão OpenPGP. O fork foi criado em resposta a mudanças planejadas pelo grupo de trabalho IETF para a próxima atualização da especificação OpenPGP (RFC-4880) e que foram vistas por Koch como duvidosas em termos de manter compatibilidade e garantir segurança. Os desenvolvedores que apoiaram o fork, dos projetos GnuPG, RNP (implementação OpenPGP do Thunderbird) e Gpg4win, temem que as mudanças propostas possam ser prejudiciais para as implementações existentes de aplicativos baseados em OpenPGP, cujos usuários esperam estabilidade na especificação a longo prazo e não estão dispostos a aceitar mudanças que comprometam a compatibilidade.
O LibrePGP inclui melhorias úteis, desenvolvidas nos últimos anos para uma futura versão da especificação OpenPGP, mas exclui modificações que impactam negativamente a compatibilidade. Por exemplo, em comparação com o padrão atual RFC-4880, o LibrePGP adotou as seguintes funcionalidades:
- Suporte ao algoritmo de criptografia Camellia (RFC-5581),
- Extensões ECC (Criptografia de Curva Elíptica) para OpenPGP (RFC-6637).
- Suporte obrigatório a hashes SHA2-256 (SHA-1 e MD5 foram considerados não recomendados, e a possibilidade de desencriptar dados sem verificação de integridade foi_CLASSIFIED como completamente obsoleta).
- Aumento para 256 bits do tamanho do identificador (fingerprint).
- Suporte ao esquema de assinaturas digitais EdDSA e curvas elípticas BrainpoolP256r1, BrainpoolP384r1, BrainpoolP512r1, Ed25519, Curve25519, Ed488 e X448.
- Suporte ao algoritmo CRYSTALS-Kyber, resistente a ataques de computadores quânticos.
- Suporte aos modos de criptografia autenticada OCB (Offset codebook mode).
- Implementação da quinta versão do formato de assinaturas digitais com proteção de metadados.
- Suporte a subpacotes expandidos com assinaturas digitais.
Principais pontos de crítica à nova especificação OpenPGP:
- O grupo de trabalho IETF, em vez de uma atualização incremental gradual da especificação, tentou reinventar o padrão, realizando mudanças significativas que comprometem a compatibilidade.
- Imposição de suporte ao modo de criptografia simétrica GCM (Galois/Counter Mode), que é difícil de implementar corretamente, desconsiderando o modo OCB (Offset Codebook Mode), cujas patentes expiraram há alguns anos.
- Adição de pacotes opcionais com preenchimento aleatório adicional para proteção contra análise de tráfego. De acordo com os criadores do LibrePGP, tais pacotes com preenchimento aleatório inicial não verificável criam uma ameaça de uso para a criação de canais ocultos de transmissão de dados e para a evasão de sistemas de prevenção de vazamento de dados. Anteriormente, a ideia de incluir preenchimento adicional foi rejeitada por ser um assunto não do nível de criptografia, mas do nível de aplicativo.
- Aplicação de um esquema de criptografia ECDH modificado (mudança no formato OID), em vez do uso da versão já descrita no RFC-6637 e implementada no PGP e GnuPG.
- Remoção de algumas funcionalidades usadas na prática, como o método clássico de revogação de chaves, a flag 'm' para marcar dados MIME e a flag 't' para separar dados textuais de dados binários (a flag 't' foi substituída pela flag 'u' para texto na codificação UTF-8).
- Recusa em incluir no novo formato de assinaturas a proteção dos metadados do arquivo assinado (por exemplo, é possível alterar o nome do arquivo sem invalidar a assinatura).
- Dúvida sobre a possibilidade de adicionar 'sal' às assinaturas (Salted signature) para fortalecer a proteção contra ataques de colisão com um prefixo específico. O valor com sal pode ser usado como um canal oculto não desativável para transmitir 32 bytes de dados na assinatura.
- Deslocamento do padrão em direção ao uso primário para comunicação online, ignorando as necessidades de armazenamento de dados a longo prazo.
Os defensores do OpenPGP já publicaram críticas à crítica. Como resultado, se um compromisso não for alcançado, a divisão pode levar ao aumento das incompatibilidades nas implementações do OpenPGP/LibrePGP. Para solucionar parcialmente esse problema, os desenvolvedores do OpenPGP fixaram a quinta versão do formato de assinaturas de modo compatível com o LibrePGP e começaram a trabalhar na sexta versão.
Fonte: opennet.ru
