Subject: [openpgp] SHA-2 support should be mandatory – change defaults

From: Christian Stadelmann <[email-masked]>
Date: Sun, 10 Aug 2014 19:57:48 +0200

Hi

Disclaimer: I'm not much familiar with the RFC process

I recently found that many mails encrypted by Enigmail/GnuPG are using
SHA-1 as hashing algorithm.
So I asked the Enigmail guys to use SHA-2 instead [1]. They said no
arguing not to change any GnuPG defaults.
The GnuPG guys don't want to set SHA-2 as default [2] since RFC4880 [3]
only states that SHA-1 must be implemented. Since SHA-2 support is not
mandatory they won't make it default.

There are several known attacks against SHA-1 reducing its effective
security (without breaking it). Since SHA-2 is widely deployed for about
10 years I think it is time to move on and make SHA-2 default.

I don't know whether any plans are around to specify a Revision 2 of the
OpenPGP standard but if they are, this should be part of it. Are there
any chances to change it?
And if there are such changes would it be possible to make these changes
too:
1. Add SHA-3 support
2. Make AES-256 the default (mandatory) symmetric-key algorithm instead
of TripleDES (which is quite weak anyway)
3. Replace DSA as default public-key algorithm (since it relies on good
random which is often not available/ensured) by RSA.
4. Algorithm Preferences / RSA: change minimum RSA key size to 2048

There was a related discussion on this some 5 years ago [4].

[1]
http://sourceforge.net/p/enigmail/forum/feature_requests/thread/e1810d6b/
[2]
https://bugs.g10code.com/gnupg/issue1679
[3]
https://tools.ietf.org/html/rfc4880#section-9.4
[4]
https://www.ietf.org/mail-archive/web/openpgp/current/msg00239.html

Regards
Christian Stadelmann

---

From: Aaron Toponce <[email-masked]>
Date: Sun, 10 Aug 2014 18:40:13 -0600

> 10 years I think it is time to move on and make SHA-2 default.

First off, I'm not a cryptographer, but this is my understanding of what it
would take to break SHA-1 on a PGP signature.

I'm assuming that the attacks you are referring to are collision attacks,
because there is no practical second preimage attack on SHA-1 [1], or even MD5 for
that matter [2]. Second preimage attacks differ from collision attacks subtly. In a
collision attack, the plaintexts p1 and p2 are not specified, but chosen
randomly. With second preimage attacks, plaintext p1 is known, so plaintext p2
must be found such that hash(p1) == hash(p2) [3].

    1. http://stackoverflow.com/a/2774744
    2. https://en.wikipedia.org/wiki/MD5#Preimage_vulnerability
    3. https://en.wikipedia.org/wiki/Preimage_attack

Also, I'm assuming you don't understand how PGP signatures work. With PGP
signatures, a plaintext message is first cryptographically hashed, then
encrypted with the sender's private key. So to mount a feasible attack on a PGP
signature, you would need to:

    1- Produce the exact cryptagraphic hash from a different public key, or
    2- Find a hash collision with differing text

In the first case, you would be breaking RSA, El Gamal, etc. In the second, you
would be mounting a second preimage attack on the hash function. Both cases are
not practical, or even remotely close to becoming practical in the foreseeable
future.

Finally, even though it's not default, you can change your gpg.conf(5) to use a
specific hashing algorithm that your signing key supports, such as SHA1,
SHA224, SHA256, SHA384, SHA512, RIPEMD160, etc. It's trivial to make the
change, and while I don't know about Enigmal specifically, Mutt will honor the
change.

I'm guessing that there may be some historical baggage that prevents making
SHA-2 or SHA-3 the default for OpenPGP in the near term, such as breaking older
PGP userspace implementations. Also, SHA-1 outperforms SHA-2 [4]. I would
advocate moving to SHA-3 if performance was a factor, as the authors claim 12.5
cycles per byte [5], versus 15.8 with SHA-256 and 17.7 with SHA-512 (even
though SHA-1 still out performs SHA-3) [4].

    4. http://www.cryptopp.com/benchmarks.html
    5. http://keccak.noekeon.org/Keccak-implementation-3.2.pdf

Thanks,

-- 
. o .   o . o   . . o   o . .   . o .
. . o   . o o   o . o   . o o   . . o
o o o   . o .   . o o   o o .   o o o

---

From: David Leon Gil <[email-masked]>
Date: Mon, 11 Aug 2014 00:21:08 -0400

> > 10 years I think it is time to move on and make SHA-2 default.

Christian is correct (except for the not breaking SHA-1 part). The
collision attacks on SHA-1 are serious and are computationally feasible
(but still too expensive for academic cryptographers). I'd suggest reading
Marc Steven's thesis:
https://marc-stevens.nl/research/papers/PhD%20Thesis%20Marc%20Stevens%20-%20Attacks%20on%20Hash%20Functions%20and%20Applications.pdf

Note that chosen-prefix collision attacks, in particular, can accomplish
almost everything a 2nd preimage attack on a hash can. Again, Stevens
provides useful details.

Also, I'm assuming you don't understand how PGP signatures work.

OpenPGP does not use any signature algorithms which are
'collision-resistant'. So, if the hash algorithm is weak, so are the
signatures.

For RSA signatures, the situation is even worse; there is no proof
that PKCS1v1_5 signatures have any specific security strength against
forgery.[*]

