4 ms·
This looks impressive. Is an MD5 hash still "safe" if you use a salt? Can an attacker generate a collision having the MD5 hash without knowing the salt?
by XCSme 4y ago
This looks impressive.
Is an MD5 hash still "safe" if you use a salt? Can an attacker generate a collision having the MD5 hash without knowing the salt?
- Retr0id 4y ago> Can an attacker generate a collision having the MD5 hash without knowing the salt? Depending on how the salt is applied, yes.
- XCSme 4y agoLet's say I append 128 random bytes to the input string.
- Retr0id 4y agoTrivially broken. Ignoring the adler32 and crc32 checksums, I can retroactively adjust the hex digits in the image without affecting the resultant hash, even with a suffix - as long as I know what the final hash is.
- imranhou 4y agoAssuming that you are able to easily trigger the hashing with salt enough times for you to adjust the image... right? Any idea (ballpark) how many such test iterations would you need? Great work btw!
- Retr0id 4y agoApproximately 1
- XCSme 4y agoI was talking about basic string hashing (not images), so I guess that would be even simpler. > I can retroactively adjust the hex digits in the image without affecting the resultant hash My point is: I give you a hash H, can you generate a collision by finding a string X, so that when I append an (unknown to you) salt S then MD5(X + S) = H. EDIT: To make it clear, the only feedback you get when you try X is whether the final hash matches, you don't get the resulting hash each time.
- jgeralnik 4y agoMD5 is not broken in the way you think it is. Even without salting if you give a hash H there is basically no way to recover a string that hashes to it other than randomly trying strings 2^128 times. What you can do trivially is find 2 strings X1 and X2 such that md5(X1) == md5(X2). In this case seeding the way you described won't help because md5(X1+S) will equal md5(X2+S) due to the way MD5 works
- kadoban 4y agoTrying to make md5 safe is annoying enough, and has few enough benefits, that it's basically a waste of time. I _think_ that would do it though, if your salt is private and secure enough and you apply it the right way. I easily could be missing an attack though, so take with a large grain of salt (heh).
- londons_explore 4y agoThere are no known attacks against MD5 as long as the data you hash is not controllable by the attacker. You should still use a different hash algorithm though.
- mrb 4y agoThat's like saying "There are no known attacks against MD5 as long as you don't try to attack it"
- saagarjha 4y agoNot really. This actually provides useful properties in practice, though you should still probably not rely on that.
- londons_explore 4y agoUsecase where this property is useful: Developer writes some code and publishes it. It's big, so he puts it on an untrusted CDN, and also publishes an MD5 hash of the code (not via the CDN). User downloads the code from the CDN, and verifies the published hash matches. A malicious CDN couldn't make an evil file with a matching hash, based on known attacks against MD5, unless they could influence the Developer to get certain data into the original file.
- mrb 4y ago"malicious CDN couldn't make an evil file" Then the CDN, by definition, would control the data that the end-user (downloader) hashes. But I understand the confusion: londons_explore meant to write "there are no known (practical) preimage attacks" against MD5, which is true, since the only theoretical preimage has a complexity 2^123 or so.
- deleted 4y ago[deleted]
- oconnor663 4y agoMD5 is vulnerable to both length extension and chosen prefix collisions, so I think an attacker can generate a collision even without knowing the prefix, just by observing a single output. That said, I'm also pretty sure HMAC-MD5 is still unbroken in practice.