3
$\begingroup$

Looking at the RFC for PGP email/asynchronous chat with PFS here https://datatracker.ietf.org/doc/html/draft-brown-pgp-pfs-03 can anyone tell me why the following scheme is no good?

Alice and Bob retrieve each others long-term public keys. When Alice sends the first email to Bob, she encrypts her message with Bob's long-term public key, generates a one time public key and signs it with her long-term private key and includes it in her email to Bob. Bob receives the email from Alice, and when replying, uses Alice's one-time public key to encrypt his message, and also includes his reply email a one-time public key signed with his long-term private key. etc etc. Of course, one-time public/private keys are deleted once they're used to decrypt a message, just as ephemeral Diffie-Hellman keys are deleted in something like ECDHE.

This provides PFS for Bob, and basically PFS for Alice (excluding the first message of Alice).

Why is this scheme not widely-used in PGP? Is it just because key generation takes a few moments? Or that, Alice having multiple communication partners (that might take forever to reply) means storing multiple one-time private keys? (This can of course be mitigated by making the one-time private keys expire after a short time, eg., one week like with Pond).

Thoughts welcome.

(by the way, I'm not really suggesting this as a revolutionary scheme. I'm genuinely trying to understand asynchronous messaging better, and destroying this basic PGP scheme would be helpful in my understanding).

Improve this question
$\endgroup$
1

1 Answer 1

Reset to default
2
$\begingroup$

Keeping a complete history of messages/keys

Perfect forward secrecy is great to protect "stream kind" of messages, but that does not really fit what OpenPGP is (mostly) used for. Often, OpenPGP messages are sent and read from different machines, at different times, in different order. While OTR (offering perfect forward secrecy) does not rely on external mailboxes (like IMAP servers) holding messages for long periods of times, mails often are kept a long period of time, and you might want to store them in their original, encrypted form. Perfect forward secrecy does require to have a unique store of a message (or at least key) history, something OpenPGP does not require. And storing such a history would again partially counterfeit the benefits of perfect forward secrecy, anyway.

Perfect forward secrecy might simply have been too young

Finally, OpenPGP had its first revisions pretty much at the same time perfect forward secrecy was discussed first. A likely (additional) reason is perfect forward secrecy wasn't on Phil Zimmerman's scope at all at that time.

Improve this answer
$\endgroup$
1
  • $\begingroup$ Instead of "stream kind message" I think you mean "synchronous communication"? I.e. where both participants are available to perform a key negotiation (e.g. Diffie-Hellman)? Signal (formerly TextSecure) has an (imperfect) solution for this where they store 100 pre-computed one-time-use receiver-halfs of the DH exchange on a central server. If you trust the server never to hand out the same twice you've got perfect forward secrecy... signal.org/blog/asynchronous-security $\endgroup$
    – Giel
    Nov 29, 2022 at 13:38

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.