Seems people like bottom post around here.

On Tue, Mar 23, 2010 at 8:51 PM, Nicolas Williams
<> wrote:
> 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:
>> >
>> >
>> >
>> > 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

In anon-ip (a zero-knowledge systems internal project) and cebolla [1]
we provided forward-secrecy (aka backward security) using symmetric
re-keying (key replaced by hash of previous key).  (Backward and
forward security as defined by Ross Anderson in [2]).

But we did not try to do forward security in the sense of trying to
recover security in the event someone temporarily gained keys.  If
someone has compromised your system badly enough that they can read
keys, they can install a backdoor.

Another angle on this is timing attacks or iterative adaptive attacks
like bleichenbacher's attack on SSL encryption padding.  If re-keying
happens before the attack can complete, perhaps the risk of a
successful so far unnoticed adaptive or side-channel attack can be
reduced.  So maybe there is some use.

Simplicity of design can be good too.

Also patching SSL now that fixes are available might be an idea.  (In
my survey of bank sites most of them still have not patched and are
quite possibly practically vulnerable).



The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to

Reply via email to