SHA-(n+1)
There is an even faster attack on SHA-1. It's major news for cryptanalysts. But why do I have to care? Choosing a hash function is orthogonal to other system decisions. Why is it not possible to transparently upgrade the hash function on all the computers in the world, once a replacement is designed and before the attacks become truely practical?
Enabling graceful software evolution would help address many security problems. Cryptanalysis can be done by small team -- making systems evolvable requires coordination by large companies. Unfortunately the problem is more political than technical.
Enabling graceful software evolution would help address many security problems. Cryptanalysis can be done by small team -- making systems evolvable requires coordination by large companies. Unfortunately the problem is more political than technical.
posted by =M at 10:14 PM
2 Comments:
For many applications, simply upgrading the hash function would be difficult, because the hash values themselves remain in use long-term.
Take digital signatures, for example. In practical systems, you sign the hash of the document, not the document itself. If you upgrade the hash function, you'd invalidate all the old signatures (or else you'd keep the old hash function around, but the premise is that the hash function is so insecure that it can't be trusted).
I agree with you that long-term hash values present a problem. However, there's an important class of applications for which the values are used only in the short term -- e.g. TLS and IPsec. For these applications, a capability to "upgrade all the infrastructure at once" would solve the problem.
As for digital signatures, I am getting in over my head here, but I guess you can re-sign the document in the window after the attack is discovered but before it's made practical. Re-signing can be done by anyone, as long as the timestamp can be trusted. Again, the ability to update the infrastructure in a timely manner is critical.
Post a Comment
<< Home