4 ms·

First SHA1 was shattered. https://shattered.io https://shattered.io Now it's reduced to shambles. It's time to stop using SHA1. (HMAC-SHA1 is still okay.)

tptacek 7y ago
It's OK in the sense that it's not a security emergency, but, don't use HMAC-SHA1 (or HMAC-MD5, which is also in the same sense "ok").
- CiPHPerCoder 7y ago
  Quite right.
- wolf550e 7y ago
  When do you expect it would be feasible to forge HMAC-SHA1 or HMAC-MD5?
  - nneonneo 7y ago
    All current collision attacks assume you know the intermediate hash values (IHVs). With a typical HMAC forgery scenario, you don’t know the secret key so you don’t know the IHV corresponding to the inner hash application, which means existing collision attacks are not applicable. If you do know the secret key, collisions are easy, but probably pointless since you can already forge HMAC signatures for anything you want. Still, even if there’s no way to break HMAC-SHA1 (or even HMAC-MD5) faster than the birthday attack, you should still prefer to pick a better hash algorithm for safety.
    - a1369209993 7y ago
      Also, you shouldn't use a different hash algorithm for HMAC than for other hashing, because that increases the amount of security-critical code you have, which directly increases the chance that there's a bug in your security-critical code.
      - tptacek 7y ago
        It's pretty unlikely that you're going to have a bug in your SHA1 and SHA2 cores, for whatever that's worth to you. Virtually nobody implements them by hand.
        kbwt 7y ago
        Anecdotally I know of one very popular application that has a bug in their SHA-1 implementation causing it to effectively only perform a single round.
        wolf550e 7y ago
        Would that make it only interoperable with itself, and not have the security a correct implementation of SHA1 provides? Is it a security bug (i.e. is there anything worth stealing by breaking their not-quite-SHA1-hash)?
        kbwt 7y ago
        The application is using a proprietary client/server protocol, so it already lacks lacks any kind of interoperability. In this specific case, it's unclear whether the bug has direct security implications. The broken SHA-1 is used on some user-controlled data that gets XORed onto the server's decryption of a user-specified payload before being passed into an RC4 key schedule. It's certainly plausible that this might produce a server-assisted privacy compromise of other users' sessions.

tptacek 7y ago

It's OK in the sense that it's not a security emergency, but, don't use HMAC-SHA1 (or HMAC-MD5, which is also in the same sense "ok").

CiPHPerCoder 7y ago
Quite right.
wolf550e 7y ago
When do you expect it would be feasible to forge HMAC-SHA1 or HMAC-MD5?
- nneonneo 7y ago
  All current collision attacks assume you know the intermediate hash values (IHVs). With a typical HMAC forgery scenario, you don’t know the secret key so you don’t know the IHV corresponding to the inner hash application, which means existing collision attacks are not applicable. If you do know the secret key, collisions are easy, but probably pointless since you can already forge HMAC signatures for anything you want. Still, even if there’s no way to break HMAC-SHA1 (or even HMAC-MD5) faster than the birthday attack, you should still prefer to pick a better hash algorithm for safety.
  - a1369209993 7y ago
    Also, you shouldn't use a different hash algorithm for HMAC than for other hashing, because that increases the amount of security-critical code you have, which directly increases the chance that there's a bug in your security-critical code.
    - tptacek 7y ago
      It's pretty unlikely that you're going to have a bug in your SHA1 and SHA2 cores, for whatever that's worth to you. Virtually nobody implements them by hand.
      - kbwt 7y ago
        Anecdotally I know of one very popular application that has a bug in their SHA-1 implementation causing it to effectively only perform a single round.
        wolf550e 7y ago
        Would that make it only interoperable with itself, and not have the security a correct implementation of SHA1 provides? Is it a security bug (i.e. is there anything worth stealing by breaking their not-quite-SHA1-hash)?
        kbwt 7y ago
        The application is using a proprietary client/server protocol, so it already lacks lacks any kind of interoperability. In this specific case, it's unclear whether the bug has direct security implications. The broken SHA-1 is used on some user-controlled data that gets XORed onto the server's decryption of a user-specified payload before being passed into an RC4 key schedule. It's certainly plausible that this might produce a server-assisted privacy compromise of other users' sessions.