Live data from Hacker News

The first chosen-prefix collision for SHA-1

sha-mbles.github.io

201–210 of 369 posts

Re: The first chosen-prefix collision for SHA-1

#201
post #143

This kind of thing always brings me down a bit. It's not rational, but it does. I mean I truly admire these folks skills, the math involved is obviously remarkable. But I think the feeling is related to not being able to rely on anything in our field. Hard to justify going to the trouble of encrypting your backup. 10 years from now, it might be as good as plain text. It's not security only, nothing seems to work in t…

Last part of this comment made me laugh, trying to imagine someone shouting over Slack "PATCH YOUR BRIDGE, NOW!!"

https://en.m.wikipedia.org/wiki/Citigroup_Center It has been done once after they found a bug.

Re: The first chosen-prefix collision for SHA-1

#202
post #108

This kind of thing always brings me down a bit. It's not rational, but it does. I mean I truly admire these folks skills, the math involved is obviously remarkable. But I think the feeling is related to not being able to rely on anything in our field. Hard to justify going to the trouble of encrypting your backup. 10 years from now, it might be as good as plain text. It's not security only, nothing seems to work in t…

FWIW, a lot of very smart people seem to think that we actually do have symmetric encryption in a state where it "works" and is "understood" and that AES is unlikely to be "broken". What we don't really feel so great about is asymmetric encryption, but at least that feels like something P != NP might imply can be done... hashing algorithms just have this problem where if you glance at the information theory you would…

Yes: for specific examples of this confidence see JP Aumasson’s paper https://eprint.iacr.org/2019/1492 “Too much crypto”

Re: The first chosen-prefix collision for SHA-1

#203

Earlier quoted context omitted.

Isn't that like incredibly simple? Dump your garbage string behind a // or inside an #if 0, restrict the garbage string character set to characters which will not disturb that, and your compiler will whistle while it works.

anyone checking diffs would notice that, or working on the file, etc. it wouldn't survive long

I think active projects would detect this fine - but what if that commit was pushed to lpad and everyone ended up pulling it to local because it's a dependency of a dependency of a dependency in NPM?

Or what if it's a really obscure library for parsing like... pyramidal jpeg2000s, are the library consumers going to be checking the source? Heck, most people already don't check download checksums unless their downloader does it automatically.

Re: The first chosen-prefix collision for SHA-1

#204

This kind of thing always brings me down a bit. It's not rational, but it does. I mean I truly admire these folks skills, the math involved is obviously remarkable. But I think the feeling is related to not being able to rely on anything in our field. Hard to justify going to the trouble of encrypting your backup. 10 years from now, it might be as good as plain text. It's not security only, nothing seems to work in t…

The way I see it, this is what is bad:

> We have tried to contact the authors of affected software before announcing this attack, but due to limited resources, we could not notify everyone.

Many in the 'security industrial complex' make as if they are doing god's work by their 'research' but from a common sense, man/woman on the street, and layman point of view that is not what appears to be going on at all.

What they do is self serving and a detriment. Then they try to justify it in some way as being good when it's not good. It's like going around and compiling a list of doors in a neighborhood that are open, attempting to contact everyone but not getting some people and then saying 'hey look at what we did for you'. Meanwhile if a list were not compiled at all almost all people would do just fine.

> But I think the feeling is related to not being able to rely on anything in our field. Hard to justify going to the trouble of encrypting your backup. 10 years from now, it might be as good as plain text.

Figure out the amount of issues there would be if there was not such open disclosure and an entire industry surrounding breaking things vs. same not being done. That is the issue.

> Imagine an engineer receiving a call at midnight about his bridge because gravity changed during daylight saving in a leap year. That's our field.

No because nobody is able to or actively trying to change gravity (or is able to).

Re: The first chosen-prefix collision for SHA-1

#205

This kind of thing always brings me down a bit. It's not rational, but it does. I mean I truly admire these folks skills, the math involved is obviously remarkable. But I think the feeling is related to not being able to rely on anything in our field. Hard to justify going to the trouble of encrypting your backup. 10 years from now, it might be as good as plain text. It's not security only, nothing seems to work in t…

There's an MC Frontalot song called "Secrets from the Future" and the refrain is "You can't hide secrets from the future." It's something of a useful mantra to remind oneself that if "the future" is a part of your threat model, yes your encryption likely isn't enough because on a long enough timescale it is likely "the future" will crack it. As with any other security issue, the question is "what is your threat model…

