关于各类型加密密钥对支持

[Trisia]

目前各CA 对加密密钥对 都不太规范，现存大量源自各种规范的不同结构的加密密钥对形式，就目前我已知的就有：

• GB/T 35276-2017
• GB/T 35275-2017
• GB/T 35291-2017 （6.4.10.1 结构体二进制）
• GM/T 0018-2012 （5.8 结构体二进制 ）

在TLCP服务端的加密密钥是通过CA从KMC得到，加密密钥对的私钥保护方法见 GMT 0014 数字证书认证系统密码协议规范

基于SM2算法的数字签名报文格式见 GBT 35275-2017 信息安全技术 SM2密码算法加密签名消息语法规范 或 GMT 0010-2012 SM2密码算法加密签名消息语法规范

该加密结构来自于 CMS RFC 5652 Cryptographic Message Syntax (CMS)

使用签名公钥加密 KEK 然后使用对称加密加密私钥

示例如下： 1677068431706_双证书.zip

[emmansun]

SM2EnvelopedKey来自于GB/T 35276-2017，另外的应该是pkcs#7的国密扩展，应该已经在我的pkcs#7 fork项目中实现了，明天我看看您提供的例子。

[it512]

@Trisia @emmansun 两位在这方面也是专家了， 建议你们将GB中不明确的地方， 不统一的地方， 整理出来，向有关部门做一个提案如何？并且在二位的项目中做一个参考实现，作为提案的一部分提交。

[emmansun]

pkcs7项目目前还不支持SignedEnvelopedData，建了一个issue: emmansun/pkcs7#8

[emmansun]

@Trisia , 您提供的示例数据是配对的吗？我发现SM2签名证书.crt中的SerialNumber=202302222020332756，而SM2加密私钥数字信封.p7b中的接收者SerialNumber=202302222020333509。

另外，这是哪个CA签发的？感觉SM4加密算法用得怪怪的，这样会给使用者带来困扰。

1. 加密算法标识符用了SM4，却没有使用含加密模式的更精确的标识符。
2. 密文长度是64个字节，我们知道私钥应该是32个字节，猜测是CBC模式？16字节IV+32字节密文+16字节填充？

结果，用您提供的签名私钥确实是能解密出来（SM4-ECB）的：

0000000000000000000000000000000000000000000000000000000000000000ca1c1d7f42b70273022c46c6075c8c8c92cb95f424184e7776f08fb6db750640

而您提供的SM2加密私钥.pem中的值为：

ca1c1d7f42b70273022c46c6075c8c8c92cb95f424184e7776f08fb6db750640 

难道那个CA的实现还固定长度为64字节？！

[emmansun]

所以，问题为：

1. 接收者签名证书序列号不匹配，而且接收者除了证书序列号，没有issuer。
2. 加密算法标识符不精确。
3. 私钥长度固定为64字节，前面补了32字节0。

[Trisia]

https://www.gmcert.org/

[Trisia]

细节部分工作日时我抽时间看看

[emmansun]

已在pkcs7项目中支持了signedEnvelopedData，以openssl为例，私钥输出一般以pkcs12（旧版本）、pkcs8为主。

[emmansun]

cfca的“pkcs12_sm2”。