Re: HOWTO prep for migration off of SHA-1 in OpenPGP

Posted by: aigarius 5 years, 2 months ago

(12 comments)

Daniel says that we should move away from SHA1 by switching hash algorithms for signatures and generating keys that use at least SHA256 from SHA-2 family. I have been bitten by non-default GPG options before. So I propose that we do a security release of GPG that changes the defaults of key generation and key signing in such ways that SHA-1 algorithms are not used by default for any operation, unless a backwards compatibility option is used.

Currently unrated


Comments

  • Wouter Verhelst 5 years, 2 months ago

    Er, it's not entirely clear to me what you think that's going to accomplish.

    Daniel suggests changing the defaults locally. You suggest changing the defaults in the source.

    Apart from the fact that the former requires every individual to do stuff manually, the effects are going to be the same.

    Can you elaborate?

    Link / Reply
  • aigarius 5 years, 2 months ago

    The defaults should be sane and secure. While changing the defaults locally is faster for the people that do infact read the blogs, the news is unlikely to reach most of the people using the software. The fastest way and most secure way to propagate the best practices is to make them the default.

    And besides the good security by default, this will also show care for our users. Imagine a new GPG user creating a key with default options, only to be told at the next keysigning that his key is not good enough, because he did not use the right digest algorithm. That is bad for the image of the software, a bad practice.

    So, updating defaults to reflect best practice is good practice IMHO, and when old defaults may cause security problems, then I think that would allow for such defaults-only update to be propogated via the security update channels.

    Edit: Also an official security update is a great way to bring general visibility to the problem.

    Link / Reply
  • brian m. carlson 5 years, 2 months ago

    Uh, the fingerprint for v4 keys (that is, all RSA keys generated by GnuPG and all DSA keys) is created by using the SHA-1 hash. Also, the Modification Detection Code packet (which prevents certain attacks that involve modifying the ciphertext) uses SHA-1; even if that packet were extended to use SHA-256, it would still be possible to use a rollback attack to use SHA-1 instead.

    Additionally, despite my protests, SHA-1 is the default fallback hash if no other hash is available. That is, if I am sending a signed and encrypted message, and I cannot find a hash algorithm that the recipient can use that is also acceptable to me, SHA-1 will be used.

    So as much as I would like to get rid of SHA-1, I think it will be difficult for OpenPGP. I think it would also be better to use SHA-512 instead of SHA-256, to prevent having this same problem again soon.

    Link / Reply
  • Daniel Kahn Gillmor 5 years, 2 months ago

    Aigarus, i think a change in defaults should come at some point soon anyway, and it would be interesting to see Debian lead on this. On the other hand, i think it's important that those of us who come closer to understanding what's going on take it on ourselves first, iron out any wrinkles, and *then* push for a change in the defaults.

    Brian: SHA-1's collision-resistance has been compromised, but it is not clear that its one-wayness has been compromised. As <a href="http://www.imc.org/ietf-openpgp/mail-archive/msg33252.html" rel="nofollow">Daniel A. Nagy points out</a>, for fingerprints and MDC, collision resistance is unimportant, and only one-wayness matters.

    I agree there's more work to be done to extricate OpenPGP fully from SHA-1, but i don't believe that the presence of SHA-1 in fingerprints and MDCs represent a security concern at this point. I'm much more concerned about data signatures and identity certifications, in which some of the data provided comes not from the signer, but from an outside party. The use of SHA-1 with significantly weakened collision-resistance in these contexts presents real room for dangerous shenanigans.

    As for SHA512 instead of SHA256, i'm fine with that (in fact, that's what i use myself with my 4096-bit RSA key). But not everyone has the hardware (or wants to spend the time) to put up with the extra computational cost here.

    At any rate, my hope is that SHA256 will last us until SHA-3 is settled, at which point OpenPGPv5 keys will be available, and we can move forward.

    Link / Reply
  • Daniel Kahn Gillmor 5 years, 2 months ago

    You might also be interested in <a href="http://www.imc.org/ietf-openpgp/mail-archive/msg33235.html" rel="nofollow">David Shaw's response about changing the default signing algorithm</a>.

    Link / Reply
  • Daniel Kahn Gillmor 5 years, 2 months ago

    Ah, and one last thought: getting most DD's to change their keys and preferences is a different task than switching the defaults of gpg. They're not mutually exclusive, and they don't perform the same function. Even if we were to get gpg to switch it's defaults, that would really only affect new gpg installations or users who have not customized their gpg installation at all. For users who have done some gpg configuration already, or who have existing keys with stored/published preferences, a change in the defaults won't actually make a difference.

    So we need both things to happen, eventually. And changing the defaults of a major piece of infrastructure won't happen without serious consideration, testing and probably some politicking too. On the other hand, individuals can change their settings right now, and our experience with the changed settings can help inform the transition process for gpg itself.

    So we should start the transitions available to us today (we'll need to do them eventually anyway), and then move on to the next steps as we have the chance.

    Link / Reply
  • Net Toolbox - SHA-1 Generator 4 years, 11 months ago

    How bad is SHA-1? Shouldn't I store passwords in SHA-1 anymore?

    Link / Reply
  • aigarius 4 years, 11 months ago

    I would say - for new deployments use SHA256.

    Link / Reply
  • Daniel Kahn Gillmor 4 years, 11 months ago

    Net Toolbox:

    To the best of my understanding, storing passwords using SHA-1 relies on the one-wayness of the digest algorithm, not on its collision-resistance.

    that is, if someone gets ahold of your stored (and digested) passwords, it should be very difficult for them to figure out the *undigested* form of the passwords.

    The attacks against SHA-1 have been against the collision-resistance. That is, one entity should not be able to easily generate two different strings which have the same digest. It turns out that SHA-1 isn't as good at preventing this as it should be.

    I don't think this weakness is relevant to a good, salted, password-hashing scheme.

    Link / Reply
  • aigarius 4 years, 11 months ago

    If you have two passwords that have the same hash, then both will work to login. If it is possible to generate a some password for a given hash, then passwords are vulnerable. I do not understand the attack vector to know whether that is what is made plausible.

    Link / Reply
  • nobled 4 years, 11 months ago

    If one-wayness really isn't affected, that isn't any more plausible than before. Exploiting low collision-resistance still requires knowing(or creating) the plaintext you're trying to collide with in the first place, not just the hash.

    Link / Reply
  • Daniel Kahn Gillmor 4 years, 11 months ago

    Aigarius--

    for password hashes which use a <a href="http://en.wikipedia.org/wiki/Salt_(cryptography)" rel="nofollow">salt</a> (and reasonable password hashing approaches these days should use a salt to prevent attacks like <a href="http://en.wikipedia.org/wiki/Rainbow_table" rel="nofollow">rainbow tables</a>), then a regular user can't even inject one side of a known collision, because they don't know the salt used (it should be randomly generated by the system).

    Even if a user *could* inject one side of a known collision into their own entry in the password list, i don't see how that raises a possible exploit in a password lookup for other users, even if they have access to the contents of the list of digested passwords.

    Link / Reply

New Comment

required
required (not published)
optional

Recent Posts

Archive

2014
2013
2012
2011
2010
2009
2008
2007
2006
2005

Categories

Authors

Feeds

RSS / Atom