The point about archeologists is a good one because it speaks to motive. In general, we should be very supportive of the efforts of distant historians who want to understand what humanity used to be like. We should not WANT to hide secrets from a sufficiently far future. I can't think of any secret that deserves to be hidden from them for any reason besides perhaps modesty.

Re: The first chosen-prefix collision for SHA-1

#206

General questions: (edit: these are indeed general questions, not just about SHA1) Has anyone else been worried about data deduplication done by storage and/or backup systems, considering that they usually use hashes to detect data blocks that are "the same" (without additional metadata) and avoid storing those "duplicate data blocks" again? Doesn't this seem far worse when you also consider that systems like Dropbox…

are there any systems that do sha-1 for dedup? I am only aware of sha-256.

Subversion's dedup was broken by the http://shattered.io/ SHA-1 collision in 2017 https://medium.com/@hyrum/shattered-subversion-7edea4ba289c

Re: The first chosen-prefix collision for SHA-1

#207
post #119
post #87

Earlier quoted context omitted.

The GP was likely hinting at SHA1 being an hashing function, non an encryption function, so just applying sha* wouldn't produce a working backup

It probably will if your data is less than 128 bytes, and you're willing to wait a few decades to decrypt it.

If you're planning to brute-force count through 2^(128x8) possible bit inputs, it will be quite a few decades indeed. And you'll need a few spare solar systems to annihilate to get enough energy to drive your counting engine through that many states.

https://security.stackexchange.com/a/6149/1427

Re: The first chosen-prefix collision for SHA-1

#208
post #85

This kind of thing always brings me down a bit. It's not rational, but it does. I mean I truly admire these folks skills, the math involved is obviously remarkable. But I think the feeling is related to not being able to rely on anything in our field. Hard to justify going to the trouble of encrypting your backup. 10 years from now, it might be as good as plain text. It's not security only, nothing seems to work in t…

At least in our case problem can be solved by re-encryption. Yes, we have to keep up to date with developments before everything is completely broken, but it is not bad as discovering a bridge needs to be rebuilt. Speaking of which, it is common to have to retrofit for earthquakes which probably wasn’t the rule when they built the original bridge

That depends on your threat model. A patient attacker can store all of your encrypted messages till some future point where decryption is economically feasible. Since they already have the weakly encrypted data, encrypting it again doesn't solve anything.

Re: The first chosen-prefix collision for SHA-1

#209

> SHA-1 has been broken for 15 years, so there is no good reason to use this hash function in modern security software. Why are cryptographers always exaggerating things and so out of touch with reality? The first actual collision was like 3 years ago. It's not like the world has been on fire in the meantime, and it's not like SHA-1 is broken for every single possible usage even now. And why the nonsense with "no goo…

Ten years ago I was being pressured into not adding SHA-256 support to a new system because SHA-1 would allow them to use a stack of old crypto cards some idiot bought and hadn't been able to put to use, so they were just collecting dust in a closet somewhere. (They had a max of 1k RSA keys, which also were considered broken at the time, close to it when the cards were new).

This wasn't for some throw-away project. Big, old company. This may be the closest I've come by far to writing software that will still be used after I'm dead (gets a little easier every year, though). If I gave them SHA-1 they'd still be using it for sure.

I refused, and the fact that people were calling MD5 very broken and SHA-1 broken helped.

(A completely different faction was trying to get me to jump straight to SHA-512. I said that was probably overkill, and yes I will implement it but we're using SHA-256 as a default. Then a couple years later it turns out SHA-256 is more resilient than 512 anyway. But what a schizophrenic place.)

Re: The first chosen-prefix collision for SHA-1

#210

> A countermeasure has been implemented in commit edc36f5, included in GnuPG version 2.2.18 (released on the 25th of November 2019): SHA-1-based identity signatures created after 2019-01-19 are now considered invalid. Since SHA-1 was always possible to break, and since NSA probably gets access to big computers and sophisticated techniques before researchers, why doesn't this invalidate every SHA-1 signature ever made…

No, because this is a collision attack (without control over the hash value), not a preimage attack (where you match an existing hash).

We know how to make pairs of new files that collide with each other, but there's no known way of creating a file that collides with something specific that existed before.

Post reply on HN