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

The Curious Case of MD5

katelynsills.com

Post reply on HN
Print view View original

121–130 of 173 posts

Re: The Curious Case of MD5

#121

Post by NoboruWataya »

tptacek wrote: post #10

The unsatisfying answer to this is probably that it just doesn't matter. It's not as if evidence chain of custody is assured cryptographically; it's assured by rules and regulations and an adversarial system. If you tried to submit as evidence a forged document vouchsafed with a colliding MD5 hash, you'd be putting your own freedom at risk, because the forgery will be straightforwardly detectable (the real document w…

Exactly. Both sides will have copies of all pertinent evidence, and if their copies conflict in any material way, it will be noticed and investigated and the party that manipulated their copy is going to have a very bad time.

The examples given in the article rely on an attacker manipulating an image prior to it being hashed, or compromising their opponent's database. If you can (and are willing to) do these things, no hashing algorithm will help. They also assume that the hash is literally the only thing anyone will rely on in identifying a document, which is not how it will work in practice. (No witness has ever said "yes there was a letter, I don't remember what it looked like or what it said but I remember its MD5 hash was [...]".)

Re: The Curious Case of MD5

#122

Post by [deleted] »

tgamblin wrote: post #94
hannob wrote: post #85

Earlier quoted context omitted.

> The article mentions the key detail: MD5 is broken for cryptography (collisions) but not for second preimage attacks. The problem with this argument is that people often don't properly understanding the security requirements of systems. I can't count the number of times I've seen people say "md5 is fine for use case xyz" where in some counterintuitive way it wasn't fine. And tbh, I don't understand the urge of peop…

> I can't count the number of times I've seen people say "md5 is fine for use case xyz" where in some counterintuitive way it wasn't fine. I can count many more times that people told me that md5 was "broken" for file verification when, in fact, it never has been. My main gripe with the article is that it portrays the entire legal profession as "backwards" and "deeply negligent" when they're not actually doing anythi…

[deleted]

Re: The Curious Case of MD5

#123

Post by NoboruWataya »

shpx wrote: post #108

MD5 hashes are half the length of the recommended hashing algorithms. This convenience (and the switching cost) is worth more than the theoretical security considerations.

> (and the switching cost)

Yes, I must say I smiled when I saw the author's assertion that moving the entire legal industry to a new hashing algorithm is "trivial".

Re: The Curious Case of MD5

#124

Post by RuggedPineapple »

tgamblin wrote: post #94
hannob wrote: post #85

Earlier quoted context omitted.

> The article mentions the key detail: MD5 is broken for cryptography (collisions) but not for second preimage attacks. The problem with this argument is that people often don't properly understanding the security requirements of systems. I can't count the number of times I've seen people say "md5 is fine for use case xyz" where in some counterintuitive way it wasn't fine. And tbh, I don't understand the urge of peop…

> I can't count the number of times I've seen people say "md5 is fine for use case xyz" where in some counterintuitive way it wasn't fine. I can count many more times that people told me that md5 was "broken" for file verification when, in fact, it never has been. My main gripe with the article is that it portrays the entire legal profession as "backwards" and "deeply negligent" when they're not actually doing anythi…

>And "tech" apparently knows better.

The tech community has a massive problem with Dunning-Kruger, and has for basically ever. Hell two decades ago when I was a young guy working in the field so did I.

I'm not sure if its because the field is basically a young man's game and that's inherent with relative youth, or if there's something deeper going on, but its hard to ignore once you notice it.

That said, the idea that you have a better handle of what's going on in the legal system and the needs/uses legal professionals have then actual people in the legal profession and academics in the legal field is a pretty big leap even with those priors.

Re: The Curious Case of MD5

#125

Post by aljarry »

denton-scratch wrote: post #110

> only broken for encryption It's broken in an adversarial situation: given the hash of evidence-file A, it's possible to construct a file B that gives the same hash. But it would be a different matter entirely to construct a file B that actually looked like a file of evidence relevant to the case. I don't know how lawyers use these hashes, but unless they're being used to detect malicious tampering, I don't see what…

> It's broken in an adversarial situation: given the hash of evidence-file A, it's possible to construct a file B that gives the same hash.

No, that's a second preimage attack. MD5 is safe against preimage & second preimage attacks.

What MD5 is not safe against, is a collision attack: you can create two messages/files with different content, that end up having the same hash.

Re: The Curious Case of MD5

#126

Post by aaron695 »

tptacek wrote: post #10

The unsatisfying answer to this is probably that it just doesn't matter. It's not as if evidence chain of custody is assured cryptographically; it's assured by rules and regulations and an adversarial system. If you tried to submit as evidence a forged document vouchsafed with a colliding MD5 hash, you'd be putting your own freedom at risk, because the forgery will be straightforwardly detectable (the real document w…

[dead]

Re: The Curious Case of MD5

#127

Post by gruez »

moyix wrote: post #59
gruez wrote: post #55

Earlier quoted context omitted.

Generating 2^64 hashes isn't guaranteed to produce a collision, and even if a collision did exist in that set, you're not going to find it by getting a bunch of GPUs to compute 2^64 hashes. There's a huge difference between a haystack that maybe contains a needle, and a needle that's been pulled from the haystack and presented to you. To actually find and identify the collisions you'll need to hook those GPUs up to s…

You can generate pairs of hashes for random inputs and check for collision without storing all of the outputs, no?

That requires way more hashes to be computed though.

Re: The Curious Case of MD5

#128

Post by robertlagrant »

alextingle wrote: post #115
robertlagrant wrote: post #97

> Yes, they say, MD5 is broken for encryption, but since they’re not doing encryption, it’s fine for them to use it. Unless I missed it, this article seems to not refute the most fundamental point: MD5 was never broken for encryption. Hashing is not encryption.

It's broken for hashing too. The point is that MD5 is no good if there's any way an adversary might want to subvert it. It's fine if you just want to use it for hashing your own documents, but as soon as there's an incentive for someone to substitute one document for another, MD5 is problematic. That's certainly the case for encryption, but it's also the case for these legal document records.

I don't disagree, but I think my point still stands.

Re: The Curious Case of MD5

#129

Post by bostik »

krallja wrote: post #16

I actually picked SHA256 for the path-prefix feature in https://jacob.jkrall.net/benfords-law for “NIST compliance.” That is, I didn’t ever want to answer “yes” to a potential customer’s CISO security surveys question like “does your application use any non-NIST-approved hashing functions?” It’s frankly broken that evidence-handling doesn’t have to follow the government's advice about hash function selection!

Funnily enough, I had an interesting discussion with a client's lawyer (who, to their credit, is reasonably tech-savvy) before the holidays. I had redlined "FIPS 140-2" from their contract language. I'll omit the context, because it's too nuanced to be discussed here, but the long and short of it was that she wanted to know why I did that.

I informed her that since FIPS 140-2 is about physical properties of key creation and management, all the relevant layers in a cloud-only solution are simply in the wrong scope. And I added that I am allergic to the string "FIPS" in general. Even having it present in official contract language makes people leap into weird assumptions about supported and allowed algorithms.

Her response? "Oh, that makes sense."

Re: The Curious Case of MD5

#130

Post by tesdinger »

NoboruWataya wrote: post #117
Moru wrote: post #82

Earlier quoted context omitted.

Yes, this is a thing. My arguments have bene shot down with a handwaving several times. "But that would be a crime so then we call our lawyers". Feels like it would be cheaper to just use something secure than to pay a lawyer :-)

If someone commits a crime, it's not the victim of the crime that has to pay for the lawyer to prosecute them.

Kim Yong Un is not going to make a bank transfer out of North Korea to pay for your Lawyers after they hacked you.
Post reply on HN