{"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\/it\/blog\/news\/avtor-gnupg-osnoval-librepgp-fork-standarta-openpgp","title":{"rendered":"L'autore di GnuPG ha fondato LibrePGP, un fork dello standard OpenPGP","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
Werner Koch, sviluppatore principale e creatore del progetto GnuPG (GNU Privacy Guard), ha fondato il progetto LibrePGP, incentrato sullo sviluppo di una specifica aggiornata, alternativa allo standard OpenPGP. Il fork \u00e8 stato creato in risposta alle modifiche previste dal gruppo di lavoro IETF per il prossimo aggiornamento della specifica OpenPGP (RFC-4880), che sono state percepite da Koch come discutibili in termini di mantenimento della compatibilit\u00e0 e garanzia di sicurezza. Gli sviluppatori a sostegno del fork, provenienti dai progetti GnuPG, RNP (implementazione OpenPGP di Thunderbird) e Gpg4win, temono che le modifiche previste possano rivelarsi dannose per le implementazioni attuali delle applicazioni basate su OpenPGP, i cui utenti si aspettano stabilit\u00e0 nella specifica a lungo termine e non sono disposti ad accettare modifiche che compromettono la compatibilit\u00e0. <\/p>\n
LibrePGP include utili miglioramenti, sviluppati negli ultimi anni per una futura variante della specifica OpenPGP, ma esclude modifiche che influenzano negativamente la compatibilit\u00e0. Ad esempio, rispetto allo standard attuale RFC-4880, in LibrePGP sono state adottate le seguenti possibilit\u00e0: <\/p>\n
\n
Supporto per l'algoritmo di cifratura Camellia (RFC-5581),\n
Estensioni ECC (Elliptic Curve Cryptography) per OpenPGP (RFC-6637).\n
Supporto obbligatorio per gli hash SHA2-256 (SHA-1 e MD5 sono stati classificati come non raccomandati, e la possibilit\u00e0 di decifrare i dati senza verifica dell'integrit\u00e0 \u00e8 stata considerata completamente obsoleta).\n
Aumento a 256 bit della dimensione dell'impronta digitale (fingerprint).\n
Supporto per lo schema di firme digitali EdDSA e curve ellittiche BrainpoolP256r1, BrainpoolP384r1, BrainpoolP512r1, Ed25519, Curve25519, Ed488 e X448.\n
Supporto per l'algoritmo CRYSTALS-Kyber, resistente agli attacchi da parte di computer quantistici.\n
Supporto per le modalit\u00e0 di cifratura autenticata OCB (Offset codebook mode).\n
Implementazione della quinta versione del formato delle firme digitali con protezione dei metadati.\n
Supporto per i sottopacchetti estesi con firme digitali. <\/ul>\n
Principali elementi di critica alla nuova specifica OpenPGP: <\/p>\n
\n
Il gruppo di lavoro IETF, invece di un aggiornamento incrementale graduale della specifica, ha cercato di reinventare lo standard apportando modifiche significative che compromettono la compatibilit\u00e0.\n
Imposizione del supporto per la modalit\u00e0 di crittografia simmetrica GCM (Galois\/Counter Mode), che \u00e8 difficile da implementare correttamente, ignorando nel contempo la modalit\u00e0 OCB (Offset Codebook Mode), il cui brevetto \u00e8 scaduto diversi anni fa.\n
Aggiunta di pacchetti opzionali con riempimento casuale aggiuntivo per proteggere dall'analisi del traffico. Secondo i creatori di LibrePGP, tali pacchetti con riempimento casuale iniziale non verificabile creano una minaccia di utilizzo per la creazione di canali nascosti di trasmissione dei dati e per eludere i sistemi di prevenzione della fuga di dati. In precedenza, l'idea di includere riempimento aggiuntivo era stata scartata in quanto ritenuta appartenente al livello dell'applicazione e non a quello della crittografia.\n
Applicazione di uno schema di crittografia ECDH modificato (cambiamento del formato OID), invece di utilizzare la variante gi\u00e0 descritta in RFC-6637 e implementata in PGP e GnuPG.\n
Rimozione di alcune funzionalit\u00e0 pratiche, come il metodo classico di revoca delle chiavi, il flag «m» per marcare i dati MIME e il flag «t» per separare i dati testuali da quelli binari (al posto del flag «t» \u00e8 stato introdotto il flag «u» per il testo in codifica UTF-8).\n
Rifiuto di includere nel nuovo formato delle firme la protezione dei metadati del file firmato (ad esempio, \u00e8 possibile cambiare il nome del file senza violare la firma).\n
Opzione discutibile di aggiungere «sale» alle firme (Salted signature) per migliorare la protezione contro attacchi di collisione con un prefisso definito. Il valore con sale pu\u00f2 essere utilizzato come canale nascosto non disattivabile per trasmettere 32 byte di dati nella firma.\n
Spostamento dello standard verso un uso principale per la comunicazione online, ignorando le esigenze per la conservazione prolungata dei dati. <\/ul>\n
I sostenitori di OpenPGP hanno gi\u00e0 pubblicato una critica alla critica. Di conseguenza, se non si trover\u00e0 un compromesso, la frattura potrebbe portare a un aumento delle incompatibilit\u00e0 nelle implementazioni di OpenPGP\/LibrePGP. Parzialmente per risolvere questo problema, gli sviluppatori di OpenPGP hanno fissato la quinta versione del formato delle firme in modo compatibile con LibrePGP e hanno iniziato a lavorare sulla sesta versione. \n Fonte: opennet.ru<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"