Perché la crittografia (o la firma) di lunghe code in E-Mails con PGP è problematica?

Non posso renderlo più semplice di questo :

Essentially, the trouble happens when Enigmail attaches an inline PGP signature to an email in Thunderbird's HTML message composer. The HTML composer is a different component than the plain-text composer, and it performs some "clean up" on the message body after the user hits send. That is an obvious recipe for trouble, since it occurs after the signature was computed over the message. Any alterations, including those that are invisible to the user (such as white-space changes or replacing special characters with HTML character codes) will alter the hash value of the message, which is the element of the signature that is encrypted by the sender's private key.

In this case, the alteration that happens to the message body is automatic line-wrapping. Thunderbird's line-wrapping for HTML messages breaks lines that exceed 79 characters (or whatever the value of the mailnews.wraplength preference is set to), so not every message is affected. In an attempt to avert this trouble, Enigmail performs its own line-wrapping on the message body just before generating the signature, at mailnews.wraplength - 2.

Nevertheless, there are invariably some situations when a single "word" is longer than 77 characters; the simplest example is a lengthy URL. In these situations, the automatic line-wrapping Thunderbird performs after Enigmail has processed the message splits the long line at the mailnews.wraplength point when it is sent, therefore the signature no longer validates when the email recipient's PGP client checks it.

TL; DR: è un'eredità e-mail.

Né GnuPG, né Thunderbird, né probabilmente altre implementazioni di OpenPGP si preoccupano della lunghezza della linea. Ma l'intera infrastruttura di posta elettronica lo fa.

E-Mail Legacy

Storicamente, il limite di 78 caratteri ( RFC 2822 ) è venuto fuori a causa del solito limitazioni di caratteri che si adattano a uno schermo per riga. Questo è da tempo andato da allora; mentre qualcosa attorno a questo numero di personaggi, o anche a qualche febbre, si tradurrà comunque in una migliore leggibilità rispetto alle linee lunghe da sinistra a destra del tuo schermo da 28 "4K, abbiamo un software leggermente più intelligente e user-friendly che rompe le linee automaticamente a limiti ragionevoli.

Ma l'e-mail è vecchia, così come i server e i client di posta elettronica (ancora in esecuzione). Ci sono ancora alcuni in the wild che non supportano le lunghe code, perché non sono mai state necessarie (come non dovrebbero accadere), e (potrebbero) non riuscire a gestire tale posta, o aggiungono nuove righe arbitrarie (che si interromperanno le firme).

Gestione di linee lunghe in OpenPGP

Per questo motivo, l'armatura ASCII "e-mail sicura" (radix-conversion) di OpenPGP esegue il wrapping a (massimo) 76 caratteri per riga. D'altra parte, i messaggi non firmati non verranno riarmati nella sezione di testo in chiaro, quindi Thunderbird / Enigmail ti ricorderà di rispettare quel limite di caratteri.

La posta con codifica OpenPGP / MIME (e la posta con codifica MIME in generale) non conosce questo problema, poiché citato- la codifica stampabile si occupa di aggiungere le interruzioni di riga richieste, che vengono rimosse prima che l'hash del messaggio venga calcolato per verificare la firma.

In caso di firma chiara, ciò che è firmato potrebbe non essere esattamente quello che hai digitato.

Per essere solido ( RFC4880 ):

Le linee
• che iniziano con "-" hanno come prefisso " <SP>- " (per evitare interpretazioni errate)
Le terminazioni di riga
• , qualunque esse siano, vengono sostituite con <CR><LF>
• lo spazio vuoto finale viene ignorato

Per soddisfare i requisiti SMTP ( RFC5322 ):

Le righe di messaggi
• NON DEVONO essere più lunghe di 78 caratteri (più <CR><LF> )
• le righe dei messaggi NON DEVONO essere più lunghe di 998 caratteri (più <CR><LF> )
Le linee di messaggi
• non devono essere costituite solo da un "." (la segnalazione in-band colpisce ancora) e potrebbe essere "riparata" lungo il percorso ( RFC5321 )

Il punto qui è che alcune modifiche potrebbero cambiare la semantica di un messaggio, ma si presume che non sia possibile modificare la quantità di spazio bianco alla fine di una riga. L'introduzione di alcune modifiche (nuove righe o cancellazione di un personaggio) violerebbe la firma, quindi un client PGP deve assicurarsi che questi eventi non si verifichino. Vedi anche bug Enigmail 494 .

(Alcune speculazioni: se usi occasionalmente caratteri non ASCII, questo può far sì che il tuo client di posta elettronica non usi text / plain, ma invece usi UTF-8 con codifica Base64 che elimini le complessità di cui sopra.)