2

I find the language of RFC4880-bis very disturbing on the topic of privacy. I do not want "modest" security.

"Consequently, because it [MDC] is a modest security system, it has modest requirements on the hash function(s) it employs." [emphasis mine]

Jaw hits floor.

Moreover, speed is not the most important thing--privacy is. I do not want to see SHA-1 anywhere. I don't care if the OpenPGP Standard is followed. I just want to encrypt some files and feel good about it. I don't care if the implementation must be paid for. GnuPG is enjoyable to work with, but I simply do not trust it.

Does a hardened PGP exist that is open source? One that does not use curves which are known to be compromised (as GnuGP does), which uses hashes such as Blake2 and Whirlpool, and refuses to make any decisions that weaken security--namely, MAC-then-Encrypt.

Community
  • 1
  • I suppose you could use `openssl smime`. It lets you specify the cipher and the digest algorithm, but it's not nearly as user friendly. If it's just about encryption, you don't need a hash function at all, just use `openssl enc`. – Volker Feb 12 '18 at 14:30
  • 5
    (1) The parenthetical is not in the RFC. If you quote a standards document, please don't edit the quote. (2) The text you quoted is from a *non-normative explanation*. (3) The quoted text is in the context of *unsigned, encrypted* messages, and that is what the "modest security system" is in reference to. If you want higher security guarantees against tampering, then you should sign the message, which allows you to choose a preferred hash algorithm if you want to deviate from the defaults. (4) Software recommendation questions are off topic on [security.se], see the [help/on-topic]. – user Feb 12 '18 at 14:48
  • 4
    It's worth noting that just because SHA-1 has weaknesses, those weaknesses may not apply to the circumstance of its use within GPG. There have been some previous questions on this topic https://security.stackexchange.com/questions/68105/gpg-keys-sha-1 for example – Rory McCune Feb 12 '18 at 17:39
  • @Patriot 1) if quoting something, please include a link. 2) If editing the quote for clarity, use standard editing notes to differentiate between what is original and what you are adding. Else, you *are* changing the original. Software recommendations are off-topic here. What's available at any given time changes radically. – schroeder Feb 12 '18 at 20:13
  • This question is based on incorrect premise, you are interpreting the RFC incorrectly. "it" in your quoted text refers to MDC, not OpenPGP. – Lie Ryan Feb 12 '18 at 22:14
  • 1
    @LieRyan that might be my mistake. I think you are correct though. Edit made – schroeder Feb 12 '18 at 22:37
  • @ Lie Ryan I think your comment is correct. I acknowledge that. Importantly, I apologize that my tone was inappropriate to one of those who commented. Moreover, my thoughts on this important issue should have been more carefully constructed. I would appreciate the opportunity to create a better question sometime. It is absolutely correct that this one was put on hold, and I hope everyone can at least give me some leeway because it was my first question on your site. Thank you. –  Feb 15 '18 at 11:30
  • @ Michael I apologize for my inappropriate tone in my response to your comment, which was rightly deleted. However, you did engage in the straw man fallacy, which is now neither here nor there really. I am still learning to use your site the right way and to work and play well with others. –  Feb 15 '18 at 12:06

1 Answers1

3

No, however it is not necessary. Some of your presumptions are incorrect to start out with. The things you point out as security issues are not necessarily actual issues. Let me go into more detail.

MDC uses SHA-1 and MAC-then-Encrypt

The MDC is designed to avoid a decryption oracle attack, as well as accidental corruption. Both of these issues are effectively mitigated even when using a "modest" hash function. In fact, even MD5 would likely not cause issues, considering the MDC acts similarly to a MAC where collision resistance does not matter. Using a stronger hash function would not give you any real benefit. In order to have actual integrity guarantees, you must digitally sign the message. That will prevent a large class of attacks that MDC is unable to. Overall, MDC is not designed to give a strong guarantee of integrity. It is neither intended nor capable of doing so. It is only meant to protect from a particular, obscure attack, and to give some protection against accidental corruption that may lead to decrypting a garbled message.

BLAKE2 and Whirlpool are not supported

