mirror of
https://github.com/emmansun/gmsm.git
synced 2025-05-11 03:26:17 +08:00
Updated SM2加解密性能 (markdown)
parent
de3cbb2e08
commit
1476eb86ad
@ -99,8 +99,8 @@ C1C2C3更适合加密流式处理:
|
||||
解密过程:
|
||||
* 用私钥生成Decrypter。
|
||||
* 读入至少96字节,生成C1,随之生成Z,初始化KDF(COUNTER及HASH(Z))。
|
||||
* XOR Stream, 输出部分明文;同时计算C3'。这一步要特殊处理,缓冲区中至少保留32字节。
|
||||
* Finalize,如果缓冲区数据长度超过32字节,则先对多出部分继续进行XOR stream动作,计算最终C3',和缓冲区中的最后32字节进行比较,相等则返回成功,否则失败。
|
||||
* XOR Stream, 输出部分明文;同时计算C3'。这一步要特殊处理,缓冲区中至少保留后32字节。
|
||||
* Finalize,如果缓冲区数据长度超过32字节,则先对多出部分(前n字节)继续进行XOR stream动作,计算最终C3',和缓冲区中的最后32字节进行比较,相等则返回成功,否则失败。
|
||||
|
||||
由此可见,解密时C1C2C3比C1C3C2复杂一点,但C1C3C2做不到流式加密。当然,如果我们严格按照SM2非对称加密设计的初衷,只对少量数据进行加解密,则各种格式都没什么问题。
|
||||
|
||||
|
Loading…
x
Reference in New Issue
Block a user