前言：我不知道在这里还是在Crypto网站上问这个问题是否更合适。随意移动或删除或执行任何适当的SE操作。
我被要求帮助更新某些加密软件。从广义上讲，该软件已经执行了以下步骤，这些步骤都不是特别不寻常的。为了简化发布，我省略了错误处理和Provider参数：
1）生成用于AES-128（或AES-256，mutatis mutandis）的随机对称密钥：
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的所有API，甚至可以查看Bouncy Castle，仅在密钥协商和传输的上下文中提及ECDH密钥，它们用于生成对称秘密。键而不是wrapping现有键。
我觉得我们在这里缺少一些东西，可能是由于糟糕的假设。 ECDH键真的不是Cipher.wrap()选项吗？还是is，但是我们需要做一些时髦的事情才能创建ECIES Cipher实例吗？
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密钥传输的人，因为它不是。它是包含在密钥交换中，该术语的创建是为了涵盖（有用的）运输和协议的结合。
您可以使用同意的（和派生的）值作为对称加密的密钥来创建加密方案使用（EC）DH，并且is（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“交换”（此处是交互的，并且通常是短暂的，而不是至少使接收者具有静态的身份）来生成一个秘密，该秘密被导出并用作用于对数据进行身份验证的对称加密的密钥材料。