{"id":112077,"date":"2023-12-08T15:10:14","date_gmt":"2023-12-08T13:10:14","guid":{"rendered":"https:\/\/prohoster.info\/blog\/novosti-interneta\/avtor-gnupg-osnoval-librepgp-fork-standarta-openpgp"},"modified":"2023-12-08T15:10:14","modified_gmt":"2023-12-08T13:10:14","slug":"avtor-gnupg-osnoval-librepgp-fork-standarta-openpgp","status":"publish","type":"post","link":"https:\/\/prohoster.info\/pt\/blog\/news\/avtor-gnupg-osnoval-librepgp-fork-standarta-openpgp","title":{"rendered":"O autor do GnuPG fundou o LibrePGP, um fork do padr\u00e3o OpenPGP","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
Werner Koch, principal desenvolvedor e criador do projeto GnuPG (GNU Privacy Guard), fundou o projeto LibrePGP, focado no desenvolvimento de uma especifica\u00e7\u00e3o atualizada, alternativa ao padr\u00e3o OpenPGP. O fork foi criado em resposta a mudan\u00e7as planejadas pelo grupo de trabalho IETF para a pr\u00f3xima atualiza\u00e7\u00e3o da especifica\u00e7\u00e3o OpenPGP (RFC-4880) e que foram vistas por Koch como duvidosas em termos de manter compatibilidade e garantir seguran\u00e7a. Os desenvolvedores que apoiaram o fork, dos projetos GnuPG, RNP (implementa\u00e7\u00e3o OpenPGP do Thunderbird) e Gpg4win, temem que as mudan\u00e7as propostas possam ser prejudiciais para as implementa\u00e7\u00f5es existentes de aplicativos baseados em OpenPGP, cujos usu\u00e1rios esperam estabilidade na especifica\u00e7\u00e3o a longo prazo e n\u00e3o est\u00e3o dispostos a aceitar mudan\u00e7as que comprometam a compatibilidade. <\/p>\n
O LibrePGP inclui melhorias \u00fateis, desenvolvidas nos \u00faltimos anos para uma futura vers\u00e3o da especifica\u00e7\u00e3o OpenPGP, mas exclui modifica\u00e7\u00f5es que impactam negativamente a compatibilidade. Por exemplo, em compara\u00e7\u00e3o com o padr\u00e3o atual RFC-4880, o LibrePGP adotou as seguintes funcionalidades: <\/p>\n
\n
Suporte ao algoritmo de criptografia Camellia (RFC-5581),\n
Extens\u00f5es ECC (Criptografia de Curva El\u00edptica) para OpenPGP (RFC-6637).\n
Suporte obrigat\u00f3rio a hashes SHA2-256 (SHA-1 e MD5 foram considerados n\u00e3o recomendados, e a possibilidade de desencriptar dados sem verifica\u00e7\u00e3o de integridade foi_CLASSIFIED como completamente obsoleta).\n
Aumento para 256 bits do tamanho do identificador (fingerprint).\n
Suporte ao esquema de assinaturas digitais EdDSA e curvas el\u00edpticas BrainpoolP256r1, BrainpoolP384r1, BrainpoolP512r1, Ed25519, Curve25519, Ed488 e X448.\n
Suporte ao algoritmo CRYSTALS-Kyber, resistente a ataques de computadores qu\u00e2nticos.\n
Suporte aos modos de criptografia autenticada OCB (Offset codebook mode).\n
Implementa\u00e7\u00e3o da quinta vers\u00e3o do formato de assinaturas digitais com prote\u00e7\u00e3o de metadados.\n
Suporte a subpacotes expandidos com assinaturas digitais. <\/ul>\n
Principais pontos de cr\u00edtica \u00e0 nova especifica\u00e7\u00e3o OpenPGP: <\/p>\n
\n
O grupo de trabalho IETF, em vez de uma atualiza\u00e7\u00e3o incremental gradual da especifica\u00e7\u00e3o, tentou reinventar o padr\u00e3o, realizando mudan\u00e7as significativas que comprometem a compatibilidade.\n
Imposi\u00e7\u00e3o de suporte ao modo de criptografia sim\u00e9trica GCM (Galois\/Counter Mode), que \u00e9 dif\u00edcil de implementar corretamente, desconsiderando o modo OCB (Offset Codebook Mode), cujas patentes expiraram h\u00e1 alguns anos.\n
Adi\u00e7\u00e3o de pacotes opcionais com preenchimento aleat\u00f3rio adicional para prote\u00e7\u00e3o contra an\u00e1lise de tr\u00e1fego. De acordo com os criadores do LibrePGP, tais pacotes com preenchimento aleat\u00f3rio inicial n\u00e3o verific\u00e1vel criam uma amea\u00e7a de uso para a cria\u00e7\u00e3o de canais ocultos de transmiss\u00e3o de dados e para a evas\u00e3o de sistemas de preven\u00e7\u00e3o de vazamento de dados. Anteriormente, a ideia de incluir preenchimento adicional foi rejeitada por ser um assunto n\u00e3o do n\u00edvel de criptografia, mas do n\u00edvel de aplicativo.\n
Aplica\u00e7\u00e3o de um esquema de criptografia ECDH modificado (mudan\u00e7a no formato OID), em vez do uso da vers\u00e3o j\u00e1 descrita no RFC-6637 e implementada no PGP e GnuPG.\n
Remo\u00e7\u00e3o de algumas funcionalidades pr\u00e1ticas, como o m\u00e9todo cl\u00e1ssico de revoga\u00e7\u00e3o de chaves, a flag «m» para marcar dados MIME e a flag «t» para separar dados textuais de bin\u00e1rios (a flag «t» foi substitu\u00edda pela flag «u» para texto em codifica\u00e7\u00e3o UTF-8).\n
Recusa em incluir no novo formato de assinaturas a prote\u00e7\u00e3o dos metadados do arquivo assinado (por exemplo, \u00e9 poss\u00edvel alterar o nome do arquivo sem invalidar a assinatura).\n
Capacidade duvidosa de adicionar «salt» \u00e0s assinaturas (Salted signature) para aumentar a prote\u00e7\u00e3o contra ataques de colis\u00e3o com um prefixo espec\u00edfico. O valor com sal pode ser usado como um canal oculto n\u00e3o desativ\u00e1vel para transmitir 32 bytes de dados na assinatura.\n
Deslocamento do padr\u00e3o em dire\u00e7\u00e3o ao uso prim\u00e1rio para comunica\u00e7\u00e3o online, ignorando as necessidades de armazenamento de dados a longo prazo. <\/ul>\n
Os defensores do OpenPGP j\u00e1 publicaram cr\u00edticas \u00e0 cr\u00edtica. Como resultado, se um compromisso n\u00e3o for alcan\u00e7ado, a divis\u00e3o pode levar ao aumento das incompatibilidades nas implementa\u00e7\u00f5es do OpenPGP\/LibrePGP. Para solucionar parcialmente esse problema, os desenvolvedores do OpenPGP fixaram a quinta vers\u00e3o do formato de assinaturas de modo compat\u00edvel com o LibrePGP e come\u00e7aram a trabalhar na sexta vers\u00e3o. \n Fonte: opennet.ru<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"