前言：我不知道在这里还是在Crypto网站上问这个问题是否更合适。随意移动或删除，或执行任何适当的SE操作。
已要求我帮助更新某些加密软件。从广义上讲，该软件已经执行了以下步骤，这些步骤都不是特别不寻常的。为了简化发布，我省略了错误处理和Provider参数：
1）生成用于AES-128（或AES-256，必要时作必要修改）的随机对称密钥：
KeyGenerator keygen = KeyGenerator.getInstance("AES");
keygen.init (128, a_SecureRandom_instance);
SecretKey sessionKey = keygen.generateKey();
2）根据用户是否使用...来包装对称密钥。
2a）...来自密钥对的RSA公钥：
// OAEP wasn't used in this software for hysterical raisins
Cipher wrapper = Cipher.getInstance("RSA/ECB/PKCS1Padding");
wrapper.init (Cipher.WRAP_MODE, user_RSA_PublicKey);
2b）...一个密码短语：
SecretKey stretched = ...passphrase stretched through a PBKDF like bcrypt...;
// I don't remember whether it's specified as "AES" or "AESWrap" here
Cipher wrapper = Cipher.getInstance("AES or AESWrap/ECB/NoPadding");
wrapper.init (Cipher.WRAP_MODE, stretched);
2c）在任一路由中，会话密钥都被包装：
byte[] wrapped = wrapper.wrap(sessionKey);
3）会话密钥用于使用Cipher和随机IV创建一个Cipher.ENCRYPT_MODE，然后通过它运行大量数据。该部分是非常标准的，但是如果您真的想查看CipherInputStream的用法，可以将其发布。包装好的会话密钥与加密数据以及在阳光下所有事物的一堆HMAC一起存储。
稍后在解密时，用户提供RSA私钥或用于扩展的密码。该软件将解开对称密钥并解密数据。
所有这些已经工作了一段时间。但是，当然，RSA密钥对变得越来越大且越来越慢，因此它们希望支持上述步骤2的其他可能性，其中使用椭圆曲线算法（通常是P384 ECDH）生成公钥。这就是我们感到困惑的地方。
在Cipher wrapper = Cipher.getInstance("RSA/ECB/PKCS1Padding")调用中似乎没有用于椭圆曲线的JCE替换算法/转换。 Java文档中列出的唯一一个是“ ECIES”，它似乎更倾向于多方密钥协议？
我可以找到的Java内置JCE甚至查看Bouncy Castle的所有API，仅在密钥协议和传输的上下文中提及ECDH密钥，这些密钥用于生成对称密钥，而不是包装现有密钥。
我觉得我们在这里遗漏了一些东西，可能是由于错误的假设。 ECDH密钥真的不是Cipher.wrap()的选择吗？还是是，但是我们需要做一些时髦的事情才能创建ECIES Cipher实例吗？
答案 0 :(得分：1)
RSA是用于加密和签名的算法（或者取决于您的外观，这是两个非常相似但截然不同的算法）。 RSA加密可以加密dat，它是一个（低级）密钥，在这种情况下，它称为包装。
DH是一种密钥协商算法，无论是经典形式（aka整数，Zp，modp或有限域/ FF）形式还是椭圆曲线形式（ECDH）。请注意，至少对于经典DH而言，原始协议值g ^ a ^ b mod n = g ^ b ^ a mod n具有足够的数学结构，人们不满意直接将其用作键，因此我们通过键派生来运行它功能，缩写为KDF。我不清楚ECDH值是否确实需要KDF，至少对于常用的X9 / NIST曲线（包括P384）（如果您愿意，可以在crypto.SX上查询或询问），但是使用KDF便宜且行之有效我们这样做。
我从未听说过任何能胜任呼叫（EC）DH密钥的传输，因为它不是。它 包含在密钥 exchange 中，该术语旨在涵盖运输和协议的（有用的）结合。
您可以使用协商一致的（和派生的）值作为对称加密的密钥，使用 （EC）DH 创建加密方案。 是（EC）IES。我不知道是什么让您认为IES是另一回事。现代实践是，应该对对称加密进行身份验证，并且IES的标准化形式作为单独的方案使用带有HMAC身份验证的CBC加密，尽管您可以有效地设计使用以下示例的方案：改为GCM。
如您所见，BouncyCastle提供程序提供了DH（经典）或EC IES“带有{AES，DESEDE} -CBC”的实现（在1.56之前的版本中，有时省略了-CBC），该实现使用了P1363a中的KDF2和SHA1，指定的CBC密码和HMAC-SHA1。 “标准”（Sun / Oracle / Open）提供程序没有，但是您可以结合使用原始协议操作，KDF，对称加密和MAC来产生相同的结果。
这与CMS-formerly-PKCS7 with classic DH and ECDH和PGP with ECDH的操作类似（尽管在某些细节上有所不同）。 （PGP不支持经典DH；它使用ElGamal加密代替RSA。）更不用说TLS（有时通过1.2，始终在1.3中）和SSH，它们使用经典或EC DH“交换”（此处是交互的，并且通常是短暂的，而不是至少使接收者具有静态的身份）来生成一个秘密，该秘密被导出并用作用于对数据进行身份验证的对称加密的密钥材料。