Why it’s harder to forge a SHA-1 certificate than to find a SHA-1 collision • Hacker News Board

Re: Why it’s harder to forge a SHA-1 certificate than to find a SHA-1 collision

#41

Post by guelo » Wed, Dec 23, 2015, 5:27 AM UTC

agwa wrote: post #4

We're lucky that hash collision attacks have a relatively simple mitigation like this. (Although you have to trust CAs to follow the rules and implement it properly, and events of the last few years indicate that CAs need to have as few things to screw up as possible.) However, we're not always going to be so lucky. The next major transition in digital certificates could very well be to post-quantum crypto due to adv…

Also when we develop cold fusion, faster than light time travel, and exploit the many worlds theory crypto will be harder.

Re: Why it’s harder to forge a SHA-1 certificate than to find a SHA-1 collision

#42

Post by KirinDave » Wed, Dec 23, 2015, 6:30 AM UTC

nly wrote: post #6

KirinDave wrote: post #2

It's worth noting that SHA1 is also suitable for use in HMAC on older hardware, security is not significantly compromised by SHA1's properties. You can move to more modern algorithms, but there isn't a pressing need to remove SHA1 implementations for that application.

Aren't there more secure hashes than SHA1 that are also faster? Like BLAKE2, which can be configured for 128 or 160 bit output?

The security of hmac is not based strictly on the collision resistance of the hashing function.

Oh, and if your HMAC seals over an origin timestamp which your API respects, you've gone and made things even harder.

Re: Why it’s harder to forge a SHA-1 certificate than to find a SHA-1 collision

#43

Post by KirinDave » Wed, Dec 23, 2015, 6:32 AM UTC

aidenn0 wrote: post #40

jud_white wrote: post #38

Earlier quoted context omitted.

Thanks for the varying levels of explanation (thanks to viraptor too). I think part of the reason I was confused is because GitHub's web hook setup allows for a supplied shared secret which, based on what I understand from above, is not as secure as it could be unless the user ensures the shared secret has sufficient entropy. If I'm still not getting it please let me know. Thanks again.

A quick 30s scan of the webhooks docs looks like that is correct; if you used e.g. 12345 as your secret, you would be susceptible to a dictionary attack from anybody who was able to record a message, on the order of 10s of billions of keys per second can be tested with a multi-GPU setup. I suspect that the web hooks typically run over TLS, so recording the plaintext of a request would be a challenge in and of itself.

If your shared secret is vulnerable to brute forcing, it's vulnerable to brute forcing. An easy fix for this: generate your shared secret by hashing or salthashing a low-entropy password.

As a general rule though, HMAC is used with randomly generated secrets. I don't know why GitHub doesn't just tell you the secret.

Amazon's implementation is much more correct.

Re: Why it’s harder to forge a SHA-1 certificate than to find a SHA-1 collision

#44

Post by [deleted] » Wed, Dec 23, 2015, 10:42 AM UTC

[deleted]

Re: Why it’s harder to forge a SHA-1 certificate than to find a SHA-1 collision

#45

Post by leereeves » Wed, Dec 23, 2015, 11:18 AM UTC

Can an attacker bypass this by using the serial number and validity period from an already issued certificate?

Re: Why it’s harder to forge a SHA-1 certificate than to find a SHA-1 collision

#46

Post by taejo » Wed, Dec 23, 2015, 5:56 PM UTC

jud_white wrote: post #27

KirinDave wrote: post #2

It's worth noting that SHA1 is also suitable for use in HMAC on older hardware, security is not significantly compromised by SHA1's properties. You can move to more modern algorithms, but there isn't a pressing need to remove SHA1 implementations for that application.

I have a question I haven't been able to find an answer to, hopefully someone here can help. Why is HMAC+(hash) considered secure, while being considerably faster than say bcrypt with a cost of 12? For example, if a service used a user provided password to validate a "secret" (what would normally be the signed message), is that less secure than bcrypt? If so, what makes guessing the secret used in HMAC difficult?

bcrypt and HMAC fill different roles and have different security properties: bcrypt is a key-derivation function, and HMAC is a message authentication code. They're not comparable. In particular, HMAC should be used with a high-quality key; bcrypt is for deriving high-quality keys from lower-quality keys.