6 ms·

> Non-expert ("slashdotter") reaction: > Explain why a simple collision attack is still useless, it's really the second pre-image attack that counts Why is th

> Non-expert ("slashdotter") reaction: > Explain why a simple collision attack is still useless, it's really the second pre-image attack that counts Why is this the "non-expert reaction?" It's correct, right? And why go to the trouble of making a timeline with "Broken" and "Collision found" without a "Second pre-image found"? I'm genuinely puzzled (and have asked it here on HN before [1]), but I unfortunately suspect that an honest answer lies somewhere along these lines: "Second pre-images are a hell of lot more difficult to find than collisions, so if we waited around for a second pre-image to be found we'd never get to dance around like headless chickens and talk about really scary shit (which typically requires a second pre-image) as 'now practical'. That would make the whole field a lot less sexy, and cut into our 'expert' consulting fees..." 1. https://news.ycombinator.com/item?id=13729492 https://news.ycombinator.com/item?id=13729492 EDIT: I'm of course not advocating staying with SHA-1. There's absolutely no good reason to. Even years ago when I was last involved in choosing a cryptographic hash function (even truncated) SHA-256 was obviously a much better choice.

stestagg 10y ago
I had a similar thought, but actually prefer this way. People who understand things well enough will know what first collision means, so can moderate their response. Others who are less familiar with the ridiculous levels of subtlety around this sort of thing are better off being given the simple message that sha1 is now legacy in all cases. Helps to avoid mistakes.
- bjornsing 10y ago
  Simple "truths" are sometimes useful. I can see that. I'm more surprised though at the resentful attitude towards the actual truth (in the non-alternative sense): collisions are useless in many cases and the necessary second pre-image is much more difficult to find. At least in a forum like HN I'd expect intellectual honesty to prevail. EDIT: Removed the incorrect example out of pure shame! :P
  - detaro 10y ago
    /u/pvg linked below how the ability to generate collisions for MD5 was used to obtain a fake CA certificate. It's not obvious to me that this would not work with SHA-1 certificates, and that no other important things we use have similar weaknesses. (Neither do I know for sure that it would work, but "collisions are useless" seems like a dangerous simplification in the other direction. I suspect for many, simply replacing SHA-1 with something deemed better is easier than thoroughly evaluating the risks involved with not doing so)
    - bjornsing 10y ago
      Now we're getting somewhere in terms of intellectual discussion! :) I of course agree we should replace SHA-1. But I still think a more intellectually honest discussion is meaningful. For example, after reading the link you referred to I'm rather convinced that X.509 is pretty seriously flawed, and could easily be redesigned to be collision resistant. Why not talk about that? Why not do it?
      - mook 10y ago
        As I understand it, CAs have mitigated the collision attacks by forcing a random serial number they generate into the certificates. Since that's part of the hash, collision attacks are no longer practical. Doing x509 still means having to parse ASN.1 though, and nobody seems to actually like it.
pvg 10y ago
Take a look at this https://z.cash/technology/history-of-hash-function-attacks.html https://z.cash/technology/history-of-hash-function-attacks.h... Specifically the section 'When collision attacks do matter' and the referenced write-up at http://www.win.tue.nl/hashclash/rogue-ca/ http://www.win.tue.nl/hashclash/rogue-ca/
- bjornsing 10y ago
  Interesting! :) But isn't the real lesson here that X.509 is flawed? Also, as the linked article says: > The bottom line is that no widely-studied hash function has ever succumbed to a (second-)pre-image attack except for one. And there are signatures that are provably resistant to collisions, shouldn't we move to such signatures?
  - pvg 10y ago
    But isn't the real lesson here that X.509 is flawed I don't think that's the case And there are signatures that are provably resistant to collisions, shouldn't we move to such signatures? It's just much simpler to move to a better hash function.
    - bjornsing 10y ago
      > It's just much simpler to move to a better hash function. I don't see how one excludes the other. :P
