60 digits have 199 bits of security, so I suppose that's mostly okay, right? Does the birthday paradox apply here, reducing it to 98 bits?
60 digits have 199 bits of security, so I suppose that's mostly okay, right? Does the birthday paradox apply here, reducing it to 98 bits?
If I can generate a key that hashes to the same value as your key, I can convince anyone I am you. If I can generate a second collision for a third party's key, I can convince you you are talking to that third party, as well. Generating hash collisions is, as I understand it, pretty well modelled with the birthday paradox (and variations like the one I linked). Physical proximity seems entirely unrelated.
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. :)
98 bits is still plenty, of course, but it's not 128 bits.
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?
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.