Re: [Cfrg] how can CFRG improve cryptography in the Internet?

Watson et al:

> 
> There is an assumption being made here: that algorithms will age badly.
> This assumption is largely unwarranted.
> First off, software does not decay. It does not develop security
> problems spontaneously. Protocols with reductions remain secure so long
> as the fundamental problems they reduce to remain hard.
> 

I'd disagree slightly in that Moore's law says that the computational cost
of an attack halves every 18 months.  If one assumes Moore's law will continue
to apply, eventually its rising tide will engulf any given choice of parameter 
sizes.  Certainly Moore's Law must eventually grind to a halt, but over the 
years I've lost good money by drawing a line in the sand that I bet Moore's 
law could never get past.

There are, of course, more pressing issues than worrying about Moore's law.

> -----Original Message-----
> From: Cfrg [mailto:cfrg-bounces@irtf.org] On Behalf Of Watson Ladd
> Sent: Tuesday, February 11, 2014 12:48 AM
> To: dan@geer.org
> Cc: cfrg@irtf.org
> Subject: Re: [Cfrg] how can CFRG improve cryptography in the Internet?
> 
> On Mon, Feb 10, 2014 at 9:09 PM,  <dan@geer.org> wrote:
> >
> >  > No-longer-deemed-secure algorithms aren't the only security
> > problems  > facing out-of-date cryptographic software.  So why not go
> > one step  > further and make the cryptographic software itself
> expire?
> >
> >
> > Might I extend this to crypto-in-hardware-in-embedded-systems?
> >
> > In other words, absolutely all embedded systems must either have a
> > remote upgrade capability or a not-to-exceed pre-defined lifetime.
> 
> There is an assumption being made here: that algorithms will age badly.
> This assumption is largely unwarranted.
> First off, software does not decay. It does not develop security
> problems spontaneously. Protocols with reductions remain secure so long
> as the fundamental problems they reduce to remain hard.
> 
I'd disagree slightly in that Moore's law says that the computational cost
of an attack halves every 18 months.  If one assume Moore's law will continue
to apply, inevitably the rising tide will engulf any give choice of parameter
sizes.  Of course Moore's Law must eventually grind to a halt, but over the
years I've lost good money by drawing a line in the sand that I bet Moore's 
law could never get past. 

> The reasons why a piece of hardware made in 1996 would, 17 years later,
> be no longer secure if properly designed in the first place, would
> likely be the hash function. IDEA remains secure, even with the small
> block causing fun at 4 GB. Blowfish is unlikely to have been done in
> hardware. Triple DES would be fine today, but single DES would have
> been on the way out due to the small 2^56 key size.
> 
> Public key would likely be RSA. The big advances in algorithms were all
> known at that point, so one just has to play the Moore's law game.
> For ECC the security situation looks the same, and for Diffie-Hellman
> over prime fields, I don't recall.
> 
> The hash function would have died: it would have been MD5. With any
> luck they would have used signature schemes that avoid falling to
> simple collisions, but that's unlikely for RSA.
> 
> The big problem is that the standards were and are so terrible. SSL v3
> made 3 mistakes: predictable IVs, a complex state machine, and exposing
> a CBC padding oracle. PKCS 1.5 had lots wrong with it. For this
> hardware to be useful, it wouldn't have made it to 2013 without massive
> problems beyond the weak hash.
> 
> Sincerely,
> Watson Ladd
> 
> --
> "Those who would give up Essential Liberty to purchase a little
> Temporary Safety deserve neither  Liberty nor Safety."
> -- Benjamin Franklin
> 
> _______________________________________________
> Cfrg mailing list
> Cfrg@irtf.org
> http://www.irtf.org/mailman/listinfo/cfrg