mirror of
https://github.com/emmansun/gmsm.git
synced 2025-07-05 03:13:17 +08:00
Updated SM2加解密性能 (markdown)
parent
5d09055612
commit
de3cbb2e08
15
SM2加解密性能.md
15
SM2加解密性能.md
@ -89,6 +89,21 @@ BenchmarkHash8K-6
|
||||
# 关于SM3基于SIMD的多路并行
|
||||
目前已经有好多基于SIMD的哈希算法实现:MD5,SHA256,也包括SM3。通用SIMD多路并行设计实现的难点在于输入、输出协调处理,象**SM2-KDF**这种应用场景是最简单的:处理的数据块数相同,数据源单一。预测当待加密数据足够长的情况下,SM2加密性能能赶上(甚至超过?)无SM4-NI的SM4-CBC的性能。接下来会做一些实验性实现,观察一下效果。
|
||||
|
||||
# 关于密文格式C1C2C3和C1C3C2
|
||||
C1C2C3更适合加密流式处理:
|
||||
* 用公钥生成Encrypter。
|
||||
* 生成随机数和点C1,随之生成Z,初始化KDF(COUNTER及HASH(Z)),输出C1点。
|
||||
* XOR Stream,输出部分密文C2;同时计算C3,也就是认证码。
|
||||
* Finalize,输出最终C3值。
|
||||
|
||||
解密过程:
|
||||
* 用私钥生成Decrypter。
|
||||
* 读入至少96字节,生成C1,随之生成Z,初始化KDF(COUNTER及HASH(Z))。
|
||||
* XOR Stream, 输出部分明文;同时计算C3'。这一步要特殊处理,缓冲区中至少保留32字节。
|
||||
* Finalize,如果缓冲区数据长度超过32字节,则先对多出部分继续进行XOR stream动作,计算最终C3',和缓冲区中的最后32字节进行比较,相等则返回成功,否则失败。
|
||||
|
||||
由此可见,解密时C1C2C3比C1C3C2复杂一点,但C1C3C2做不到流式加密。当然,如果我们严格按照SM2非对称加密设计的初衷,只对少量数据进行加解密,则各种格式都没什么问题。
|
||||
|
||||
# 结论
|
||||
经过KDF共享Z状态优化后:
|
||||
```
|
||||
|
Loading…
x
Reference in New Issue
Block a user