3 ms·
I don't see how hash truncation prevents the attack. Regarding timestamp, precise timestamp is sent in clear text in another event field (currentTime_ms) so it
by codedokode 5y ago
I don't see how hash truncation prevents the attack.
Regarding timestamp, precise timestamp is sent in clear text in another event field (currentTime_ms) so its presence doesn't prevent message content recovery.
- yunohn 5y ago> its presence doesn't prevent message content recovery The TS is the “salt” & hence defeats rainbow tables, unless somehow it’s feasible to infinitely store them for every combination of message & time for the past/future. > how hash truncation prevents the attack It literally deletes half the information you have for the attack. You CANNOT /perfectly/ compute the original text for a truncated hash, you’ll have innumerable clashes. So yes, any attack is impossible/infeasible.
- gpderetta 5y agoThe problem is that the text that is hashed is not random (like a salted password would be) and the space of all sensible clear texts is much much smaller and possibly amenable to brute force. Also, storing the hash means that messages are irrefutable.
- yunohn 5y agoPasswords are even less random than sensible texts - the whole discussion around rainbow tables and salting is normally about cracking passwords. But do you disagree with my claims? Do you have any sources to backup their invalidity?