ECDSA signatures are the only OpenPGP-specified signature algorithm with a
good security proof. Google's E2E extension is well-written and generates
ECC keys exclusively (but can verify RSA signatures); I recommend it
highly. (But it is in beta right now.)

even though it's not default, you can change your gpg.conf(5) to use a
> specific hashing algorithm

In particular, set the following preferences in GnuPG:

digest-algo SHA512
cipher-algo AES256

The man page incorrectly warns against using them, and advises that you use
the 'personal-' variants instead. These effectively do nothing.

If any downstream package maintainers are reading this, email me, and I'll
be delighted to open an issue to include a modern gpg.conf skeleton in
your package. (I'm presently preparing an annotated version with detailed
justifications for various option settings.)

> PGP userspace implementations.

Does *anyone* on this list use an OpenPGP implementation that does not
support SHA-2 and AES? (And, if so, can you estimate how many users are in
a similar position?)

-dlg

[*] In particular, even though we can estimate the cost of *factoring* an
RSA key, the cost of *forging* a signature may be much lower. This cost may
well be lower than the cost of a collision attack on the hash. See,
e.g., Coron et al.'s work on ISO 9796-2 signatures, if you aren't clear on
the distinction: https://eprint.iacr.org/2009/203.pdf

---

From: "Robert J. Hansen" <[email-masked]>
Date: Mon, 11 Aug 2014 02:27:13 -0400

> security (without breaking it).

The question is whether these attacks reduce SHA-1's effectiveness as it
is used in OpenPGP, and if so, to what extent.  (My belief is they do,
but not to the extent doomsayers fear.)

> 2. Make AES-256 the default (mandatory) symmetric-key algorithm
> instead of TripleDES (which is quite weak anyway)

The best attack on 3DES requires 315 yottabytes (!!) of memory just to
reduce it to complexity 2**112.  For any reasonable assumption about
computing power, 3DES is as solid as a rock and offers an effective key
length comparable to more modern ciphers.

There are many reasons to dislike 3DES.  It's slow, ungainly, hard to
implement correctly, has a relatively small block size, and so on... but
"quite weak" is not one of them.

I would not mind replacing 3DES as the mandatory symmetric cipher, but
there needs to be better justification than this.

> 3. Replace DSA as default public-key algorithm (since it relies on
> good random which is often not available/ensured) by RSA.

A good PRNG is required for the overwhelming majority of OpenPGP uses.
(I mean, sure, technically you could send everything unencrypted and
unsigned in an OpenPGP packet, but...)  If you don't have a good PRNG
then pretty much the entire protocol falls apart, so I don't understand
why it's important to make RSA the default key selection because it's
less dependent on having a good PRNG.  What am I missing here?

I have nothing against making RSA the default, but again, we need better
justification.

---

From: Werner Koch <[email-masked]>
Date: Mon, 11 Aug 2014 10:11:43 +0200

> random which is often not available/ensured) by RSA.

You mean the random K value commonly used for signatures?  GnuPG has
replaced that by the RFC-6979 method.  I don't know how other
implementations handles this.

Anyway, I assume that it is now common understanding that a v5 key
format will suggest the use of ECC algorithms using modern curves.

Shalom-Salam,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.

---

From: Aaron Toponce <[email-masked]>
Date: Mon, 11 Aug 2014 06:36:54 -0600

> implementations handles this.

Just to clarify for those on the list (I'm not sure of the technical
competencies of most on the list), RFC 6979 as I understand it specifies a
"deterministic DSA". This is calculated by first creating an HMAC_DRBG(k,c)
value, where 'k' is a randomly generated key, and 'c' is a counter. Provided
the hashing algorithm is cryptographically secure, even though the output is
determined, its output is indistinguishable from true random, and it will be
uniformly chosen. This output is now the "random k" for DSA that Werner refers
to.

---

From: Jon Callas <[email-masked]>
Date: Wed, 13 Aug 2014 20:04:29 -0700

To add in my two cents to this, I'm going to channel an old Security AD, Jeff Schiller.

There's a huge difference between Mandatory To Implement (a MUST) and Mandatory to Use.

As perhaps the best example, the X.509 RFCs list DSA as the MUST algorithm, but it's not clear that there are as many real-world DSA certificates as I have fingers. Or noses. Everyone uses RSA or ECC.

Thus, I agree with what you're saying, that implementations really need to stop using SHA-1, except by some explicit override, and maybe not even then. In PGP, we stopped using SHA-1 by default back in 2004 when Wang's attacks came out. We moved right to SHA-256, and just started marking all keys as wanting SHA-256 or better.

Similarly, PGP started guiding people early on to longer RSA keys. You could make one if you wanted, but you had to go into advanced key creation etc. Also similarly, it had opinions about symmetric algorithms and these were in the defaults.

You don't need to change any documents, you need to get software to change.

Now, there are plenty of other things that could be useful. I might, for example, do an individual draft for SHA3, or even SHA-512/z in a few relevant values of z.

As for DSA, there's no reason you can't use any of a number of protected DSAs. Werner noted that GnuPG uses RFC-6979 to protect it. PGP always used a keyed hash, where the key was the DSA private key to improve the nonce. If you wonder why PGP didn't use an HMAC, it's because in those days there was no HMAC. These days, HMAC is Simply What Is Done.

In short -- it's a lot easier to fix software than documents. Remember, (again, channeling Schiller) standards exist for interoperability.

	Jon