2 ms·

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 so

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.

rowbin 1y ago
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.

rowbin 1y ago

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.