On Mon 2015-06-08 10:32:18 -0400, intrigeri wrote: > Anyway: the root cause of the problem is PGP/inline, and it's a real > one (as explained in the thread that lead to this bug being filed > IIRC, the sending MUA has no way to express what's the encoding of the > cleartext, because it only sees the ciphertext that's encoded in > US-ASCII). In some cases, and even possibly in the majority of cases, > it works because the receiving MUA's assumptions are correct, but it > cannot possibly *always* work because there's no robust way to > correctly guess the encoding of a bytestring in all cases. > > I'm wrong, I'm sure dkg will happily correct me :)
Far from it, i was writing up this exact explanation when your message came in. Thanks for writing it :) Furthermore: It's not just about whether your peer's MUA is likely to guess right, and whether a message is *likely* to be interpreted correctly. You also have to evaluate the problem in an adversarial context. If this crucial piece of context (character encoding) is not cryptographically protected, it can be manipulated by an attacker. If the bytestream gets reinterpreted based on the attacker's modifications, what kinds of errors can result? About 30 minutes of fiddling around with malicious character encodings got me to the "message tampering through header substitution" example here: https://dkg.fifthhorseman.net/notes/inline-pgp-harmful/ It's not a world-shattering break, but it's clear that the context does need to be protected in order for messages to be safely transmitted. Inline PGP has no way to do that. --dkg _______________________________________________ Tails-dev mailing list Tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
