我正在尝试将RFC 6637集成到Bouncy Castle C#中，这比最初想象的更具挑战性，因为必须同时存在私钥和公钥才能计算共享秘密：那些不适合充气城堡 API 的。
无论如何，RFC 的第 10 节定义了一个公钥将被编码到公钥加密会话密钥包中。这是发送方还是接收方的公钥？无论哪种方式，为什么 OID 不是它的一部分，因为没有 OID，该点或多或少是无用的。
更新： 我刚刚使用 Symantec Pgp 命令行工具转储 ecc 加密文件的数据包。现在我明白了一点：对于每次加密，发送者都会生成一个新的 ECDH 密钥，它与接收者的曲线相匹配，并将新的公钥作为包的一部分发送。
更新 2：
现在完全支持 RFC 6637。检查存储库。
在Diffie-Hellman算法中，发送者和接收者必须在同一个组中播放——在 ECDH 的情况下，相同的曲线。具有密钥对的人不会先验地共享相同的组参数（尽管在椭圆曲线的情况下，“标准曲线”很少）。如果发送方和接收方的密钥对都使用相同的曲线，他们可能会使用该曲线来计算共享密钥，但通常不能假设。
此外，PGP 遵循电子邮件上下文，这是单向的：单个消息从发送者发送到接收者，并且在电子邮件实际发出之前，接收者不会收到交易通知。然后接收器在整个操作过程中完全静止。因此，发送方和接收方必须使用接收方密钥对所在的组。
因此，发件人必须（通常）创建一个新的密钥对，被认为是“短暂的”（这是 RFC 6637 第 10 节中的重要词），仅用于该电子邮件发送，与接收者的密钥在同一组中。发件人不会存储该密钥（因此命名）。消息必须包含发送者的临时密钥对的公共部分，即曲线点；曲线 OID 不需要指定，因为根据定义，使用接收者的曲线：接收者已经知道它。
注意：由于发送者使用全新的临时密钥对，ECDH 不暗示发送者身份验证。如果发件人希望向收件人证明他的身份，他还必须使用他自己的非临时签名密钥对签署他的电子邮件。