4 ms·
>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 ov
by lenish 10y 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. :)
- wtbob 10y agoNo, 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.
- lenish 10y agoIf 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/src/org/thoughtcrime/securesms/crypto/PublicKey.java#L87 https://github.com/WhisperSystems/Signal-Android/blob/3.0.0/...
- wtbob 10y agoSHA1? 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?
- pfg 10y agoSHA-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.