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

111–120 of 173 posts

Re: The Curious Case of MD5

#111

Post by NavinF »

pxx wrote: post #89
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. Help us out by describing a time when this happened. MD5's weaknesses are easily described, and importantly, it is still (second) preimage resistant. I agree that upgrade is likely your best bet. But I've found the other direction of bad reasoning is a more pernicious trap to fall…

> MD5's weaknesses are easily described, and importantly, it is still (second) preimage resistant

Most devs have no idea what that means, but most devs still need to use hash functions. They need to use primitives that match their mental model of a hash function. Said model is https://en.m.wikipedia.org/wiki/Random_oracle

The usual answer here is "don't roll your own crypto", but in practice abstinence-only cryptography education doesn't work.

Re: The Curious Case of MD5

#112

Post by planede »

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…

> the real document won't have hash colliding artifacts in it

I don't think that hash colliding artifacts would necessarily be obvious. They could be in part of a file that ends up being ignored by parsers of the file format. Or it could be some low level noise in pixel values in scanned documents.

Re: The Curious Case of MD5

#113

Post by franga2000 »

planede wrote: post #112
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…

> the real document won't have hash colliding artifacts in it I don't think that hash colliding artifacts would necessarily be obvious. They could be in part of a file that ends up being ignored by parsers of the file format. Or it could be some low level noise in pixel values in scanned documents.

Both of those are things computer forensics experts are used to looking for and I'm certain even a beginner could find them.

Re: The Curious Case of MD5

#114

Post by akvadrako »

kozak wrote: post #2

I still use MD5 as a 128-bit checksum algorithm that is fast and universally supported and compatible everywhere. In this role it's still useful, just don't expect it to be a cryptographic hash anymore.

Except MD5 is slower than SHA2 on modern PCs / servers.

Re: The Curious Case of MD5

#115

Post by alextingle »

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.

Re: The Curious Case of MD5

#116

Post by planede »

a1369209993 wrote: post #28
Dwedit wrote: post #3

MD5 is incredibly broken. The PDF file PoC||GTFO 0x14 ( https://dl.packetstormsecurity.net/mag/pocgtfo/pocorgtfo14.p... , 42MB large) is a PDF file that can be also run in a NES emulator, and will display its own MD5 hash. The MD5 hash is also shown in the pdf document itself. (Don't download it from archive.org, their copy is altered) The fact that any document can contain its own MD5 hash embedded in there should b…

> a PDF file that can be also run in a NES emulator, and will display its own MD5 hash. The MD5 hash is also shown in the pdf document itself. By that logic, SHA 256 is also broken: $ cat >sha256.py from hashlib import sha256 s = 'from hashlib import sha256\ns = %r\nprint sha256(s%%s).hexdigest()\n' print sha256(s%s).hexdigest() $ sha256sum sha256.py 14cc85c420ced317fdb73e9403ac3f6e1d96d19c70ae0dce8da9b8d96fa0b4d3 sh…

PDF being Turing complete doesn't mean that the program embedded within can access the bytes of the document.

Re: The Curious Case of MD5

#117

Post by NoboruWataya »

Moru wrote: post #82
kmeisthax wrote: post #18

If you could just throw anyone who forged a digital signature in prison, you'd keep using MD5, too. The reason why people like us keep changing everything for security is specifically because we have no access to justice. Computer crimes are international and difficult to prosecute, so you might as well drop an algorithm like a hot potato if anyone - even just nation state actors - could break it. We build our rules…

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.

Re: The Curious Case of MD5

#118

Post by hannob »

pxx wrote: post #89
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. Help us out by describing a time when this happened. MD5's weaknesses are easily described, and importantly, it is still (second) preimage resistant. I agree that upgrade is likely your best bet. But I've found the other direction of bad reasoning is a more pernicious trap to fall…

> Help us out by describing a time when this happened.

Linus Torvalds saying that SHA-1 is okay for git, while it is used for Git signatures as well. Signatures are a classic "you need collission resistance to have safe signatures, but people are often confused about it" case.

Re: The Curious Case of MD5

#119

Post by hannob »

JeffSnazz wrote: post #90
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…

> And tbh, I don't understand the urge of people to defend broken hash functions. Just use a safe one, even if you think you "don't need it". The ideal discourse would not imply a binary sense of "safety" at all, much less for a function evaluated outside the context and needs of its usage....

The thing is: We have a binary definition of safety for cryptographic hash functions, and it works well.

You can add a non-binary sense of safety to cryptographic hash functions, but it makes stuff a lot more complicated for no good reason. If you use the "preimage-safe-but-not-collission-safe" ones, you need to do a lot more analysis to show safety of your whole construction. You could do that, but it gives you no advantage.

Re: The Curious Case of MD5

#120

Post by masklinn »

ivanbakel wrote: post #105
masklinn wrote: post #75

Earlier quoted context omitted.

Because they’re known to be collision resistant (it’s a primary requirement), whereas non-cryptographic hashes are not, so now you need to evaluate each function individually for this property which is a hassle. And an unnecessary one, I doubt the computation of the hash is what genomics are bound on.

But what's the relevance of collision resistance, without a meaningful attack surface?

Ensuring every sequence is uniquely identified.

Although they still want to avoid those, non-cryptographic hash functions often care a lot less about collision resistance, which is a problem when fingerprinting, which is the use case here.

The alternative to a CHF in this case is not a non-cryptographic hash function, it's a dedicated fingerprinting scheme (like Rabin fingerprints). But a CHF is a perfectly good fingerprinting function if you don't have more specialised needs (like rolling hashes).

Post reply on HN