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 majord...@metzdowd.com