Why is encryption (or signing) of long lines in E-Mails with PGP problematic?

Question

I am using Thunderbird with Enigmail and OpenPGP to encrypt and/or sign E-Mails. On many occasions Enigmail complains that I have too long lines in the mail and asks how it should wrap them.

However this doesn't seem to follow any logical trends. Sometimes it complains, sometimes it doesn't.

My question however: What does it matter in the first place how long a line is? A line break isn't something terribly different than the letter A (ok, it's a CR and a LF in most cases) but the encryption algorithm sees just bytes anyways.

I wasn't able to find any explaination whatsoever about this in the documentation as well.

Can someone explain why line breaks are problematic for signing/encrypting with PGP?

Answer 1

I can not make it simpler than this:

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.

Answer 2

TL;DR: this is e-mail legacy.

Neither GnuPG, nor Thunderbird, nor probably any other implementations of OpenPGP will bother about the line length. But the whole e-mail infrastructure does.

E-Mail Legacy

Historically, the limit to 78 characters (RFC 2822) came up because of the usual limitations of characters that fit on a screen per line. This is long gone since; while something around this number of characters, or even some fever will still result in a better readability than long lines from the left to the right of your 28" 4K screen, we've got slightly more intelligent and user-friendly software that breaks lines automatically at reasonable limits.

But e-mail is old, and so are (still running) e-mail servers and clients. There are still some in the wild that do not support long lines, because they've never been needed (as they should not occur), and they (might) fail at handling such mail, or they add arbitrary newlines themselves (which will break signatures).

Handling of Long Lines in OpenPGP

For this reason, the "e-mail safe" ASCII-armoring (radix-conversion) of OpenPGP wraps at (maximum) safe 76 characters per line. On the other hand, clearsigned messages will not be rewrapped in the clear text section, thus Thunderbird/Enigmail remember you to stick to that character limit.

OpenPGP/MIME-encoded mail (and MIME-encoded mail in general) does not know this problem, as the quoted-printable encoding takes care of adding required linebreaks, which are removed before the message hash is calculated for verifying the signature.

Answer 3

In the case of clear-signing, what is signed may not be exactly what you have typed.

In order to be robust (RFC4880):

• lines starting with "-" are prefixed with "<SP>-" (to prevent misinterpretation)
• line endings, whatever they are, are replaced with <CR><LF>
• trailing whitespace is ignored

In order to fulfill SMTP requirements (RFC5322):

• message lines SHOULD NOT be longer than 78 characters (plus <CR><LF>)
• message lines MUST NOT be longer than 998 characters (plus <CR><LF>)
• message lines must not consist of only a "." (in-band signalling strikes again) and may be "fixed" along the way (RFC5321)

The point here is that some modifications could change the semantics of a message, but it is assumed that changing the amount of whitespace at the end of a line could not. The introduction of some changes (extra newlines or deletion of a character) would violate the signature, so a PGP client must make sure these events won't happen. See also Enigmail bug 494.

(Some speculation: if you are occasionally using non-ASCII characters, this may cause your email client not to use text/plain, but instead to use base64-encoded UTF-8 which sidesteps the above complexities.)