[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: SKIP Design & Applicability Statement
[Phil Karn wrote:]
>> There is one (important) aspect in which PFS offers a better defense than a
>> non-PFS solution. Namely, if the key-compromise is discovered, the keys may
>> be revoked, thereby protecting against future impersonation attacks and
>> still preserving the secrecy of past encrypted data.
>
> Key compromises don't have to be "discoverable" to make PFS
> worthwhile. The PFS "crank" can be "turned" on a regular basis
> according to local policy just as symmetric keys are periodically
> refreshed. This limits the amount of data that can be compromised at
> once to that sent after the last PFS rekey.
Phil,
That quote of mine is taken from a section that was describing
issues related to servers that contain long-term data.
Yes, in general PFS provides defense against non-discovered key
compromises. However, in case of servers that store long-term data,
there are two sources of the original plaintext. One is the recorded
ciphertext (with capture of the associated traffic key) and the second
is the stored plaintext data on the server's disk.
For example, let's say that the PFS channel transmitted mail
messages from a mail server, which stay stored on the server's
disk. A few months later, your long-term key is compromised.
Of course, the recorded cipher-text is no longer a fruitful
source of the plaintext, given the PFS channel and destruction
of the associated traffic keys. However, the long-term key
compromise allows an attacker to impersonate you, connect to
the mail server, and recover the plaintext from the original
source of the plaintext; namely your mail folder on the server.
If the key-compromise is undiscovered, nothing prevents the
attacker from using this second source of plaintext, and
this is the case I was pointing out as the distinction
between discovered and non-discovered key compromise.
If the data transmitted on the channel is ephemeral data,
e.g. audio/video conferencing etc., then this kind of
attack wouldn't work. But from a server perspective,
this is an important distinction.
Ashar.
Follow-Ups: