Hacker News new | ask | show | jobs
by lenish 3538 days ago
>reducing it to 98 bits?

Did you mean 198?

198 bits is entirely reasonable assuming a brute force attack is the only option. Were it not we'd be in a panic over AES-128 and AES-192. :)
1 comments
wtbob 3538 days ago
No, hashes generally require twice as many bits in order to avoid birthday attacks — that's why one uses SHA-256 for 128-bit security.

98 bits is still plenty, of course, but it's not 128 bits.

link
lenish 3538 days ago
If we're talking about the actual hash signal uses for this value, then sure, but talking about the number of digits displayed isn't even the right thing to care about, since they're using SHA1 for the hash AFAICT: https://github.com/WhisperSystems/Signal-Android/blob/3.0.0/...
link
wtbob 3538 days ago
SHA1? SHA1 SHA1‽ I'd always thought that OWS had incredibly good crypto — why are they using SHA1? If it's to support relatively short hashes … I just can't even.

There's simply no excuse to choose to use SHA1 in 2016. It's not completely broken, it's probably good enough, but why not just truncate SHA2?

link
pfg 3538 days ago
SHA-1 is fine in this context. SHA-1 isn't as collision-resistant as it was once thought to be, but that's not a property that you care about for this use-case.

The same principle applies to checksums that are sometimes published for binaries - many still use MD5 or SHA-1 - and that's fine too, as (second) preimage resistance is what counts here, rather than collision-resistance.

link