Re: Forward Secrecy

[Ian G <[e-mail]>]

Hal Finney wrote:

>http://www.links.org/dnssec/draft-brown-pgp-pfs-04.txt.
>
>   Using a series of encryption keys, each with a short lifetime,
>   reduces the information revealed by the compromise of any one private
>   key because each key protects less data.  If expired keys are
>   securely deleted, attackers will never be able to retrieve them to
>   decrypt captured ciphertext.  Therefore when a public encryption key
>   expires, an OpenPGP client MUST securely wipe the corresponding
>   private key [4].
>
>I don't agree that OpenPGP clients MUST always securely wipe expired
>private keys.  In the context of a user who wants PFS, this makes sense.
>But for a user who wants to be sure he can decrypt his messages, this
>is a bad policy.  For example, some mail systems may store the messages
>in encrypted form, and he needs to keep the key around in order to read
>those messages in the future.
>  
>

I'm inclined to think that this would be bad
practice.  If a mail system were to want to
keep mail around for encryption purposes,
I'd say it should re-encrypt the packet using
a local key.

The alternate - saving the encrypted message
in the form as it was sent over the network -
leads to all sorts of key management trouble
later on.  It means that keys have to be kept
around for as long as the oldest email, which
isn't really likely to please anyone.


>But this leads to a larger concern, which is that much of this draft
>specifies client behavior in a manner which has traditionally been out
>of scope for our working group.  We would not normally propose to give
>guidelines for UI such as the existence of a panic mode, and how clients
>should respond to it.  For example, we do not attempt to prescribe how
>client software should display signed messages, what information should
>be shown from a signature, or how to depict messages which are partially
>signed and partially unsigned.
>  
>

I'd agree with that.  Although, if PFS is to
be achieved, a certain amount of guidance
would be required ... to explain things like
"must wipe the transport key after re-encrypting."

>I won't try to go through the rest of the draft at this time.  As I said,
>I support the goal of PFS, but I am skeptical about whether it makes
>sense for our WG to promulgate such detailed advice on a relatively
>narrow aspect of security.
>  
>

One comment - the URL points to an ID, a draft
presumably heading for standards track.  Would
it make more sense to specify a more client-oriented
document if it was informational track?

iang

-- 
News and views on what matters in finance+crypto:
        http://financialcryptography.com/