3 ms·

It's interesting that blog post didn't mention one of the largest concerns people should have with PGP -- it still doesn't use authenticated encryption even tho

by cyphar 8y ago

It's interesting that blog post didn't mention one of the largest concerns people should have with PGP -- it still doesn't use authenticated encryption even though the problems with unauthenticated encryption have been known for decades. (Yes, GPG has the MDC -- but as the fairly recent "PGP/MIME is broken" bugs showed, the handling of MDC was broken in several ways and it can only be detected after outputting all of the data. AEAD is far more cryptographically sound.)

Xylakant 8y ago
Nitpick: MDC failures can only be detected after decrypting all the data. So the decrypting program would need 2 passes (one to validate and one to present the plaintext) or buffer the decrypted output until it verified the MDC is sound. GPG, however, does neither. AEAD, as far as I understand, suffers from a similar, though less severe problem: decryption can fail at any point due to a validation error. You can be certain that anything up to the failure hasn’t been tampered with, but the question of what to do with the partial plaintext remains. A partial, truncated ISO or script may be problematic, even if it hasn’t been tampered with. (think: truncate rm -rf /tmp/foo to rm -rf /“)
- cyphar 8y ago
  > GPG, however, does neither. It also will output to --output even if an MDC validation error occurs at any point, which is pretty insane. But from memory this is actually a larger architectural problem (GPG doesn't appear to buffer anything -- which means that when you tell it to write to --output it doesn't write anywhere else first). > AEAD, as far as I understand, suffers from a similar, though less severe problem: decryption can fail at any point due to a validation error. You can be certain that anything up to the failure hasn’t been tampered with, but the question of what to do with the partial plaintext remains. That is also a problem, though it would avoid most attacks where programs don't check GPG error codes (which is what the email vulnerabilities a few months ago were about). The only practical attack is what you've described -- some sort of known-plaintext attack where the message already contains the attack payload as a prefix. Ultimately AEAD (over MDC) is a protection against people accidentally doing the wrong thing when using crypto tools -- because users should not trust any of the decrypted text if the message didn't validate.

by cyphar 8y ago

Xylakant 8y ago

Nitpick: MDC failures can only be detected after decrypting all the data. So the decrypting program would need 2 passes (one to validate and one to present the plaintext) or buffer the decrypted output until it verified the MDC is sound. GPG, however, does neither. AEAD, as far as I understand, suffers from a similar, though less severe problem: decryption can fail at any point due to a validation error. You can be certain that anything up to the failure hasn’t been tampered with, but the question of what to do with the partial plaintext remains. A partial, truncated ISO or script may be problematic, even if it hasn’t been tampered with. (think: truncate rm -rf /tmp/foo to rm -rf /“)

cyphar 8y ago
> GPG, however, does neither. It also will output to --output even if an MDC validation error occurs at any point, which is pretty insane. But from memory this is actually a larger architectural problem (GPG doesn't appear to buffer anything -- which means that when you tell it to write to --output it doesn't write anywhere else first). > AEAD, as far as I understand, suffers from a similar, though less severe problem: decryption can fail at any point due to a validation error. You can be certain that anything up to the failure hasn’t been tampered with, but the question of what to do with the partial plaintext remains. That is also a problem, though it would avoid most attacks where programs don't check GPG error codes (which is what the email vulnerabilities a few months ago were about). The only practical attack is what you've described -- some sort of known-plaintext attack where the message already contains the attack payload as a prefix. Ultimately AEAD (over MDC) is a protection against people accidentally doing the wrong thing when using crypto tools -- because users should not trust any of the decrypted text if the message didn't validate.