"Against Rekeying"

[Nicolas Williams]

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.

There may be reasons for re-keying, but the commonly given one that a
given key gets weak over time from use (meaning the attacker can gather
ciphertexts) and just the passage of time (during which an attacker
might brute force it) does not apply to modern crypto.

Ensuring that a protocol that uses modern crypto also supports re-keying
only complicates the protocol, which adds to the potential for bugs.

Consider SSHv2: popular implementations of the server do privilege
separation, but after successful login there's the potential for having
to do re-keys that require privilege (e.g., if you're using SSHv2 w/
GSS-API key exchange), which complicates privilege separation.  But for
that wrinkle the only post-login privsep complications are: logout
processing (auditing, ...), and utmpx processing (if you want tty
channels to appear in w(1) output; this could always be handled in ways
that are not specific to sshd).  What a pain!  (OTOH, the ability
delegate fresh GSS credentials via re-keying is useful.)

Nico
-- 

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com