On Sat, Oct 05, 2013 at 09:29:05PM -0400, John Kelsey wrote: > One thing that seems clear to me: When you talk about algorithm > flexibility in a protocol or product, most people think you are > talking about the ability to add algorithms. Really, you are talking > more about the ability to *remove* algorithms. We still have stuff > using MD5 and RC4 (and we'll probably have stuff using dual ec drbg > years from now) because while our standards have lots of options and > it's usually easy to add new ones, it's very hard to take any away.
Algorithm agility makes it possible to add and remove algorithms. Both, addition and removal, are made difficult by the fact that it is difficult to update deployed code. Removal is made much more difficult still by the need to remain interoperable with legacy that has been deployed and won't be updated fast enough. I don't know what can be done about this. Auto-update is one part of the answer, but it can't work for everything. I like the idea of having a CRL-like (or OCSP-like?) system for "revoking" algorithms. This might -in some cases- do nothing more than warn the user, or -in other cases- trigger auto-update checks. But, really, legacy is a huge problem that we barely know how to ameliorate a little. It still seems likely that legacy code will continue to remain deployed for much longer than the advertised service lifetime of the same code (see XP, for example), and for at least a few more product lifecycles (i.e., another 10-15 years before we come up with a good solution). Nico -- _______________________________________________ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
