Hacker News Reader

Comment by rowbin | Hacker News Reader

Interesting, I'd love to see some more opinions on this. I find the instant "MD5 is broken, don't use it advice" harmful. Not all applications are security related or need absolute highest speed. I actually had use cases in multiple hobby projects, but of course that doesn't there are many.

For example in a distributed event based LAN chat, I used MD5 for an "integrity chain". Every new event id is the hash of the old event id + some random bytes. This way you can easily find the last matching event two systems have in common. Just a random id isn't enough, when two instances integrate an event from a third system, while one of the two added a new event just before that.

No security needed, speed doesn't matter much, it is not designed for high throughput. MD5 seems like a very good choice, because it's easy to work with and can be verified on every system.

View on HN

As far as I know and that information is probably way out of date, such an integrity chain on MD5 could be compromised as someone would be able to switch out some important bytes (switch the byte with a toggle on "I do NOT want to buy this very expensive washing machine") while keeping the hash value intact. So using MD5 as a signature check on documents like invoices going through unsafe channels is not safe.

But this is a security case that requires a hostile actor. If the problem is just checking for data integrity or in this case data identity without there being a danger for manipulation, MD5 should perform fine. I don't see a problem with your use case. I am no expert here and there are probably more optimal hashes, but MD5 has the advantage of being widely implemented in all kinds of systems.

Because understanding the intrinsic weakness of hashes isn't trivial, many just recommend "MD5 is broken, don't use it". I think this is just to be on the safe side. Many applications would probably be fine, but because to err on the side of caution is safer, people sometimes say that MD5 is the worst hash function ever conceived.

You are using the security argument again. It is not used in an adverserial context. You are correct, that this is not secure. And messages can be tampered with. But this is not the application. The threat model of the application is that everything happens in a private context without adversaries. The communication is end-to-end encrypted and every participant of the chat has total control and is allowed to change everything in the chat, even messages from other users. So there is no point in protecting again adversaries that have access have to the secure channel, because they are already allowed to do anything, even if the hash were cryptographically secure, they are allowed to change everything. The integrity is only for synchronization, so that every participant can easily verify the state of the event history up to a specific point.

Reply on news.ycombinator.com