Daniel, "using the *recipient's* public key (not the sender's public key)" makes sense to me. Thank you very much for the explanation. No further questions. Linda -----Original Message----- From: Daniel Kahn Gillmor <dkg@xxxxxxxxxxxxxxxxx> Sent: Wednesday, November 29, 2023 3:46 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 On Wed 2023-11-29 20:11:31 +0000, Linda Dunbar wrote: > 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? Hm, the session key *is* a symmetric key. but when using a PKESK, it is encrypted using the *recipient's* public key (not the sender's public key), and can only be decrypted by the recipient's private key. The way that encryption is done, for public key algorithms that are based on Diffie-Hellman, is that the sender generates an ephemeral secret, and includes the ephemeral public in the PKESK, and wraps the session key using a keywrap based on a key derived from the DH shared secret, which in turn comes from the ephemeral secret key and the recipient's public key (or, from the recipient's perspective, from the recipient's secret key and the ephemeral public key). See for example the definition of X25519 PKESK: https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#name-algorithm-specific-fields-for- But note also that some PKESKs don't use DH at all (e.g. RSA), which is why §2.1 doesn't talk about DH explicitly. --dkg -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
