Werner Koch, principale sviluppatore e creatore del progetto GnuPG (GNU Privacy Guard), ha fondato il progetto LibrePGP, focalizzato sullo sviluppo di una specifica aggiornata come alternativa allo standard OpenPGP. Il fork è stato creato in risposta alle modifiche pianificate dal gruppo di lavoro IETF per il prossimo aggiornamento della specifica OpenPGP (RFC-4880), che Koch ha ritenuto discutibili dal punto di vista del mantenimento della compatibilità e della sicurezza. Gli sviluppatori dei progetti GnuPG, RNP (implementazione OpenPGP da Thunderbird) e Gpg4win che hanno supportato il fork temono che le modifiche pianificate possano danneggiare le implementazioni esistenti di applicazioni basate su OpenPGP, i cui utenti contano sulla stabilità della specifica a lungo termine e non sono disposti ad accettare modifiche che ne compromettano la compatibilità.
LibrePGP include utili miglioramenti sviluppati negli ultimi anni per la futura versione della specifica OpenPGP, ma esclude modifiche che influiscono negativamente sull'interoperabilità. Ad esempio, rispetto all'attuale standard RFC-4880, LibrePGP adotta funzionalità come:
- Supporto per l'algoritmo di crittografia Camellia (RFC-5581),
- Estensioni ECC (crittografia a curva ellittica) per OpenPGP (RFC-6637).
- Supporto obbligatorio per gli hash SHA2-256 (SHA-1 e MD5 sono obsoleti e la possibilità di decrittografare i dati senza verifica dell'integrità è completamente obsoleta).
- Aumentata la dimensione dell'impronta digitale a 256 bit.
- Supporto per lo schema di firma digitale EdDSA e per le curve ellittiche BrainpoolP256r1, BrainpoolP384r1, BrainpoolP512r1, Ed25519, Curve25519, Ed488 e X448.
- Supporto per l'algoritmo CRYSTALS-Kyber, resistente alla forza bruta sui computer quantistici.
- Supporto per le modalità di crittografia autenticate OCB (modalità Offset codebook).
- Implementazione della quinta versione del formato di firma digitale con protezione dei metadati.
- Supporto per sotto-pacchetti estesi con firme digitali.
Le principali critiche alla nuova specifica OpenPGP sono:
- Invece di aggiornare gradualmente le specifiche, il gruppo di lavoro IETF ha tentato di reinventare lo standard e di apportare modifiche significative e non interoperabili.
- Forzare il supporto per la modalità di crittografia simmetrica GCM (Galois/Counter Mode), difficile da implementare correttamente, ignorando la modalità OCB (Offset codebook mode), i cui brevetti sono scaduti diversi anni fa.
- Aggiungere pacchetti opzionali con padding casuale per proteggere dall'analisi del traffico. Secondo i creatori di LibrePGP, tali pacchetti con padding casuale iniziale non controllato rischiano di essere utilizzati per creare canali di trasmissione dati nascosti e aggirare i sistemi di prevenzione delle perdite di dati. In precedenza, l'idea di includere il padding era stata scartata in quanto oggetto del livello applicativo, non del livello di crittografia.
- Utilizzando uno schema di crittografia ECDH modificato (modificando il formato OID), invece di utilizzare la versione già descritta in RFC-6637 e implementata in PGP e GnuPG.
- Rimozione di alcune funzionalità utilizzate nella pratica, come il classico metodo di revoca della chiave, il flag "m" per contrassegnare i dati MIME e il flag "t" per separare i dati di testo dai dati binari (il flag "t" è stato sostituito dal flag "u" per il testo codificato UTF-8).
- Rifiuto di includere la protezione dei metadati del file firmato nel nuovo formato di firma (ad esempio, è possibile modificare il nome del file senza compromettere la firma).
- Esiste una dubbia possibilità di aggiungere un "sale" alle firme (firma salata) per migliorare la protezione contro gli attacchi di collisione con un dato prefisso. Il valore salato può essere utilizzato come canale nascosto non disconnettibile per trasmettere 32 byte di dati nella firma.
- Spostare lo standard verso l'uso primario per la comunicazione online, ignorando le esigenze di archiviazione dei dati a lungo termine.
I sostenitori di OpenPGP hanno già pubblicato critiche a queste critiche. In definitiva, se non si riuscisse a trovare un compromesso, la divisione potrebbe portare a crescenti incompatibilità nelle implementazioni OpenPGP/LibrePGP. Per risolvere parzialmente questo problema, gli sviluppatori di OpenPGP hanno corretto la quinta versione del formato di firma come compatibile con LibrePGP e hanno iniziato a lavorare sulla sesta versione.
Fonte: opennet.ru
