Daniel, Thank you very much for the explanation. My puzzle is when the Sender using its Public Key to encrypt the Session Key, can anyone who have the access of the sender's Public Key decrypt the Session Key? Is it true that the Session Key is encrypted with a symmetric key between the Sender and the Recipient? Thanks, Linda -----Original Message----- From: Daniel Kahn Gillmor <dkg@xxxxxxxxxxxxxxxxx> Sent: Wednesday, November 29, 2023 1:26 PM To: Linda Dunbar <linda.dunbar@xxxxxxxxxxxxx>; gen-art@xxxxxxxx Cc: draft-ietf-openpgp-crypto-refresh.all@xxxxxxxx; last-call@xxxxxxxx; openpgp@xxxxxxxx Subject: Re: Genart last call review of draft-ietf-openpgp-crypto-refresh-12 Hi Linda-- Thanks for your review! On Wed 2023-11-29 09:48:54 -0800, Linda Dunbar via Datatracker wrote: > Nits/editorial comments: > Some of the steps described for "Confidentiality/authentication via Encryption" > are not clear to me. Hope the authors can answers the following questions: > > Section 2.1: Step 3 says that the Sender using Public Key to encrypt > the Session Key. The Step 5 says that the Receiver decrypts the > Session Key using recipient's Private Key. Shouldn't Sender and > Recipient use DH with both Public Key and Private Key to encrypt and decrypt the Session Key? When DH is used within OpenPGP for decryption, it involves the receiver's private key plus an ephemeral share that is packaged alongside the message itself (in the "public key encrypted session key", or PKESK packet). The section you're referring to (§2.1) is a high-level description, and it doesn't cover all the possible mechanisms available with OpenPGP. For example, some public key encryption in OpenPGP uses RSA, which doesn't involve DH at all. (and as-yet-unspecified quantum-resistant public key encryption, like ML-KEM, also likely won't use DH, see https://datatracker.ietf.org/doc/draft-wussler-openpgp-pqc/) So the contents of the PKESK depends on the specific algorithm used, and the description in §2.1 describes the overall process without getting into any particular cryptographic mechanism. Hopefully this helps understand why that section is written this way. Please don't hesitate to ask more questions! --dkg -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
