[145173] in cryptography@c2.net mail archive
Re: "Against Rekeying"
daemon@ATHENA.MIT.EDU (Nicolas Williams)
Tue Mar 23 16:00:28 2010
Date: Tue, 23 Mar 2010 14:51:41 -0500
From: Nicolas Williams <Nicolas.Williams@Sun.COM>
To: "Perry E. Metzger" <perry@piermont.com>
Cc: cryptography@metzdowd.com
In-Reply-To: <20100323154238.GH21244@Sun.COM>
On Tue, Mar 23, 2010 at 10:42:38AM -0500, Nicolas Williams wrote:
> On Tue, Mar 23, 2010 at 11:21:01AM -0400, Perry E. Metzger wrote:
> > Ekr has an interesting blog post up on the question of whether protocol
> > support for periodic rekeying is a good or a bad thing:
> >
> > http://www.educatedguesswork.org/2010/03/against_rekeying.html
> >
> > I'd be interested in hearing what people think on the topic. I'm a bit
> > skeptical of his position, partially because I think we have too little
> > experience with real world attacks on cryptographic protocols, but I'm
> > fairly open-minded at this point.
>
> I fully agree with EKR on this: if you're using block ciphers with
> 128-bit block sizes in suitable modes and with suitably strong key
> exchange, then there's really no need to ever (for a definition of
> "ever" relative to common "connection" lifetimes for whatever protocols
> you have in mind, such as months) re-key for cryptographic reasons.
I forgot to mention that I was referring to session keys for on-the-wire
protocols. For data storage I think re-keying is easier to justify.
Also, there is a strong argument for changing ephemeral session keys for
long sessions, made by Charlie Kaufman on EKRs blog post: to limit
disclosure of earlier ciphertexts resulting from future compromises.
However, I think that argument can be answered by changing session keys
without re-keying in the SSHv2 and TLS re-negotiation senses. (Changing
session keys in such a way would not be trivial, but it may well be
simpler than the alternative. I've only got, in my mind, a sketch of
how it'd work.)
Nico
--
---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo@metzdowd.com
