4 ms·

Yes, it is 128-bit hash. 128 bits are enough to recover a message made of 3-4 words. Some messages are build by template, for example, a message from a bank say

Yes, it is 128-bit hash. 128 bits are enough to recover a message made of 3-4 words. Some messages are build by template, for example, a message from a bank saying "Your PIN code is XXXX". In this case, it is possible to recover the PIN code using 128-bit hash as the number of possible PIN codes is less than 2^128.

RL_Quine 5y ago
Probably given the sender is always the same for those, the work to recover the text is probably literally just the key space of the code. Like, 1M hashes in a lookup table for a normal bank 2FA code. Recoverable in microseconds.
yunohn 5y ago
It’s a 256bit hash of message+timestamp truncated to 128bit. The attack you’re describing is literally impossible.
- 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 ago
      The 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 ago
        Passwords 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?

RL_Quine 5y ago

Probably given the sender is always the same for those, the work to recover the text is probably literally just the key space of the code. Like, 1M hashes in a lookup table for a normal bank 2FA code. Recoverable in microseconds.

yunohn 5y ago

It’s a 256bit hash of message+timestamp truncated to 128bit. The attack you’re describing is literally impossible.

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 ago
    The 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 ago
      Passwords 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?