Seems that RFC 2828 only clarifies that not all people agree on a definition. Let me try to clarify, and since I'm just about to complete the lecture and chapter covering this area in my `secure communication and commerce` course (and book), I'll really appreciate comments/corrections. In particular I hope Robert Shirey (editor of rfc2828) is listening (I don't have his e-mail).
First to the specific questions in the original note: > ... Does the "forward security" refer > to the fact that if Eve knows a "K" Alice and Bob used two > weeks ago, she > cannot assume either of their identities for a current > transaction? No. The concepts covering this are `resilience to known-key attack` (when K is a session key derived from long-term `master` key(s)), and `proactive security` (when K denotes all secret & keying info). > Or does it mean that even if Eve knows the current "K" in use by > Alice and Bob's session, she cannot impersonate either of them? I think I didn't understand this as this appears impossible trivially. > Or does it mean something else? Bingo! :-) A reasonable definition for PFS appears in [MOV96], def. 12.16, p. 496 in my copy. Let me give here a slight variant (improvement I hope) to it: A protocol is said to have perfect forward secrecy if compromise of long-term keys at time t does not compromise PAST traffic, i.e. messages sent before t-T, even if attacker has all past (encrypted) traffic available. The value T is a constant (the length of key update period). Some related definitions/concepts: Known-key attack: this is an attack on a protocol which uses designated, multiple `session keys` to encrypt and/or authenticate messages, where all the `session keys` are exchanged using some other secrets (master, long-term keys) never used directly to encrypt or authenticate messages. The attacker is given the value of some session keys. A protocol is resilient to knonw key attack if an attacker with access to all traffic and to some session keys cannot decrypt messages encrypted with a key not given to him, and cannot authenticate messages using a key not given to him. Proactive security recovery: Consider the following scenario. Attacker compromises all keys of a party at time t (without the party being aware of it). A protocol provides proactive security recovery with period T if at t+T, either the attack is detected or security is restored (attacker cannot decrypt or forge future traffic). See formal definition and implementation in [CHH00]. Best regards, Amir Herzberg Please use my new e-mail: [EMAIL PROTECTED] [CHH00] Ran Canetti, Shai Ha-Levi and Amir Herzberg. "Maintaining authenticated communication in the presence of break-ins". In Journal of Cryptography, Vol. 13, No. 1, January 2000, pp. 61-105. Extends version in Proceedings of the sixteenth annual ACM symposium on Principles Of Distributed Computing (PODC), 1997, Pages 15 - 24. [MOV96] Alfred J. Menezes, Paul C. van Oorschot, Scott A. Vanstone, Handbook of Applied Cryptography, CRC Press, ISBN 0-8493-8523-7, October 1996. Available online at http://www.cacr.math.uwaterloo.ca/hac/. --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
