"[Not] Against Rekeying"

[james hughes]

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

On Mar 23, 2010, at 4:23 PM, Adam Back wrote:

> 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]).

The paper on Cebolla[4] states that "Trust in symmetric keys diminishes the longer they are used in the wild. Key rotation, or re-keying, must be done at regular interfals to lessen the success attackers can have at crypt-anayzing the keys". This is exactly the kind of justification that the Dkr post and most of the comments agree is flawed.

It goes on to state what was said about new keys being derived from old keys.

[4] http://www.cypherspace.org/cebolla/cebolla.pdf


Hmm. Interesting. Learn one key, have them all for the future. Wow. Yes, that is Ross' definition of backward security, and clearly does not meet Ross' definition of forward security. In reading the paper, it seems like this system is: Crack one key, you're in forever. A government's dream for an anonymity service. Ross' definitions for, backwards, forwards makes sense from a terminology point of view, but IMHO without both, it is not secure.

Sure one can talk about attack scenarios, and that just proves the tautology that we don't know what we don't know (or don't know what has not been invented yet). There is no excuse to bad crypto hygiene. I don't know why someone would build a system with K_i+1 = h(K_i) when there are so many good algorithms out there.


> 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.

I agree with the Ekr posting, but not the characterization above. The Ekr posting says "[rekey for] Damage limitation If a key is disclosed" and "This isn't totally crazy". The statement of fact is that if a key is compromised, a rekey limits the scope of the compromise.

The Ekr posting said nothing about how the key was disclosed. Yes, if you have root on the machine an have mounted an active attack, all bets are off, but there are other ways for key disclosure to happen (as was discussed in the Ekr posting).

For example a cold boot attack [3] can be used to recover a communications session key (instead of a disk key). If that key has been used for a particularly long time, and if one assumed that the attacker had the opportunity to  record all the ciphertext, then one must expect that all of that information can now be read.

[3] http://en.wikipedia.org/wiki/Cold_boot_attack

[The comments about breaking keys is deleted. I agree with the original posting and everyone else that changing a key OF A MODERN CIPHER to eliminate algorithm weaknesses is not a valuable reason to rekey.]

On Mar 23, 2010, at 2:42 PM, Jon Callas wrote:

> If you need to rekey, tear down the SSL connection and make a new one. There should be a higher level construct in the application that abstracts the two connections into one session.

I agree (but as a nit, we can reverse the order. Create a completely new session and just move the traffic to the new connection.)

Limiting the scope of a key compromise is the only justification I can see for rekey. That said, limiting the scope of the information available because of a key compromise is still a very important consideration. 

Jim

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