4 ms·

Does it go beyond the minimum and old set of ciphers in use by the usual implementations? I'm asking because I firmly believe that any GnuPG re-implementation s

Does it go beyond the minimum and old set of ciphers in use by the usual implementations? I'm asking because I firmly believe that any GnuPG re-implementation should try to improve on the current state of mail crypto [0]. [0] https://blog.cryptographyengineering.com/2014/08/13/whats-matter-with-pgp/ https://blog.cryptographyengineering.com/2014/08/13/whats-ma...

nwalfield 8y ago
Let's go through Matt's major points: Key Exchange / Key Management This isn't really a problem with the OpenPGP protocol or an OpenPGP implementation. This is inherent to any system that tries to protect you from active adversaries. If you are willing to use centralization, then you can do something like X509 (what is what TLS uses), but there are many, many cases of CAs issuing bad certificates either by accident or maliciously, e.g., the TURKTRUST incident. You can also do something like Signal with its verified key servers. But, if you want to be decentralized, then somehow you have to get the user involved. So, in my opinion, this is more a criticism of decentralization than of OpenPGP. Now, that doesn't mean that OpenPGP tooling can't help. In fact, about 4 years ago, several initiatives began working on mechanisms to make key discovery much easier, and mostly transparent for users primarily concerned about privacy (as opposed to those whose threat model includes active adversaries, like activists, lawyers, or journalists). See, in particular, the work that pep (https://pep.foundation https://pep.foundation) and Autocrypt (https://autocrypt.org https://autocrypt.org) have been doing. Forward Secrecy As I've written before (https://arstechnica.com/information-technology/2016/12/signal-does-not-replace-pgp/ https://arstechnica.com/information-technology/2016/12/signa...), I don't think that forward secrecy is actually fixing a problem that most people have. Particularly in the case of OpenPGP where most people are interested in encryption of data at rest (messages stored on an IMAP server), which forward secrecy doesn't help (forward secrecy, because it throws away old key material, only makes sense for protecting data in motion). But, that doesn't mean that we haven't given some thought to the problem. In fact, at the very same gathering, Justus, who is also working on Sequoia, presented a proposal for adding forward secrecy to OpenPGP in a backwards compatible manner. You can watch the presentation (https://www.youtube.com/watch?v=an6oYjikAPY https://www.youtube.com/watch?v=an6oYjikAPY), or read an early version of the proposal (https://mailarchive.ietf.org/arch/msg/openpgp/mk8_FSS-n4DVGfh_VwuGtEOS2xk https://mailarchive.ietf.org/arch/msg/openpgp/mk8_FSS-n4DVGf...). The short version is: OpenPGP already has mechanisms to mark encryption keys as being appropriate for data at rest or data in motion. Until now, no implementation has bothered with this distinction. We propose creating two encryption-capable subkeys, one for data at rest, and one for data in motion, and rotating the one for data in motion once a week. To ensure that a sender has a non-expired encryption key we pre-generate keys, and distribute them via the keyserver network. The OpenPGP format and defaults suck It is true that OpenPGP has standardized a number of ciphers that are no longer sensible, includes compression support, etc. But, OpenPGP is over 30 years old. In that time there have been many improvements. But Matt is right that these improvements come slowly. This is partly due to the lack of funding: the industry choose S/MIME over OpenPGP. (Although S/MIME is cryptographically worse than OpenPGP. See EFAIL for a critical example of why.) A major difficult to deprecating old ciphers is that OpenPGP is used for data at rest. And people rightly expect, I think, to be able to decrypt data and verify signatures from X years ago. This means we can't completely drop support for, say, CAST5: people wouldn't be able to decrypt old messages. Matt seems to ignore this bit, and focuses primarily on real-time communication (e.g., Signal), which only needs encryption for data in motion, i.e., the encryption is stripped and only archived on a trusted device (e.g., not an IMAP server). One thing that we are consider in Sequoia is requiring the caller to provide a timestamp when verifying or decrypting a message. The timestamp can be used to choose defaults that are appropriate for when the message was allegedly created. The timestamp can be double checked with the timestamp in the signature. In this way, if someone tries to send you an email using a deprecated cipher, they'll also have to set the timestamp in the email to, say, 1997, which would hopefully be suspicious. Likewise, something like a can be shown when the message doesn't meet the current standard. I hope that helps! If you have any other questions, you're welcome to ask here, or on irc (#sequoia on freenode) or on our mailing list (devel@sequoia-pgp.org). :) Neal
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.

nwalfield 8y ago

Let's go through Matt's major points: Key Exchange / Key Management This isn't really a problem with the OpenPGP protocol or an OpenPGP implementation. This is inherent to any system that tries to protect you from active adversaries. If you are willing to use centralization, then you can do something like X509 (what is what TLS uses), but there are many, many cases of CAs issuing bad certificates either by accident or maliciously, e.g., the TURKTRUST incident. You can also do something like Signal with its verified key servers. But, if you want to be decentralized, then somehow you have to get the user involved. So, in my opinion, this is more a criticism of decentralization than of OpenPGP. Now, that doesn't mean that OpenPGP tooling can't help. In fact, about 4 years ago, several initiatives began working on mechanisms to make key discovery much easier, and mostly transparent for users primarily concerned about privacy (as opposed to those whose threat model includes active adversaries, like activists, lawyers, or journalists). See, in particular, the work that pep (https://pep.foundation https://pep.foundation) and Autocrypt (https://autocrypt.org https://autocrypt.org) have been doing. Forward Secrecy As I've written before (https://arstechnica.com/information-technology/2016/12/signal-does-not-replace-pgp/ https://arstechnica.com/information-technology/2016/12/signa...), I don't think that forward secrecy is actually fixing a problem that most people have. Particularly in the case of OpenPGP where most people are interested in encryption of data at rest (messages stored on an IMAP server), which forward secrecy doesn't help (forward secrecy, because it throws away old key material, only makes sense for protecting data in motion). But, that doesn't mean that we haven't given some thought to the problem. In fact, at the very same gathering, Justus, who is also working on Sequoia, presented a proposal for adding forward secrecy to OpenPGP in a backwards compatible manner. You can watch the presentation (https://www.youtube.com/watch?v=an6oYjikAPY https://www.youtube.com/watch?v=an6oYjikAPY), or read an early version of the proposal (https://mailarchive.ietf.org/arch/msg/openpgp/mk8_FSS-n4DVGfh_VwuGtEOS2xk https://mailarchive.ietf.org/arch/msg/openpgp/mk8_FSS-n4DVGf...). The short version is: OpenPGP already has mechanisms to mark encryption keys as being appropriate for data at rest or data in motion. Until now, no implementation has bothered with this distinction. We propose creating two encryption-capable subkeys, one for data at rest, and one for data in motion, and rotating the one for data in motion once a week. To ensure that a sender has a non-expired encryption key we pre-generate keys, and distribute them via the keyserver network. The OpenPGP format and defaults suck It is true that OpenPGP has standardized a number of ciphers that are no longer sensible, includes compression support, etc. But, OpenPGP is over 30 years old. In that time there have been many improvements. But Matt is right that these improvements come slowly. This is partly due to the lack of funding: the industry choose S/MIME over OpenPGP. (Although S/MIME is cryptographically worse than OpenPGP. See EFAIL for a critical example of why.) A major difficult to deprecating old ciphers is that OpenPGP is used for data at rest. And people rightly expect, I think, to be able to decrypt data and verify signatures from X years ago. This means we can't completely drop support for, say, CAST5: people wouldn't be able to decrypt old messages. Matt seems to ignore this bit, and focuses primarily on real-time communication (e.g., Signal), which only needs encryption for data in motion, i.e., the encryption is stripped and only archived on a trusted device (e.g., not an IMAP server). One thing that we are consider in Sequoia is requiring the caller to provide a timestamp when verifying or decrypting a message. The timestamp can be used to choose defaults that are appropriate for when the message was allegedly created. The timestamp can be double checked with the timestamp in the signature. In this way, if someone tries to send you an email using a deprecated cipher, they'll also have to set the timestamp in the email to, say, 1997, which would hopefully be suspicious. Likewise, something like a can be shown when the message doesn't meet the current standard. I hope that helps! If you have any other questions, you're welcome to ask here, or on irc (#sequoia on freenode) or on our mailing list (devel@sequoia-pgp.org). :) Neal

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.