我主要对使用Curve25519进行密钥交换和使用Ed25519进行签名感兴趣。但是类似的组合（例如EC-DH和EC-Schnorr甚至是具有相同密钥对的EC-DSA）也会很有趣。
Curve25519仅对x坐标的输出进行哈希处理。 Diffie-Hellman密钥交换
Ed25519是EC-Schnorr签名的细微变体。
我看到一些建议，避免将单个密钥用于多个目的，但是我找不到任何具体的建议。
#1 楼
关于“ EMV中的加密和签名的联合安全性”的论文表明，可以在不损害安全性的情况下一起使用ECIES和EC-Schnorr签名：在随机Oracle模型ECIES-KEM中如果gap-DLP问题和gap-DH问题都很难解决，那么
EC-Schnorr和EC-Schnorr共同安全
Ed25519与EC-Schnorr非常相似，并且ECIES和Curve25519基于EC-DH，因此这表明在Curve25519和Ed25519中使用相同的密钥对是安全的。
仍然有证据表明，直接引用Curve25519中使用的密钥交换会很好。
#2 楼
通常，您希望保持加密和签名密钥不相交，因为它们往往具有不同的生命周期。从广义上讲，应该保存加密密钥，因为私有密钥的丢失意味着相对于公共密钥加密的数据的丢失。但是，签名密钥不能托管，因为签名的证明值仅来自密钥所有者对私钥的控制。请参阅此答案以进行更详细的讨论。您的特定情况可能会容许未托管的加密密钥-例如，仅使用您的加密密钥（称为“密钥交换密钥”）用于建立短期会话密钥，这些会话密钥不用于加密数据，或者用于在另一侧迅速解密加密的数据，并且从未存储过加密的数据。也就是说，您的密钥交换密钥用于建立类似SSL的隧道，而不用于发送加密的电子邮件。在那种情况下，剩下的一个问题是关于密钥交换算法和签名算法之间的交互：攻击者是否可以通过让您发出一些使用相同私钥的签名来破坏密钥交换？正如@CodesInChaos所建议的那样，对于ECDH和ECDSA使用相同的私钥是安全的，但是Devil位于详细信息中：除非有明确的安全性证明与您打算使用的特定算法有关，否则我建议不要这样做。
安全且可行的是，存储主密钥K，并使用合适的PRF（例如HMAC_DRBG）动态地从K派生您的加密私钥和签名私钥。 。
评论
$ \ begingroup $
第一个区别不是加密和签名之间，而是身份验证和机密密钥之间。特别是，如果您使用基于密钥交换的算法来验证电子邮件[我更喜欢签名]，则它的生命周期与用于签名的密钥相同。
$ \ endgroup $
– CodesInChaos
2012年7月22日在17:43
$ \ begingroup $
主密钥方法也无济于事，因为我试图尽量减小公共密钥的大小。我考虑过使用两个单独的公共密钥的哈希，但这在我的某些预期用途中很烦人。阅读我链接的论文后，我认为与协议和实施中其他与安全性相关的部分发生错误的风险相比，使用EC-DH + EC-Schnorr的风险是可以接受的。
$ \ endgroup $
– CodesInChaos
2012年7月22日17:45
$ \ begingroup $
我认为问题更多是关于使用同一密钥是否会从密码/数学意义上损害密钥的安全性。密钥的使用方式及其生命周期是一个实现细节，具体取决于您尝试构建的系统类型，安全要求，威胁模型，用例等。
$ \ endgroup $
–亚当·伊里尔门科（Adam Ierymenko）
19年5月20日在15:29
评论
这个问题的一般版本略多于加密和密钥派生