infinity0 10y ago
Unless your system is very simple (i.e. even if it's moderately simple) it's non-trivial to really be sure that a 2nd-pre-image attack is truly necessary to break any part of your system, and that a collision attack truly cannot break any part of your system.
- bjornsing 10y ago
  Is it...? I've designed a system that used the SHA-256 hash of an RSA public key to establish trust between a client and a server. Client gets the SHA-256 hash as part of its static configuration (out of band). When the client connects to the server over DTLS it gets its public key, and checks that the key hashes to the configured value. Isn't it rather obvious that no third party can attack this system even if they can create an SHA-256 collision? Sure, you can dream up some weird scenario where someone could set up two servers with different RSA public keys that would hash to the same value, so that the client could be fooled into connecting to one when it thought it was connected to the other. But to me it seems quite obvious that that's outside the treat model / irrelevant.
  - infinity0 10y ago
    I'd say this is a "very simple system". Real use-cases are more complex and have to deal with various issues you brushed aside by saying "out of band". Especially in situations where you don't trust what's giving you the hash (e.g. because you haven't authenticated them yet, or because the application inherently means you can't trust them even if you have authenticated them) then collision resistance most likely necessary.
CJefferson 10y ago
Well, looking around the last few days, this SHA-1 collision is breaking various pieces of software (svn in particular). You can't count on two documents with the same hash being the same document. Sure, there is broken, and then even-more broken, but SHA-1 is already, for most practical purposes, useless.
- bjornsing 10y ago
  Sure, if the claims stopped at SHA-1 being "useless" then I have no complaints. But generally the headless chicken dance tends to quickly move on to all kinds of practical exploitability; which simply isn't true.

stestagg 10y ago

I had a similar thought, but actually prefer this way. People who understand things well enough will know what first collision means, so can moderate their response. Others who are less familiar with the ridiculous levels of subtlety around this sort of thing are better off being given the simple message that sha1 is now legacy in all cases. Helps to avoid mistakes.

bjornsing 10y ago
Simple "truths" are sometimes useful. I can see that. I'm more surprised though at the resentful attitude towards the actual truth (in the non-alternative sense): collisions are useless in many cases and the necessary second pre-image is much more difficult to find. At least in a forum like HN I'd expect intellectual honesty to prevail. EDIT: Removed the incorrect example out of pure shame! :P
- detaro 10y ago
  /u/pvg linked below how the ability to generate collisions for MD5 was used to obtain a fake CA certificate. It's not obvious to me that this would not work with SHA-1 certificates, and that no other important things we use have similar weaknesses. (Neither do I know for sure that it would work, but "collisions are useless" seems like a dangerous simplification in the other direction. I suspect for many, simply replacing SHA-1 with something deemed better is easier than thoroughly evaluating the risks involved with not doing so)
  - bjornsing 10y ago
    Now we're getting somewhere in terms of intellectual discussion! :) I of course agree we should replace SHA-1. But I still think a more intellectually honest discussion is meaningful. For example, after reading the link you referred to I'm rather convinced that X.509 is pretty seriously flawed, and could easily be redesigned to be collision resistant. Why not talk about that? Why not do it?
    - mook 10y ago
      As I understand it, CAs have mitigated the collision attacks by forcing a random serial number they generate into the certificates. Since that's part of the hash, collision attacks are no longer practical. Doing x509 still means having to parse ASN.1 though, and nobody seems to actually like it.

pvg 10y ago

Take a look at this https://z.cash/technology/history-of-hash-function-attacks.html https://z.cash/technology/history-of-hash-function-attacks.h... Specifically the section 'When collision attacks do matter' and the referenced write-up at http://www.win.tue.nl/hashclash/rogue-ca/ http://www.win.tue.nl/hashclash/rogue-ca/

bjornsing 10y ago
Interesting! :) But isn't the real lesson here that X.509 is flawed? Also, as the linked article says: > The bottom line is that no widely-studied hash function has ever succumbed to a (second-)pre-image attack except for one. And there are signatures that are provably resistant to collisions, shouldn't we move to such signatures?
- pvg 10y ago
  But isn't the real lesson here that X.509 is flawed I don't think that's the case And there are signatures that are provably resistant to collisions, shouldn't we move to such signatures? It's just much simpler to move to a better hash function.
  - bjornsing 10y ago
    > It's just much simpler to move to a better hash function. I don't see how one excludes the other. :P

infinity0 10y ago

Unless your system is very simple (i.e. even if it's moderately simple) it's non-trivial to really be sure that a 2nd-pre-image attack is truly necessary to break any part of your system, and that a collision attack truly cannot break any part of your system.

bjornsing 10y ago
Is it...? I've designed a system that used the SHA-256 hash of an RSA public key to establish trust between a client and a server. Client gets the SHA-256 hash as part of its static configuration (out of band). When the client connects to the server over DTLS it gets its public key, and checks that the key hashes to the configured value. Isn't it rather obvious that no third party can attack this system even if they can create an SHA-256 collision? Sure, you can dream up some weird scenario where someone could set up two servers with different RSA public keys that would hash to the same value, so that the client could be fooled into connecting to one when it thought it was connected to the other. But to me it seems quite obvious that that's outside the treat model / irrelevant.
- infinity0 10y ago
  I'd say this is a "very simple system". Real use-cases are more complex and have to deal with various issues you brushed aside by saying "out of band". Especially in situations where you don't trust what's giving you the hash (e.g. because you haven't authenticated them yet, or because the application inherently means you can't trust them even if you have authenticated them) then collision resistance most likely necessary.

CJefferson 10y ago

Well, looking around the last few days, this SHA-1 collision is breaking various pieces of software (svn in particular). You can't count on two documents with the same hash being the same document. Sure, there is broken, and then even-more broken, but SHA-1 is already, for most practical purposes, useless.

bjornsing 10y ago
Sure, if the claims stopped at SHA-1 being "useless" then I have no complaints. But generally the headless chicken dance tends to quickly move on to all kinds of practical exploitability; which simply isn't true.