[Cryptography] Crypto Standards v.s. Engineering habits - Was: NIST about to weaken SHA3?

[Nico Williams]

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
--