From 1476eb86ad336e07e13111b4a0a7054adeaffa16 Mon Sep 17 00:00:00 2001 From: Sun Yimin Date: Sun, 19 May 2024 10:16:51 +0800 Subject: [PATCH] =?UTF-8?q?Updated=20SM2=E5=8A=A0=E8=A7=A3=E5=AF=86?= =?UTF-8?q?=E6=80=A7=E8=83=BD=20(markdown)?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- SM2加解密性能.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/SM2加解密性能.md b/SM2加解密性能.md index 8879ca8..1212b2e 100644 --- a/SM2加解密性能.md +++ b/SM2加解密性能.md @@ -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非对称加密设计的初衷，只对少量数据进行加解密，则各种格式都没什么问题。