From de3cbb2e0834c6c425320efae3c71a132ed54fd8 Mon Sep 17 00:00:00 2001
From: Sun Yimin <emmansun@users.noreply.github.com>
Date: Sun, 19 May 2024 10:14:53 +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 | 15 +++++++++++++++
 1 file changed, 15 insertions(+)

diff --git a/SM2加解密性能.md b/SM2加解密性能.md
index 89231c3..8879ca8 100644
--- a/SM2加解密性能.md
+++ b/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状态优化后：
 ```