{"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\/novosti-interneta\/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, focalizzato 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 successivo aggiornamento della specifica OpenPGP (RFC-4880), che Koch ha percepito come problematiche in termini di mantenimento della compatibilit\u00e0 e sicurezza. Gli sviluppatori di supporto dei progetti GnuPG, RNP (implementazione di OpenPGP di Thunderbird) e Gpg4win temono che le modifiche previste possano essere dannose per le attuali implementazioni delle applicazioni basate su OpenPGP, i cui utenti si aspettano stabilit\u00e0 della specifica nel lungo periodo e non sono disposti a tollerare modifiche che compromettano la compatibilit\u00e0. <\/p>\n
LibrePGP include miglioramenti utili, sviluppati negli ultimi anni per la futura variante della specifica OpenPGP, ma esclude modifiche che potrebbero influire negativamente sulla compatibilit\u00e0. Ad esempio, rispetto allo standard attuale RFC-4880, in LibrePGP sono state adottate funzionalit\u00e0 come: <\/p>\n
\n
Supporto per l'algoritmo di crittografia 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 considerati non raccomandati, e la possibilit\u00e0 di decifrare i dati senza verifica dell'integrit\u00e0 \u00e8 completamente obsoleta).\n
Aumento della dimensione dell'impronta a 256 bit.\n
Supporto per lo schema di firma digitale EdDSA e curve ellittiche BrainpoolP256r1, BrainpoolP384r1, BrainpoolP512r1, Ed25519, Curve25519, Ed488 e X448.\n
Supporto per l'algoritmo CRYSTALS-Kyber, protetto contro attacchi su computer quantistici.\n
Supporto per le modalit\u00e0 di crittografia autenticata OCB (Offset codebook mode).\n
Implementazione della quinta versione del formato di firma digitale con protezione dei metadati.\n
Supporto per sotto-pacchetti estesi con firme digitali. <\/ul>\n
Principali elementi di critica della nuova specifica OpenPGP: <\/p>\n
\n
Il gruppo di lavoro IETF ha cercato di reinventare lo standard e apportare modifiche significative che compromettono la compatibilit\u00e0 anzich\u00e9 aggiornare gradualmente la specifica.\n
L'implementazione del supporto per la modalit\u00e0 di crittografia simmetrica GCM (Galois\/Counter Mode), che \u00e8 difficile da realizzare correttamente, escludendo 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 contro l'analisi del traffico. Secondo gli sviluppatori di LibrePGP, tali pacchetti con riempimento iniziale casuale non verificabile creano una minaccia di utilizzo per la creazione di canali nascosti di trasmissione dati e per eludere i sistemi di prevenzione delle perdite di dati. In passato, l'idea di includere il riempimento aggiuntivo era stata rifiutata, essendo considerata un aspetto a livello di applicazione piuttosto che di crittografia.\n
Utilizzo di uno schema di crittografia ECDH modificato (variazione del formato OID), invece di utilizzare la variante gi\u00e0 descritta nel 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 contrassegnare i dati MIME e il flag «t» per separare i dati di testo da quelli binari (il flag «t» \u00e8 stato sostituito dal 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
Possibilit\u00e0 dubbia di aggiungere «sale» alle firme (Salted signature) per rafforzare la protezione contro attacchi di collisione con un prefisso specificato. Il valore con sale pu\u00f2 essere utilizzato come un canale nascosto non disattivabile per trasmettere 32 byte di dati nella firma.\n
Spostamento dello standard verso l'uso principale per la comunicazione online, ignorando le esigenze di archiviazione a lungo termine dei dati. <\/ul>\n
I sostenitori di OpenPGP hanno gi\u00e0 pubblicato critiche alla critica. Di conseguenza, se non si trova un compromesso, la divisione pu\u00f2 portare a un aumento delle incompatibilit\u00e0 nelle implementazioni di OpenPGP\/LibrePGP. Parzialmente, per risolvere questo problema, i programmatori 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":"