EC密钥ECIES加解密场景下IEKeySpec的作用是什么？

问题背景 #

开发基于Bouncy Castle的Java Spring Boot EC密钥加解密功能时，首先通过OpenSSL生成prime256v1曲线的相关密钥，执行命令如下：

openssl ecparam -name prime256v1 -genkey -noout -out secp256r1-key.pem
openssl ec -in secp256r1-key.pem -pubout -out secp256r1-pub.pem
openssl req -new -key secp256r1-key.pem -x509 -nodes -days 99999 -out secp256r1-cert.pem

最初编写的加解密代码可正常运行，代码如下：

public String encrypt_1(final String msg, PublicKey publicKey) throws Exception {
    final Cipher cipher = Cipher.getInstance("ECIES");
    final byte[] msgBytes = msg.getBytes("UTF-8");
    cipher.init(Cipher.ENCRYPT_MODE, publicKey);
    final byte[] encryptedBytes = cipher.doFinal(msgBytes);
    return Base64.getEncoder().encodeToString(encryptedBytes);
}

public String decrypt_1(final String msgEncrypted, PrivateKey privateKey) throws Exception {
    final Cipher cipher = Cipher.getInstance("ECIES");
    final byte[] msgBytes = Base64.getDecoder().decode(msgEncrypted);
    cipher.init(Cipher.DECRYPT_MODE, privateKey);
    final byte[] decryptedJwtBytes = cipher.doFinal(msgBytes);
    return new String(decryptedJwtBytes, StandardCharsets.US_ASCII);
}

查阅其他ECIES Java实现资料时，发现不少示例会使用IESParameterSpec和IEKeySpec，初始化Cipher时同时传入两类密钥，和常规非对称加密仅需传入对端公钥（加密）/自身私钥（解密）的用法不同，这类实现的核心片段如下：

// ...
IESParameterSpec param = new IESParameterSpec(d, e, 256);
// 解密时传入包含两个密钥的KeySpec
bcipher.init(Cipher.DECRYPT_MODE, new IEKeySpec(tpPrivateKey, ownPublicKey), param);
final byte[] decryptedBytes = bcipher.doFinal(cipherTextBytes);
// ...

这类写法无法正常运行，核心疑问为两点：

• 这种实现方式安全性是否更高？
• 加解密过程中为什么需要同时传入两类密钥？

核心解答 #

1. 两种写法对应ECIES的两种不同工作模式 #

当前可正常运行的代码，使用的是标准临时-静态（Ephemeral-Static）ECIES模式，也是各类密码库默认的ECIES实现：

• 加密时，Cipher内部会自动生成一对一次性临时EC密钥对，用临时私钥+传入的接收方公钥通过ECDH协商出共享密钥，再派生加密密钥、MAC密钥完成消息加密，最后会把临时公钥拼接在密文头部一起输出。
• 解密时，Cipher从密文头部解析出发送方生成的临时公钥，用传入的自身私钥+临时公钥算出相同的共享密钥即可完成解密。
  这种模式下解密方不需要提前知道发送方的任何公钥信息，加密方也不需要持有自己的长期密钥，初始化时仅需传入单个密钥即可，符合非对称加密的常规使用认知。

需要传入两个密钥的写法，使用的是静态-静态（Static-Static）ECIES模式：

• 这种模式不会生成临时密钥对，加密和解密双方需要提前持有对方的长期公钥，双方都用「自身长期私钥+对方长期公钥」通过ECDH协商出固定的共享密钥。
• 因为加密、解密环节计算共享密钥都需要同时用到自身私钥和对端公钥两个材料，所以需要用IEKeySpec把两个密钥打包传入——注意这里不是传入双方的所有公私钥，只是传入当前操作方自己持有的两个密钥材料：自身私钥、通信对端的公钥，不存在私钥泄露给对方的问题。

2. 静态-静态模式默认场景下安全性更低 #

没有特殊需求不要使用静态-静态模式，它的安全特性远差于默认的临时-静态模式：

• 临时-静态模式每次加密都会生成新的临时密钥，相同明文每次加密得到的密文都不同，天然具备前向安全性：就算某一次通信的密钥泄露，也不会影响其他历史、后续密文的安全，也能天然抵御重放攻击。
• 静态-静态模式下，只要双方的长期密钥不变，协商出的共享密钥就是固定的，一旦这个共享密钥或者任意一方的长期私钥泄露，所有历史密文都会被破解，也没有前向安全性，必须额外搭配随机盐、消息序号、时间戳等机制才能防重放，实现成本高且容易出现安全漏洞。

静态-静态模式唯一的适用场景是资源极度受限的嵌入式环境，不需要在密文里携带临时公钥可以节省几十字节的传输带宽，普通Web、服务端开发完全不需要使用这种模式。

3. 静态-静态模式代码运行失败的常见原因 #

• 加密解密两端的IESParameterSpec参数不一致：不同Bouncy Castle版本的默认KDF哈希算法、MAC算法、密钥长度参数存在差异，静态-静态模式要求两端的密钥派生参数完全一致，任意一个参数不匹配都会导致解密失败。
• 密钥传参顺序错误：IEKeySpec构造的第一个参数必须是当前操作方自身的私钥，第二个参数必须是通信对端的公钥，加密、解密场景都要遵循这个规则，传反会直接算出错误的共享密钥，无法正常加解密。

当前使用的默认ECIES实现符合SEC 1国际标准，和OpenSSL等工具的默认ECIES逻辑兼容，没有特殊需求不需要调整为静态-静态模式。

内容的提问来源于stack exchange，提问作者BarbetNL