Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

blog.cloudflare.com

Post reply on HN
Print view View original

31–40 of 46 posts

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

#31

Post by pyre »

EGreg wrote: post #16
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…

Can someone explain to me in plain language / layman's terms how a quantum computer is supposed to reverse cryptographic hash functions? What would be the process EXACTLY?

Theoretically, a quantum computer could reduce brute force time to a minimal amount. But really there are no "general purpose" quantum computers at the moment (so far as I know).

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

#32

Post by specialk »

bracewel wrote: post #3

Guh, until CF/FB can provide some data that shows users with no upgrade path are genuinely going to be effected by this, and not connections MITM'd by some crappy AV or other random middlebox the LV proposal seems like a pretty silly idea... https://www.cabforum.org/pipermail/public/2015-December/0064...

There is a great clourflare article [1] that has talked about this before when they first suggested LV certs.

> The seemingly good news is that globally, SHA-2 is supported by at least 98.31% of browsers. Cutting 1.69% off the encrypted Internet may not seem like a lot, but it represents over 37 million people.

There is also an interesting discussion in Security Now #538 [2] there is also a transcript of the show [3]. Skip to page 2 of 39 just where Leo says "Yeah". Android 2.2 and Windows XP SP 2 are on the list of things that don't support SHA-2. These devices exist particularly in the developing world. It sends the wrong message, to the developing world in particular, if we don't support HTTPS for them. It encourages websites in areas where it isn't 1.69% of their users but maybe 5% of their users to just not enforce TLS. TLS with a SHA-1 signed LV cert is better than no security at all.

Facebook's also has a cool server add-on to dynamically serve LV certs to those who need them is very promising. If it is in-production at Facebook it is bound to be good.

[1] https://blog.cloudflare.com/sha-1-deprecation-no-browser-lef...

[2] https://www.grc.com/securitynow.htm

[3] https://www.grc.com/sn/sn-538.pdf

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

#33

Post by paulirwin »

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…

When you say post-quantum certs, do you mean using a technique like key stretching (i.e. PBKDF2) to slow down the brute force time?

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

#34

Post by toast0 »

bracewel wrote: post #3

Guh, until CF/FB can provide some data that shows users with no upgrade path are genuinely going to be effected by this, and not connections MITM'd by some crappy AV or other random middlebox the LV proposal seems like a pretty silly idea... https://www.cabforum.org/pipermail/public/2015-December/0064...

Most releases of Symbian don't support sha2 certs with the system SSL library (which is what the built in browser uses). Many Symbian devices are not upgradable to the release that does support it.

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

#35

Post by agwa »

paulirwin wrote: post #33
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…

When you say post-quantum certs, do you mean using a technique like key stretching (i.e. PBKDF2) to slow down the brute force time?

I mean certs using post-quantum crypto for signatures (e.g. NTRU, hash-based signatures) rather than RSA or ECC, which are utterly defeated by quantum algorithms.

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

#37

Post by aidenn0 »

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?

Presumably you will use a key-stretching algorithm before applying HMAC.

[edit]

So yes, directly using a password in HMAC is a bad idea, and less secure than using some function designed for deriving keys from passwords.

You are confusing two things about sha-1. Assuming a 100% secure cryptographic hash function that is as fast as sha-1, you should not use it directly for hashing passwords (though it can be part of a larger construction like PBKDF2).

This is because the number of passwords you can check per second in an offline attack is related to the speed of the hash function, and bcrypt (and pbkdf2, and scrypt, argon2) are all various ways of slowing down the hashing process.

Similarly it is likely that md5 would be roughly as secure for protecting passwords as sha-256 when used in pbkdf2 because the known weaknesses of md5 would not be of assistance in performing a dictionary attack against a hashed password.

If you have a high-quality key then HMAC is secure without needing the hash function to be slow, so if you wanted to use a password with HMAC, you would first use a KDF to generate a high-quality key from the password, and then use the key in hmac. This is similar for any cryptographic tool that wants a high-quality key as input (i.e. most of them).

[edit2]

A shorter answer is that HMAC is secure and fast because its input key already has sufficient entropy. bcrypt is slow because its whole point is to make it difficult to attack a key with low entropy.

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

#38

Post by jud_white »

aidenn0 wrote: post #37
jud_white wrote: post #27

Earlier quoted context omitted.

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?

Presumably you will use a key-stretching algorithm before applying HMAC. [edit] So yes, directly using a password in HMAC is a bad idea, and less secure than using some function designed for deriving keys from passwords. You are confusing two things about sha-1. Assuming a 100% secure cryptographic hash function that is as fast as sha-1, you should not use it directly for hashing passwords (though it can be part of a…

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.

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

#39

Post by yuhong »

specialk wrote: post #32
bracewel wrote: post #3

Guh, until CF/FB can provide some data that shows users with no upgrade path are genuinely going to be effected by this, and not connections MITM'd by some crappy AV or other random middlebox the LV proposal seems like a pretty silly idea... https://www.cabforum.org/pipermail/public/2015-December/0064...

There is a great clourflare article [1] that has talked about this before when they first suggested LV certs. > The seemingly good news is that globally, SHA-2 is supported by at least 98.31% of browsers. Cutting 1.69% off the encrypted Internet may not seem like a lot, but it represents over 37 million people. There is also an interesting discussion in Security Now #538 [2] there is also a transcript of the show [3]…

The Android one is an error from a GlobalSign page later corrected. Android uses OpenSSL I think and has supported SHA2 certificates since 1.0.

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

#40

Post by aidenn0 »

jud_white wrote: post #38
aidenn0 wrote: post #37

Earlier quoted context omitted.

Presumably you will use a key-stretching algorithm before applying HMAC. [edit] So yes, directly using a password in HMAC is a bad idea, and less secure than using some function designed for deriving keys from passwords. You are confusing two things about sha-1. Assuming a 100% secure cryptographic hash function that is as fast as sha-1, you should not use it directly for hashing passwords (though it can be part of a…

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.

Post reply on HN