Every problem is simple if you have access to a working time machine. In this case we could just go back in time and implement SHA-2-256 when it was first published rather than a decade later.
Which is precisely what some of us argued for at the time. Rather than looking at how to make the best of the SHA-1 situation, I would like us to spend some time and look at how we avoid ending up in that situation again. And this is a particularly good time to do so because CFRG has just delivered some new EC curves using the rigid construction approach that I think are likely to be widely accepted. As a general principle, I believe that we should always have support for exactly two cryptographic algorithms in Internet applications. One of these should be the current default algorithm, the second a backup in case there is a problem with the first. Use of any other algorithms outside that set should be discouraged for purposes other than experimentation. If some country wants to insist on its own peculiar crypto, they should be clearly seen to be 'on their own'. You do not improve security by adding algorithms that are more secure, you only improve security by withdrawing weak algorithms. As far as key sizes go, I see a need for only two work factors, 'more than adequate' and 'excessive'. I have used AES128 extensively and these days I am using AES256 extensively as well. I have never, ever configured a system for AES192 and can't imagine a reason why I would use it. Either I care about performance or I want the absolute best guarantee of security possible. Looking at the current situation for symmetric ciphers, I note that we have AES and we have something of an emerging consensus on Cha-Cha 20 as a backup (maybe). We also have SHA-2 in widespread use and SHA-3 has been specified but we have not really started on SHA-3 deployment at this point. I would like to see a push for SHA-3 deployment as a backup to SHA-2. While the fact that SHA-2 offers a 512 bit output means this is perhaps not as high a priority as SHA-2 over SHA-1 should have been, I think it would be prudent to offer both as a matter of course. On public key algorithms, it will be a while before we can decommission RSA but I think that point will come as people start to understand that the real advantage of the EC systems doesn't lie in the increased work factor so much as the greater flexibility of the Diffie Hellman crypto system over RSA. Right now there isn't a good way to support end to end security in WebMail using RSA. You end up with keys that have been spread to far too many places to consider the system 'end to end'. Until recently I feared that the problem would be intractable. Then I (re)discovered Matt Blaze's proxy re-encryption scheme from 20 years ago and I can now see several ways to deal with the problem. Given that we already have a move to EC using the NIST curves, adding support for the CFRG curves will mean support for three algorithms rather than the two I consider ideal. But I think this is worth it. If we start deploying the CFRG curves now, we could expect to move to them as the default algorithms by 2020 and decommission RSA sometime after 2025 which is round about the time we can expect some robust QC-resistant approaches to be available. _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