For signing a message, a hash function is used. For this purpose, SHA-256 and SHA-512 are fine. In this situation, SHA-1 may not be ideal, and for this reason, it is being phased out in favor of stronger functions. While entirely different functions may be nice, it is not necessary for security. SHA-2 is fine. They are completely preimage resistant and have very good collision resistance. Also note that Whirlpool, while not endorsed by NIST, is directly based on AES, which someone who has no trust in NIST whatsoever may want to avoid (not that there's any reason to suspect it is particularly weak). The attacks that SHA-2 are vulnerable to (such as length extension attacks) are completely irrelevant to the way they are used in the OpenPGP format. When the need arises, more hashes may be added.

NIST curves are used for ECC

This is not entirely true. A NIST curve (P-256, specifically) is used when ECDSA is in use, but ECDSA is being deprecated due to the same weaknesses that regular DSA has. It is supported, but it is not recommended or required. Newer GnuPG versions have a non-NIST curve, specifically Ed25519 to replace ECDSA. It is not as well supported, but it is faster and has superior security. I'd also like to note that P-256 and other NIST curves are not "known to be compromised", as you put it. The issue with P-256 is that it does not use nothing-up-my-sleeve numbers, making it theoretically possible that the values were chosen to enable a class of yet-unknown attacks. There is no actual evidence for that, but it is good to be cautious. That's one of the reasons ECDSA is being replaced by Ed25519.

The real issues

There are actual issues with GnuPG, but they are not among the things you mentioned. These issues tend to be newer things which were not a concern back when the OpenPGP format was thought up:

  • Forward secrecy is not present. Compromising the private key allows retroactive decryption.

  • Post-quantum cryptography is not in use. NTRU would be great, but it just isn't supported.

  • The Web of Trust is hard to get right, so most people who use PGP tend to rely on TOFU.

  • GnuPG is very complex. For parsing complex formats, a tight seccomp filter would be nice.

  • PGP involves non-intuitive concepts, making it hard to use. This hinders adoption rates badly.

Community
  • 1
forest
  • 64,616
  • 20
  • 206
  • 257
  • `Forward secrecy is not present` and `Compromising the private key allows retroactive decryption.` are the same. Also, FS is unsolvable given OpenPGP's design requirements, because OpenPGP are designed for asynchronous messaging (neither systems need to be reachable to create a message) over unreliable store-and-forward system (messages are regularly dropped by relays without malice being inferred), which is what email is. Any systems that are designed to work over such constraints necessarily cannot be forward secure. – Lie Ryan Feb 13 '18 at 10:39
  • @LieRyan I know those two are the same. My point was to explain what the implication of the lack of forward secrecy is. As for PGP's usage being incompatible with FS, that is mostly true. There is a [draft](https://tools.ietf.org/html/draft-brown-pgp-pfs-03) for adding it to the standard, but it has not been implemented (and it would be overly dependent on the ability of the underlying medium to overwrite key material). At the very least, the subkeys could be rotated from time to time. But you're right that it is mostly incompatible and getting it to work would be hacky. – forest Feb 13 '18 at 14:27
  • In your first sentence you presume to know a lot more than what you actually do know. We do not know if SHA-1 and family 2 are broken in their supposed one-wayness. I, and I am in the minority, take it for granted that they are broken. Although I strongly disagree with you on the first part of your response, I look forward to going through your comments very carefully. I absolutely agree with you on the tight seccomp filter and how GnuPG is non-intuitive to use. Thank you. –  Feb 15 '18 at 12:02
  • Look at what you said: "In order to have actual integrity guarantees, you must digitally sign the message." Exactly! And the RFC goes on to talk about how IT IS VALUABLE TO NOT TO HAVE TO SIGN IT. You are utterly lost in space. Go ahead jokers, with no real information access experience. Delete this baby. –  Feb 15 '18 at 12:23
  • @Patriot I would be very surprised if anything modern with the Merkle–Damgård construction was vulnerable to a preimage attack ("one-wayness"). I do not presume that I have any classified information regarding SHA-1 or SHA-2, I am basing that answer on the current understanding of cryptography. Note that, if you take for granted SHA-1 being fully (first and second preimage, and collision) broken, then every password you ever generate on your computer is also broken, as (at least) Linux relies on SHA-1 for randomness. – forest Feb 15 '18 at 12:36
  • @Patriot Regarding the value in not signing it, I entirely agree with them. Sometimes I may want to encrypt and transmit something, without it being linked back to me. A signature provides non-repudiation, which means that it will be impossible for me to claim that I did not author that message. The MDC gives at least some integrity even when I do want to publish anonymously. This is all about threat modeling. Do you think it would be better if they removed the MDC and just told people to sign everything instead? – forest Feb 15 '18 at 12:39
  • @Patriot I take exception to calling people here "jokers" with no real experience. Many people here, including me, deal with information security daily as part of our jobs. Perhaps it is time to reflect on your own views and ask yourself if your threat model is sane. Worrying about a first preimage attack in SHA-512 and declaring that BLAKE2 would be better is just silly. It is far more likely that an efficient classical algorithm for solving the discrete log problem and integer factorization is discovered, obliterating any semblance of confidentiality for all current asymmetric cryptography. – forest Feb 15 '18 at 12:46
  • I understand. I did not say anything about classified info either, and I don't have any--especially on this topic. I have been talking about taking a strong stance in order to heighten security, and that is the stance of distrust. –  Feb 15 '18 at 12:48
  • I am wrong. I apologize again and I should not be on your site. I was totally off. Thank you. Bye. –  Feb 15 '18 at 12:49