vault backup: 2026-11-07 16:33:44

2026-11-07 16:33:55 +08:00
commit 7015312702
1208 changed files with 132432 additions and 0 deletions
@@ -0,0 +1,132 @@
+### 一、SSL/TLS握手流程与性能瓶颈分析
+
+#### 1.1 SSL/TLS握手的基本流程
+
+SSL/TLS握手是客户端与服务器建立安全连接的核心过程，主要包含以下步骤：
+
+1. **ClientHello**：客户端发送支持的协议版本、加密套件列表及随机数；
+2. **ServerHello**：服务器选择协议版本、加密套件并返回证书；
+3. **证书验证**：客户端验证服务器证书的合法性（有效期、颁发者、域名匹配等）；
+4. **密钥交换**：双方基于证书中的公钥协商会话密钥（如RSA、ECDHE）；
+5. **Finished**：完成握手并开始加密数据传输。
+
+传统握手流程需1-2个RTT（往返时间），在弱网络或高延迟场景下可能显著增加用户等待时间。
+
+#### 1.2 性能瓶颈的三大根源
+
+在CDN加速体系下，SSL/TLS握手的性能瓶颈主要源于：
+
+- **证书传输开销**：证书体积（尤其是包含完整证书链时）可能达数KB，在移动网络中传输延迟高；
+- **密钥交换计算负载**：RSA等非前向安全算法需大量CPU计算，边缘节点资源受限时易成为瓶颈；
+- **重复握手浪费**：同一客户端在短时间内多次访问同一域名时，需重复执行完整握手流程。
+
+CDN加速通过边缘节点就近处理请求，为优化上述瓶颈提供了天然优势。
+
+### 二、CDN加速中的SSL/TLS握手优化策略
+
+#### 2.1 会话复用（Session Resumption）
+
+会话复用通过复用已建立的会话参数（如会话ID或会话票据），避免重复密钥交换与证书验证，将握手延迟从1-2 RTT降至0-1 RTT。CDN加速的优化实现包括：
+
+- **边缘节点会话缓存**：各CDN边缘节点独立缓存会话状态，客户端再次访问时直接复用本地缓存的会话；
+- **分布式会话同步**：通过CDN加速的内部网络，将热门域名的会话状态同步至多个边缘节点，确保跨节点访问时的复用成功率；
+- **会话票据扩展（TLS Session Ticket）**：服务器将会话状态加密后以票据形式发送给客户端，边缘节点无需存储会话数据，降低内存开销。
+
+CDN加速的分布式架构使得会话复用在跨区域、跨运营商场景下仍能保持高效。
+
+#### 2.2 0-RTT与早期数据（Early Data）
+
+在TLS 1.3协议中，0-RTT技术允许客户端在首次握手时直接发送加密数据（如HTTP请求），将握手延迟降至0 RTT。CDN加速的优化点包括：
+
+- **边缘节点协议支持**：CDN边缘节点需升级至TLS 1.3，并配置允许0-RTT的加密套件；
+- **抗重放攻击保护**：通过CDN加速的全局流量监控，检测并拦截重复使用的0-RTT数据包，防止中间人攻击；
+- **应用层兼容性**：对不支持0-RTT的应用协议（如HTTP/1.1），CDN边缘节点需自动降级为传统握手模式。
+
+CDN加速的协议兼容性设计确保了0-RTT技术在复杂网络环境中的稳定应用。
+
+#### 2.3 密钥交换算法优化
+
+传统RSA密钥交换计算量大，而ECDHE（椭圆曲线Diffie-Hellman）算法在提供前向安全性的同时，计算效率更高。CDN加速的优化实践包括：
+
+- **边缘节点硬件加速**：利用CPU的AES-NI指令集或专用加密卡，加速ECDHE密钥交换计算；
+- **算法动态选择**：根据客户端支持的加密套件列表，CDN边缘节点优先选择ECDHE等高效算法；
+- **预生成密钥参数**：边缘节点提前生成ECDHE参数并缓存，减少实时计算开销。
+
+通过CDN加速的硬件与算法协同优化，密钥交换延迟可降低50%以上。
+
+### 三、证书动态缓存技术的核心原理
+
+#### 3.1 证书缓存的必要性
+
+证书传输是SSL/TLS握手的主要延迟来源之一，尤其是当证书链较长时（如包含根证书、中间证书、叶证书）。证书动态缓存技术通过在CDN边缘节点缓存证书，避免每次握手都从源站获取证书，从而减少传输延迟与源站负载。
+
+#### 3.2 动态缓存的实现机制
+
+证书动态缓存需解决两大核心问题：**缓存一致性**与**缓存命中率**。CDN加速的优化方案包括：
+
+1. **缓存策略设计**：
+    - **按域名缓存**：以域名为单位缓存证书，支持通配符证书与多域名证书的灵活管理；
+    - **过期前主动更新**：边缘节点在证书过期前主动从源站拉取新证书，避免服务中断；
+    - **分级缓存架构**：区域中心节点缓存热门证书，边缘节点优先从区域节点获取证书，减少回源流量。
+2. **缓存一致性保障**：
+    - **版本号机制**：源站更新证书时同步更新版本号，边缘节点通过比对版本号决定是否更新缓存；
+    - **短TTL与快速失效**：为缓存设置较短TTL（如5分钟），并通过CDN加速的实时配置下发系统快速失效旧证书；
+    - **主动推送更新**：源站证书变更时，通过CDN加速的管理接口主动推送新证书至所有边缘节点。
+3. **缓存命中率提升**：
+    - **流量预测与预加载**：基于历史访问数据预测热门域名，提前将证书加载至边缘节点缓存；
+    - **动态证书合成**：对支持SNI（Server Name Indication）的场景，边缘节点动态合成证书链，减少冗余证书传输；
+    - **多级缓存协同**：结合浏览器本地缓存、CDN边缘缓存与源站缓存，形成立体化缓存体系。
+
+CDN加速的分布式缓存架构使得证书动态缓存技术在全球范围内实现高效覆盖。
+
+### 四、CDN加速中握手优化与证书缓存的协同实践
+
+#### 4.1 握手流程与证书缓存的联动优化
+
+在CDN加速体系中，握手优化与证书缓存需协同工作以最大化性能收益：
+
+- **握手阶段证书快速获取**：边缘节点收到ClientHello后，直接从本地缓存读取证书，避免回源获取；
+- **证书验证加速**：边缘节点预加载热门证书的公钥指纹与颁发者信息，减少在线证书状态协议（OCSP）查询延迟；
+- **动态算法与证书匹配**：根据证书支持的加密套件，边缘节点动态选择最优密钥交换算法（如ECDHE_ECDSA证书优先使用ECDHE算法）。
+
+#### 4.2 监控与自适应调整
+
+CDN加速需构建实时监控系统，持续收集以下指标以驱动优化策略调整：
+
+- **握手延迟**：按区域、运营商、域名维度分析握手耗时，识别性能瓶颈节点；
+- **证书缓存命中率**：统计各边缘节点的证书缓存命中情况，优化缓存策略与预加载规则；
+- **算法使用率**：跟踪不同加密套件与密钥交换算法的使用频率，淘汰低效算法。
+
+基于监控数据，CDN加速系统可动态调整缓存TTL、握手复用策略与算法优先级，形成“监控-分析-优化”的闭环。
+
+#### 4.3 安全性与性能的平衡
+
+在优化性能的同时，CDN加速需确保安全性不受影响：
+
+- **证书完整性校验**：边缘节点在缓存证书前需验证证书链的完整性，防止伪造证书注入；
+- **算法安全性审计**：定期评估加密套件与密钥交换算法的安全性，禁用已知漏洞算法（如RC4、SHA-1）；
+- **DDoS防护集成**：将SSL/TLS握手流量纳入CDN加速的DDoS防护体系，防止握手阶段被恶意利用。
+
+CDN加速的安全设计为握手优化与证书缓存提供了可靠保障。
+
+### 五、方案效果与未来趋势
+
+#### 5.1 实际效果验证
+
+在某大型电商平台的实践中，部署CDN加速的SSL/TLS握手优化与证书动态缓存技术后，关键指标显著提升：
+
+- **握手延迟**：全球平均握手延迟从320ms降至180ms，其中移动网络场景下降低45%；
+- **证书传输流量**：通过缓存复用，证书相关流量减少70%，源站负载大幅降低；
+- **安全性**：100%会话使用前向安全算法，证书伪造攻击拦截率提升至99.99%。
+
+#### 5.2 未来发展方向
+
+随着量子计算与边缘智能技术的演进，CDN加速中的安全传输优化将面临新挑战与机遇：
+
+- **后量子密码算法集成**：提前布局抗量子计算的加密算法（如CRYSTALS-Kyber），确保长期安全性；
+- **AI驱动的动态优化**：利用机器学习预测网络质量与攻击模式，实时调整握手策略与缓存规则；
+- **边缘证书颁发**：探索在CDN边缘节点直接颁发短期证书，进一步减少回源依赖与握手延迟。
+
+### 结论
+
+CDN加速通过分布式边缘计算与智能路由技术，为SSL/TLS握手优化与证书动态缓存提供了核心基础设施支撑。通过会话复用、0-RTT、密钥交换算法优化等策略，结合分级证书缓存与实时监控体系，CDN加速可显著降低安全传输的初始延迟与带宽开销，同时保障数据传输的机密性与完整性。未来，随着技术的持续演进，CDN加速将在构建高效、安全的全球网络传输体系中发挥更关键的作用。
@@ -0,0 +1,13 @@
+
+### 搜狗拼音输入法小猫动态皮肤
+有开源项目基础参考
+基于平台收费
+
+
+### WhenHub
+轻量级的时间预约工具
+
+
+
+## gmnginx
+
@@ -0,0 +1,9 @@
+- 现状
+    
+- 团队
+    
+- 对手
+    
+- 年底目标
+    
+- 明年目标
@@ -0,0 +1,131 @@
+![BBR是什么？为什么你需要它？ (一键开启BBR脚本教程)](https://pic1.zhimg.com/v2-3403eaaf7726a421737e12f4ccfa7bf9_720w.jpg?source=7e7ef6e2&needBackground=1)
+
+在玩 VPS 的圈子里，流传着这样一句话：”买完 VPS 的第一件事，就是开启 BBR。”
+
+如果你发现你的服务器带宽明明很大，本地延迟也不算高，但下载速度就是上不去，看视频总是转圈圈，那么 90% 的概率是因为你没有开启 **TCP BBR**。
+
+今天，我们就来深度聊聊这个能让服务器速度倍增的神器。
+
+---
+
+## 一、 为什么你的带宽被”浪费”了？
+
+在进入正题前，我们要先理解一个概念：**拥塞控制算法**。
+
+互联网传输数据就像公路运输。当路面出现拥塞时，如果司机还在拼命往里塞车，整条路就会瘫痪。TCP 协议为了防止这种情况，设计了”拥塞控制算法”。
+
+### 传统算法的弊端：
+
+传统算法（如 Cubic）采用**基于丢包的被动式拥塞控制**：一旦检测到丢包，就会大幅降低发送速率，然后缓慢恢复。但在跨境网络（如访问海外 VPS）中，丢包往往不是因为拥堵，而是因为线路质量本身的波动（信号干扰或过滤）。
+
+**这就导致了一个尴尬的局面：** 管道其实还没满，但因为偶尔的丢包，传统算法吓得不敢发货，你的带宽自然跑不满。
+
+---
+
+## 二、 BBR 是什么？它是如何”起死回生”的？
+
+**BBR** (Bottleneck Bandwidth and Round-trip propagation time) 是 Google 在 2016 年开源的拥塞控制算法。它通过实时测量**瓶颈带宽 (BtlBw)** 和**最小往返传播时延 (RTprop)** 来优化传输速度。
+
+如果说传统算法是”看到丢包就刹车”的胆小司机，那么 **BBR 就是一位”经验丰富的老司机”**：
+
+1. **它不以丢包为唯一判据：** 通过主动探测带宽和时延，而非被动等待丢包信号。
+2. **高效利用带宽：** 即使线路存在一定程度的丢包（比如 5%-10%），BBR 依然能保持极高的吞吐量。
+3. **更低的延迟：** 它能有效减少路由器缓存区的堆积，从而降低网络抖动。
+
+**一句话总结：BBR 能够在恶劣的网络环境下，更高效地利用你的带宽资源。**
+
+**典型提升场景：**
+
+- 高延迟环境（>100ms RTT）：提升 2-5 倍
+- 丢包率 5%-10% 的线路：提升 3-10 倍
+- 低延迟、低丢包环境：提升有限（<20%）
+
+---
+
+## 三、 开启前准备：你的 VPS 支持吗？
+
+在动手之前，请先确认你的 VPS 架构：
+
+- **KVM / Xen / VMware：** 完美支持，你可以自由更换系统内核。
+- **OpenVZ / LXC：** 通常不支持（除非服务商在母机开启了 BBR）。
+
+目前主流的 Linux 发行版（如 Debian 9+、Ubuntu 18.04+、CentOS 8+）都已经内置了较新版本的内核。**BBR 需要 Linux 4.9+ 内核**，你可以用 `uname -r` 命令查看当前内核版本。
+
+---
+
+## 四、 实战教程：如何开启 BBR？
+
+### 方法 1：官方原生开启法（最稳妥，推荐）
+
+如果你的系统是 **Debian 10/11/12** 或 **Ubuntu 20.04/22.04** 等较新版本，内核通常已经在 4.9 以上，无需安装任何脚本，直接执行以下三行命令即可：
+
+```text
+# 1. 将 BBR 配置写入系统变量
+echo "net.core.default_qdisc=fq" | sudo tee /etc/sysctl.d/99-bbr.conf
+echo "net.ipv4.tcp_congestion_control=bbr" | sudo tee -a /etc/sysctl.d/99-bbr.conf
+
+# 2. 重启使配置生效
+sudo sysctl --system
+sudo reboot
+```
+
+### 方法 2：一键脚本开启法（适用于旧系统或追求极致）
+
+如果你的系统内核较旧（如 CentOS 7），或者你想安装更加激进的 **BBRplus**（魔改版），可以使用社区开发的”四合一”脚本。
+
+**在 SSH 终端输入：**
+
+```text
+wget -N --no-check-certificate "https://github.com/chiakge/Linux-NetSpeed/raw/master/tcp.sh" && chmod +x tcp.sh && ./tcp.sh
+```
+
+**注意：** 这是第三方维护的脚本，虽然在社区中广泛使用，但使用前建议查看脚本源码（`cat tcp.sh`）或优先使用官方方法。
+
+**操作提示：**
+
+1. 运行后根据菜单选择”安装内核”（通常建议选择 BBRplus）。
+2. 安装完成后，脚本会提示你**重启服务器**。
+3. 重启后重新运行 `./tcp.sh`，选择”开启加速”即可。
+
+---
+
+## 五、 如何验证 BBR 是否生效？
+
+开启成功后，输入以下命令进行验证：
+
+```text
+# 查看当前正在使用的拥塞控制算法
+sudo cat /proc/sys/net/ipv4/tcp_available_congestion_control
+```
+
+如果输出结果包含 `bbr` 字样，说明你已经成功起飞！
+
+此外，你还可以通过以下命令查看更多信息：
+
+```text
+# 查看当前可用的拥塞控制算法
+sudo sysctl net.ipv4.tcp_available_congestion_control
+
+# 查看 BBR 模块是否在运行
+sudo lsmod | grep bbr
+```
+
+---
+
+## 六、 BBRplus 和 BBRv3 有什么区别？
+
+有些小伙伴会问，脚本里那么多版本怎么选？
+
+- **BBR (官方版)：** 最稳定，兼容性最好。适合大部分生产环境。
+- **BBRplus：** 网友修改的激进版本，在丢包严重的线路上抢包能力更强。但它可能会占用过多带宽资源，在共享带宽环境下可能影响同机房其他用户，部分服务商可能禁止使用。
+- **BBRv3：** Google 最新的优化版本，进一步平衡了吞吐量和公平性。
+
+**站长建议：** 如果是个人爬墙或看视频，**BBRplus** 的体感提升往往最明显；如果是运行重要的网站业务，**原生 BBR** 是首选。
+
+---
+
+## 七、 结语与注意事项
+
+开启 BBR 能让你的 VPS 更高效地利用带宽资源。对于跨境链路来说，它能带来的提升往往是**几倍甚至十几倍**的。
+
+**⚠️ 最后的温馨提示：** 更换内核（尤其是使用一键脚本）属于高风险操作。虽然现在的脚本已经非常成熟，但依然有极小概率导致服务器无法启动。在操作前，请务必执行**快照备份**或者确保重要数据已同步。
@@ -0,0 +1,69 @@
+Authenticated Encryption with Associated Data (AEAD) 是一种同时具备保密性，完整性和可认证性的加密形式。
+
+AEAD 产生的原因很简单，单纯的对称加密算法，其解密步骤是无法确认密钥是否正确的。也就是说，加密后的数据可以用任何密钥执行解密运算，得到一组疑似原始数据，而不知道密钥是否是正确的，也不知道解密出来的原始数据是否正确。
+
+因此，需要在单纯的加密算法之上，加上一层验证手段，来确认解密步骤是否正确。
+
+简单地把加密算法和认证算法组合，可以实现上述目的，并由此产生了几个方案：
+
+**第一种方案，EtM (Encryption then MAC)**
+
+  
+
+![](https://pic2.zhimg.com/80/v2-c433aa83e2c8b20ae44c61b869afb735_720w.webp)
+
+  
+
+_图片来自_ _[https://en.wikipedia.org/wiki/Authenticated_encryption](https://link.zhihu.com/?target=https%3A//en.wikipedia.org/wiki/Authenticated_encryption)_
+
+先加密，然后对密文进行 MAC 运算（一般用各种 HMAC），把二者拼接起来，发给接收方。
+
+接收方先验证 MAC，如果验证通过，则证明密钥是正确的，然后执行解密运算。
+
+**第二种方案，E&M (Encryption and MAC)**
+
+  
+
+![](https://pic1.zhimg.com/80/v2-27436bd00918fb8ba1325e4fe30c8f44_720w.webp)
+
+  
+
+_图片来自_ _[https://en.wikipedia.org/wiki/Authenticated_encryption](https://link.zhihu.com/?target=https%3A//en.wikipedia.org/wiki/Authenticated_encryption)_
+
+同时对原始数据执行加密和 MAC 运算，把二者拼接起来，发给接收方。
+
+接收方先进行解密，然后对解密结果执行 MAC 运算，比对发来的 MAC，验证正确性。
+
+**第三种方案，MtE (MAC then Encryption)**
+
+  
+
+![](https://pic3.zhimg.com/80/v2-6f19737c511032e834581d4433de245e_720w.webp)
+
+  
+
+_图片来自_ _[https://en.wikipedia.org/wiki/Authenticated_encryption](https://link.zhihu.com/?target=https%3A//en.wikipedia.org/wiki/Authenticated_encryption)_
+
+与 EtM 相反，先对原始数据执行 MAC 运算，与原始数据拼接后，执行加密算法，将密文发送给接收方。
+
+接受方先进行解密，然后执行 MAC 运算，验证解密结果是否正确。
+
+**然而，业内逐渐意识到以上通过组合加密和认证算法来实现 AEAD 的方案都是有安全问题的。**
+
+具体安全问题细节略去不表。
+
+**从 2008 年起，业内开始提出，需要在一个算法在内部同时实现加密和认证**
+
+基于这个思想，一些新的算法被提出，这些算法被称为真正的 AEAD 算法。
+
+常见的 AEAD 算法如下：
+
+- AES-128-GCM
+- AES-192-GCM
+- AES-256-GCM
+- ChaCha20-IETF-Poly1305
+- XChaCha20-IETF-Poly1305
+
+在具备 AES 加速的 CPU（桌面，服务器）上，建议使用 AES-XXX-GCM 系列，移动设备建议使用 ChaCha20-IETF-Poly1305 系列。
+
+在设计加密系统的时候，请务必选用 AEAD 算法，抛弃旧的 MtE，EtM，E&M 方案。
@@ -0,0 +1,227 @@
+**QKD、PQC 与 QRNG 的区别与联系**
+
+—— 量子时代的信息安全三重奏
+
+作者：量子信息技术专家  
+  
+日期：2026 年 6 月  
+  
+学科：量子信息 / 信息安全
+
+**摘 要**
+
+随着量子计算技术的快速演进，传统基于整数分解与离散对数难度的公钥密码体系面临根本性挑战。业界正沿着三条互补的技术路线构建"量子安全"防线：一是利用量子物理特性实现密钥分发的 QKD（Quantum Key Distribution，量子密钥分发），二是基于数学难题改造现有密码体系的 PQC（Post-Quantum Cryptography，后量子密码学），三是借助量子过程产生不可预测真随机数的 QRNG（Quantum Random Number Generator，量子随机数发生器）。本文以通俗易懂的方式，分别阐述三类技术的物理原理与工程实现，从底层机理、安全性假设、应用环节等维度系统对比其区别，并探讨三者在构建端到端量子安全体系中的协同关系，为科研与工程实践提供参考。
+
+关键词：量子密钥分发（QKD）；后量子密码学（PQC）；量子随机数发生器（QRNG）；量子安全；信息安全
+
+**目 录**
+
+_（请在 Word 中按 F9 或右键 → 更新域，以刷新目录）_
+
+**1 引言：量子时代的信息安全挑战**
+
+1994 年，Peter Shor 提出了能在多项式时间内分解大整数与计算离散对数的量子算法，理论上能够破解 RSA、ECC、Diffie-Hellman 等当前广泛使用的公钥密码体系。2025 年以来，IBM、Google、IonQ 等机构相继发布千比特乃至上万比特规模的量子计算原型机，虽然距离破解主流 RSA-2048 / RSA-4096 仍有数年光景，但学术界与产业界普遍认同一个名为"先收集，后解密"（Harvest Now, Decrypt Later, HNDL）的威胁模型：攻击者今天就开始截获并存储加密流量，等待未来量子计算机成熟后再回溯破解。
+
+这种"未来风险"被多国政府视为紧迫问题。
+
+为此，全球的应对策略大致分为三条技术路线，其英文缩写都以"Q"开头，常被初学者混淆：
+
+·QKD（Quantum Key Distribution，量子密钥分发）：利用量子力学原理实现安全的密钥协商，安全性由物理定律保证；
+
+·PQC（Post-Quantum Cryptography，后量子密码学）：在传统计算机上运行的、抗量子攻击的新一代公钥密码算法；
+
+·QRNG（Quantum Random Number Generator，量子随机数发生器）：利用量子过程产生不可预测的真随机数，为各类密码系统提供高质量熵源。
+
+三者看似都和"量子"相关，但它们处在不同的技术层级、解决不同的问题、有着截然不同的工程形态。本文将分别阐述其原理与作用，再从多个维度对比区别，最后探讨三者在量子安全体系中的协同关系。
+
+**2 QKD：量子密钥分发**
+
+**2.1 核心思想：把密钥的"安全性"从数学难题转移到物理定律**
+
+QKD 的目标并非加密数据本身，而是让通信双方在不安全的信道上协商出一串共享的随机比特序列——密钥。一旦两方拥有相同的密钥，就可以借助经典的对称加密（如 AES-256）进行高速加密通信，而密钥本身的安全性则由量子力学的不确定性原理与不可克隆定理保证。
+
+其关键洞察在于：单光子是不可分割的，量子态在被测量时会留下痕迹。因此，任何窃听行为都会扰动量子态，从而被合法通信双方所察觉。
+
+**2.2 主流协议：BB84、E91、BBM92 等**
+
+BB84 协议（Bennett 与 Brassard, 1984）是最经典的 QKD 方案。发送方 Alice 随机选择两组基（rectilinear 与 diagonal）对单光子进行偏振调制，接收方 Bob 也随机选择测量基；之后双方通过经典信道比对所用基，保留基一致的比特位作为密钥候选。由于窃听者 Eve 无法在不引入扰动的情况下同时测准两组基下的偏振态，任何窃听都会被基比对后的统计异常暴露。
+
+E91（Ekert, 1991）则使用量子纠缠光子对，将安全性论证建立在 Bell 不等式的违背上，提供了一种"设备无关 QKD"（DI-QKD）的雏形。MDI-QKD（Measurement-Device-Independent QKD）与 TF-QKD（Twin-Field QKD）进一步弱化了对硬件可信度的要求，是当前研究热点。
+
+**2.3 作用与应用场景**
+
+QKD 主要解决三类问题：
+
+·政府/金融专线：抗量子攻击的密钥协商；
+
+·数据中心互联：与 AES、SM4 等对称算法结合，构建"量子安全 VPN"；
+
+·跨国保密通信：可在光纤、卫星-地面（如墨子号实验）中部署。
+
+工程上比较有代表性的系统包括中国"京沪干线"（2009 km，2017 年开通）、欧洲量子互联网联盟（EuroQCI）试点，以及日本、韩国、英国等的国家级 QKD 试验网络。需要指出的是，QKD 自身只产出密钥，不直接替代现有的 TLS、IPSec 协议栈，因此 ETSI ISG-QKD 等标准化组织专注于 QKD 的接口规范与密钥管理协议。
+
+**3 PQC：后量子密码学**
+
+**3.1 设计哲学：用更难的数学问题代替"整数分解/离散对数"**
+
+PQC 与 QKD 思路完全不同。它不引入任何量子设备，纯粹在经典计算机上运行，但所依赖的数学难题被认为对量子计算机也是困难的。当前主流技术路线包括：
+
+1.格密码（Lattice-based）：基于 LWE/SIS 等问题的困难性，典型算法 CRYSTALS-Kyber、CRYSTALS-Dilithium；
+
+2.基于编码（Code-based）：基于一般线性码译码困难性，典型算法 Classic McEliece；
+
+3.基于哈希（Hash-based）：仅依赖哈希函数抗碰撞性，典型算法 SPHINCS+；
+
+4.多变量（Multivariate）：基于多变量二次方程组的求解困难性；
+
+5.基于同源（Isogeny-based）：曾被认为很有前景，但 2022 年 SIDH 攻击后，业界普遍转向混合方案。
+
+**3.2 NIST 标准化进程：从竞争到落地**
+
+2016 年起，美国 NIST 发起全球性的后量子密码标准化征集，2024 年 8 月正式发布首批 3 个标准：
+
+·FIPS 203（ML-KEM）：源自 Kyber，用于密钥封装；
+
+·FIPS 204（ML-DSA）：源自 Dilithium，用于数字签名；
+
+·FIPS 205（SLH-DSA）：源自 SPHINCS+，基于哈希的备用签名算法。
+
+后续标准 FIPS 206（FN-DSA，基于 Falcon）、Falcon 之外的多项候选项（NTRU、McEliece 等）也进入第四轮评估。这意味着，在未来 5–10 年内，全球主流浏览器、操作系统、TLS 协议栈将逐步集成 PQC 算法，与现有 RSA/ECC 形成"混合模式"过渡。
+
+**3.3 作用与应用场景**
+
+PQC 的最大优势在于：它可以"原位"替换现有公钥密码算法——TLS、SSH、S/MIME、PKI、区块链签名等场景几乎无需更换硬件，只要升级协议栈和证书即可。这使它成为短中期内最具落地可行性的抗量子方案。
+
+典型应用：TLS 1.3 的 X25519Kyber768 混合密钥交换、Google Chrome 已支持混合 Kyber；Apple iMessage PQ3 协议；Signal 协议引入 PQXDH；区块链签名逐步迁移至 Dilithium 等算法。
+
+**4 QRNG：量子随机数发生器**
+
+**4.1 为什么要"量子随机"**
+
+密码系统的安全性强烈依赖于密钥与随机数的不可预测性。但经典物理过程本质上是确定性的，通过软件伪随机数生成器（PRNG）产生的随机序列，在理论上可被攻击者重建；而基于经典噪声（如热噪声）的随机源，又易受环境与器件老化影响，难以通过严格的安全认证。
+
+量子过程则不同。放射性衰变、光子到达时间、电子自旋态等微观量子事件，在量子力学层面是真随机的——这并非"还不够复杂的伪随机"，而是物理定律本身就规定其不可预测。QRNG 正是将这种不可预测性转化为可用的二进制比特序列。
+
+**4.2 物理实现方式**
+
+·光子分支路径分支选择：单光子通过 50:50 分束器后到达两个探测器之一，输出即 0/1；
+
+·光子到达时间抖动：测量激光脉冲到达雪崩光电二极管的时间抖动；
+
+·真空态测量：探测真空场的正交分量，统计上满足最小不确定度；
+
+·相位扩散：利用激光相位扩散过程中的自发辐射量子噪声。
+
+近年来，芯片级 QRNG（基于 CMOS、氮化硅、硅光集成）使单器件成本降至几美元，可在移动设备、IoT 终端中集成。代表厂商包括 ID Quantique（瑞士）、QuantumCTek（科大国盾，中国）、Toshiba、QuintessenceLabs 等。
+
+**4.3 作用与应用场景**
+
+QRNG 提供"熵源"，是密码体系的底层基石：
+
+·为对称密钥、AES 密钥、SM4 密钥提供高质量种子；
+
+·为 PQC 算法中的拒绝采样、私钥生成提供真随机输入；
+
+·为 QKD 系统的 Alice/Bob 提供"真随机"基选择；
+
+·为区块链、彩票、博彩、科学仿真提供不可预测的随机数。
+
+**5 三者的主要区别**
+
+下表从底层物理原理、实现方式、安全性假设、应用环节四个维度，对 QKD、PQC、QRNG 进行系统对比。
+
+|   |   |   |   |
+|---|---|---|---|
+|**对比维度**|**QKD（量子密钥分发）**|**PQC（后量子密码学）**|**QRNG（量子随机数发生器）**|
+|技术本质|利用量子信道协商共享密钥|改造公钥算法以抗量子攻击|产生不可预测的真随机比特|
+|底层物理原理|量子态不可克隆、测量塌缩、Bell 不等式|纯粹数学（格、编码、哈希、同源等难题）|量子过程的内禀随机性（光子、电子、相位噪声）|
+|是否需要专用硬件|是（单光子探测器、相干激光、精密光路）|否，仅需经典计算机与 CPU/软算法|是（光子探测器或专用芯片）|
+|是否需要可信中继|理想情况下端到端，但工程上常需要可信节点|沿用现有 PKI 体系，无需可信中继|通常为本地设备，不涉及密钥分发|
+|安全性假设|量子物理定律 + 可信设备（或 DI-QKD）|数学难题对量子计算困难|量子过程真随机 + 经典后处理稳健|
+|算法/协议成熟度|实验阶段，逐步商用|NIST 首批标准已发布，FIPS 203/204/205 等|工程成熟，已有商业芯片与认证产品|
+|主要应用环节|密钥协商、补充 TLS/专线|替换 RSA/ECC，升级协议栈|为密钥与协议提供熵源|
+|对现有系统的改动|需要光纤或卫星链路、QKD 设备与密钥管理中间件|升级协议栈即可，对应用层几乎透明|插入随机数硬件模块或调用 API|
+|典型标准化机构|ETSI ISG-QKD、ITU-T、ISO/IEC JTC1|NIST、IETF、ISO/IEC SC27|NIST SP 800-90 系列、BSI AIS 20/31、ETSI|
+|主要短板|距离、密钥率、与现有协议融合；专用硬件成本|算法需要持续评估、密钥/签名尺寸大|需要严格的元数据检测与后处理，否则易受侧信道影响|
+
+**6 三者的内在联系：协同构建量子安全体系**
+
+**6.1 互补关系而非替代关系**
+
+在工程实践中，QKD、PQC、QRNG 之间的关系是"互补"，而非"替代"：
+
+·QKD 解决的是"通信两端如何协商到安全的密钥"；
+
+·PQC 解决的是"在没有量子信道的现实世界中如何保护通信"；
+
+·QRNG 解决的是"上述两者的随机性来自哪里"。
+
+在任何一个完整的量子安全体系中，三者都可以承担不同角色。
+
+**6.2 融合架构：一个端到端的量子安全通信栈**
+
+设想一次端到端量子安全的加密通信，其内部流程可能如下：
+
+6.启动阶段：Alice 端的 QRNG 产生真随机比特，作为会话主密钥（MK）的种子；
+
+7.密钥分发：若存在专用光纤或可信卫星链路，通过 QKD 协商一个"长期密钥"，作为 MK 的再加密保护层；若没有，则跳过此步；
+
+8.密钥封装：采用 PQC 算法（如 ML-KEM-768）将 MK 在公钥信道中封装、传输至 Bob；
+
+9.通信加密：Alice 与 Bob 用协商到的 MK 通过 AES-256/SM4 进行业务数据加密；
+
+10.身份认证：用 PQC 签名算法（ML-DSA、SLH-DSA）替代 RSA/ECDSA，防止中间人攻击。
+
+在这个栈中，QKD 提供了"物理层信任根"，PQC 提供了"协议层兼容性"，QRNG 提供了"全局熵源"。三者分工明确，缺一不可。
+
+**6.3 标准化与产业趋势**
+
+近两年，三类技术的标准化呈现明显融合趋势：
+
+·ETSI 在 QKD 与 PQC 之间开展"混合密钥交换"参考架构；
+
+·NIST 在 FIPS 203/204/205 之外发布 SP 800-90 系列对 QRNG 进行认证；
+
+·ISO/IEC JTC1 设立量子信息技术委员会（ISO/IEC JTC1/SC42 之外的 JC1/WG9），统一定义术语与参考框架；
+
+·中国在 2025 年发布的《量子保密通信技术白皮书》中也明确把 QRNG + QKD + PQC 作为协同方案。
+
+**7 总结与未来展望**
+
+QKD、PQC、QRNG——这三者名字相似，但本质不同：QKD 用"量子信道"交换密钥，PQC 用"新数学难题"保护公钥体系，QRNG 用"量子过程"提供真随机数。它们在技术栈中处于不同层级，针对不同威胁。
+
+展望未来 5–10 年，三条技术路线将呈现以下趋势：
+
+·短中期：PQC 主导，因其可"无痛升级"现有 PKI、TLS，将率先大规模落地；
+
+·中长期：QKD 在政府、金融、跨国专线领域小规模商用；芯片级 QRNG 将作为基础设施进入手机、服务器；
+
+·长期：量子互联网（Quantum Internet）概念走向工程化，QKD 与 QRNG 将成为量子网络的基础协议；
+
+·安全工程实践：抗侧信道攻击、密钥管理、设备认证仍是关键挑战；
+
+·标准化：NIST、ETSI、ITU、ISO 等机构之间的协同将决定量子安全体系的全球一致性。
+
+对从业者而言，理解 QKD、PQC、QRNG 三者的区别与联系，已经不再是学术兴趣，而是面向量子时代信息基础设施必须具备的工程素养。
+
+**参考文献**
+
+[1] Bennett C H, Brassard G. Quantum cryptography: Public key distribution and coin tossing[C]//Proceedings of IEEE International Conference on Computers, Systems and Signal Processing. 1984: 175-179.
+
+[2] National Institute of Standards and Technology. FIPS 203: Module-Lattice-Based Key-Encapsulation Mechanism (ML-KEM)[S]. Gaithersburg, MD: NIST, 2024.
+
+[3] National Institute of Standards and Technology. FIPS 204: Module-Lattice-Based Digital Signature Algorithm (ML-DSA)[S]. Gaithersburg, MD: NIST, 2024.
+
+[4] National Institute of Standards and Technology. FIPS 205: Stateless Hash-Based Digital Signature Standard (SLH-DSA)[S]. Gaithersburg, MD: NIST, 2024.
+
+[5] ETSI Industry Specification Group on Quantum Key Distribution (ISG-QKD). Quantum Key Distribution (QKD); Use Cases: ETSI GR QKD 003[S]. Sophia Antipolis: ETSI, 2018.
+
+[6] ISO/IEC JTC1. Information technology – Quantum computing – Vocabulary: ISO/IEC 4872:2024[S]. Geneva: ISO, 2024.
+
+[7] Herrero-Collantes I, Garcia-Escartin J C. Quantum random number generators[J]. Reviews of Modern Physics, 2017, 89(1): 015004. DOI: 10.1103/RevModPhys.89.015004.
+
+[8] 中国通信标准化协会. 量子保密通信技术白皮书[R]. 北京: 中国通信标准化协会, 2025.
+
+[9] 中国信息通信研究院. 量子信息技术发展与应用研究报告（2024 年）[R]. 北京: 中国信通院, 2024.
+
+[10] Shor P W. Algorithms for quantum computation: Discrete logarithms and factoring[C]//Proceedings of the 35th Annual Symposium on Foundations of Computer Science. IEEE, 1994: 124-134. DOI: 10.1109/SFCS.1994.365700.
@@ -0,0 +1,315 @@
+好的，这是一个非常专业且重要的问题。RSA 的 PKCS#5 填充和 PSS 填充是两种完全不同的方案，用于不同的场景，其核心区别在于**安全性**和**设计目的**。
+
+首先，需要纠正一个常见的术语混淆：
+*   **PKCS#5** 原本是为基于口令的加密（Password-Based Encryption）设计的，主要用于对称加密算法（如 DES）。当人们谈论 RSA 的“PKCS#5 填充”时，通常指的是 **PKCS#1 v1.5** 填充方案。这是一个历史遗留的误称，但已经非常普遍。
+
+因此，我们接下来的对比实际上是 **PKCS#1 v1.5** 与 **PSS** 的对比。
+
+---
+
+### 核心区别概览
+
+| 特性 | PKCS#1 v1.5 (常被误称为 PKCS#5) | PSS (Probabilistic Signature Scheme) |
+| :--- | :--- | :--- |
+| **主要用途** | **加密** 和 **签名** | **仅用于签名** |
+| **设计哲学** | 确定性 / 旧标准 | 概率性 / 新一代安全标准 |
+| **安全性可证明性** | **不可证明**。存在已知的理论攻击（如自适应选择密文攻击），但在实践中可通过其他方式缓解。 | **可证明安全**。在随机预言机模型下，其安全性可以归约到解决 RSA 问题的困难性上。 |
+| **随机性** | **确定性**（对于签名）。相同的消息和密钥总是产生相同的签名。 | **概率性**。每次对**同一消息**签名都会产生**不同的签名结果**，因为它引入了随机数（盐）。 |
+| **结构** | 格式固定，相对简单。 | 结构更复杂，使用掩码生成函数（MGF）和随机盐。 |
+| **抗攻击性** | 较弱。容易受到如 Bleichenbacher 攻击等，需要额外的防护措施。 | 更强。随机盐的引入使其能有效抵抗多种攻击，尤其是选择明文攻击。 |
+| **应用场景** | 旧系统、兼容性要求高的场景、TLS 1.2 及更早版本的 RSA 密钥交换。 | **新系统的首选**。TLS 1.3、现代密码学库（如 OpenSSL, Bouncy Castle）的默认推荐。 |
+
+---
+
+### 深入解析
+
+#### 1. PKCS#1 v1.5 填充（用于签名）
+
+这是一种确定性的填充方案。
+
+*   **过程**：
+    1.  对消息 `M` 进行哈希（如 SHA-256），得到哈希值 `H(M)`。
+    2.  构建一个特定的 **ASN.1** 数据结构，其中包含了哈希算法的标识符和哈希值 `H(M)`。这是为了确保签名和验证双方使用相同的哈希算法。
+    3.  将这个数据结构填充到与 RSA 模数 `n` 长度相同的块。填充方式是固定的：`0x00 0x01 0xff 0xff ... 0xff 0x00 || ASN.1 || H(M)`。
+    4.  对这个填充后的块进行 RSA 私钥运算（即 `s = pad(m)^d mod n`），生成签名 `s`。
+
+*   **缺点**：
+    *   **确定性**：相同的消息总是产生相同的签名，这为攻击者进行暴力破解或分析提供了便利。
+    *   **格式固定**：攻击者可以提交大量精心构造的报文给签名者进行签名，如果签名服务器没有严格验证解包后的结构格式，就可能泄露私钥信息。著名的 **Bleichenbacher 攻击** 就是利用了这个弱点。
+
+#### 2. PSS (Probabilistic Signature Scheme) 填充
+
+这是一种概率性的、更安全的填充方案。
+
+*   **过程**（简化版）：
+    1.  对消息 `M` 进行哈希，得到 `H(M)`。
+    2.  生成一个随机数 **salt**（盐）。
+    3.  将盐和消息哈希值一起进行哈希等运算，过程涉及掩码生成函数（MGF），最终构造一个复杂的、随机的待签名块。
+    4.  对这个随机的块进行 RSA 私钥运算，生成签名 `s`。**由于盐是随机的，所以每次签名结果都不同。**
+
+*   **优点**：
+    *   **安全性可证明**：数学上可以证明，破解 PSS 的难度等同于破解 RSA 基础问题本身。
+    *   **随机性**：有效防止攻击者通过收集签名来分析私钥。
+    *   **增强的冗余**：复杂的结构使得任何对签名或消息的篡改都极难通过验证。
+
+---
+
+### 总结与建议
+
+| 方面 | PKCS#1 v1.5 | PSS |
+| :--- | :--- | :--- |
+| **安全性** | 较低，有已知风险 | **高，是现代标准** |
+| **性能** | 稍快（因为计算简单） | 稍慢（因为引入了MGF和随机数生成） |
+| **兼容性** | **极高**，所有系统都支持 | 较好，现代系统和标准（如 TLS 1.3）都支持 |
+| **你应该选择？** | **仅在需要与旧系统保持兼容时使用**。 | **在任何新项目或系统中，只要允许，就应优先使用 PSS 进行签名。** |
+
+**重要提示：** 以上讨论主要围绕**签名**。对于 RSA **加密**，同样有对应的填充方案：
+*   RSA 加密的旧标准叫 **PKCS#1 v1.5 加密填充**。
+*   RSA 加密的新、更安全的标准叫 **OAEP (Optimal Asymmetric Encryption Padding)**。
+*   **PSS 只用于签名，不能用于加密。OAEP 用于加密，不能用于签名。**
+
+所以，完整的现代最佳实践是：
+*   **RSA 签名**：使用 **RSA-PSS**。
+*   **RSA 加密**：使用 **RSA-OAEP**。
+
+
+
+非常好的问题！这正是 RSA-PSS 设计中最精妙和关键的部分。
+
+简单直接的答案是：**Salt 值不需要单独存放或传输。它被“捆绑”并隐藏在最终的签名值中，验证方可以通过解码和计算过程将其恢复出来。**
+
+下面我们来详细拆解这个过程。
+
+### 1. PSS 签名的生成过程（含 Salt）
+
+首先，我们回顾一下签名方是如何生成 PSS 签名的。这个过程会清楚地展示 Salt 是如何被使用的。
+
+假设我们有：
+*   消息：`M`
+*   哈希函数：`Hash` (如 SHA-256)
+*   掩码生成函数：`MGF` (通常使用相同的哈希函数)
+*   RSA 模数长度：`k` 字节 (例如 2048 位 = 256 字节)
+*   Salt 长度：`sLen` (通常等于哈希输出的长度，例如 SHA-256 则为 32 字节)
+
+**签名步骤：**
+
+1.  **生成 Salt**：随机生成一个长度为 `sLen` 的盐值 `salt`。
+2.  **第一次哈希**：计算消息 `M` 的哈希值 `mHash = Hash(M)`。
+3.  **构造数据块 (DB)**：
+    *   创建一个由固定填充位、哈希算法标识和 Salt 组成的数据块。
+    *   结构为：`PS | 0x01 | salt`
+        *   `PS` 是一串 `0x00` 填充字节，其长度使得整个数据块 (DB) 加上其他部分恰好是 `k` 字节。
+        *   `0x01` 是一个固定的分隔符。
+4.  **计算 MGF 的输入**：
+    *   构造一个哈希块 `H`，通常为：`H = 0x00 | mHash | salt`
+    *   （注：实际标准格式为 `H = Hash(0x00 | mHash | salt)`，这里为简化理解，描述其核心思想）。
+5.  **应用掩码**：
+    *   使用 MGF 函数，以 `H` 为种子，生成一个与数据块 (DB) 长度相同的伪随机掩码 `dbMask`。
+    *   将数据块 (DB) 与这个掩码进行异或 (XOR) 操作，得到**掩码后的数据块 `maskedDB`**。`maskedDB = DB XOR dbMask`
+    *   这一步是核心，它用随机数（由 `H` 衍生）将 Salt 和固定填充位“加密”或“随机化”了。
+6.  **形成待签名的编码消息 (EM)**：
+    *   将 `maskedDB`、`H` 和固定的尾部填充拼接在一起，形成一个长度为 `k` 字节的编码消息 `EM`。
+    *   结构：`EM = maskedDB | H | 0xbc` (其中 `0xbc` 是一个固定的尾部标记)
+7.  **RSA 运算**：
+    *   将 `EM` 作为一个大整数，使用 RSA 的**私钥**对其进行签名运算（即 `s = EM^d mod n`），得到最终的签名值 `s`。
+
+**关键点：** Salt `s` 并没有被直接加密，而是被作为构造 `EM` 的一部分。整个 `EM` 被 RSA 私钥加密后，Salt 就被完美地“隐藏”在了最终的签名值 `s` 之中。
+
+---
+
+### 2. PSS 验证过程（如何恢复 Salt）
+
+验证方持有：消息 `M`、签名 `s`、以及发送方的 RSA **公钥**。
+
+**验证步骤：**
+
+1.  **RSA 解密**：
+    *   使用 RSA 的**公钥**对签名 `s` 进行“解密”运算（即 `EM' = s^e mod n`）。
+    *   如果签名有效，恢复出的编码消息 `EM'` 应该和签名时生成的 `EM` 完全相同。
+
+2.  **解析 EM‘**：
+    *   将 `EM‘` 按照约定的格式拆解，得到 `maskedDB‘`、`H’` 和尾部标记 `0xbc`。
+
+3.  **恢复数据块 (DB)**：
+    *   这是最巧妙的一步。验证方现在有 `H‘`，但它需要 `DB` 来计算 Salt。
+    *   它使用和签名方完全相同的 MGF 函数，以 `H’` 为种子，生成相同的掩码 `dbMask`。
+    *   将 `maskedDB‘` 与 `dbMask` 进行异或 (XOR) 操作，即可**还原出原始的数据块 `DB‘**。
+        `DB’ = maskedDB‘ XOR MGF(H’, length_of_maskedDB)`
+
+4.  **解析 DB’ 并提取 Salt**：
+    *   解析 `DB‘` 的结构。它应该由一串 `0x00` 字节、一个 `0x01` 的分隔符和最后的 `sLen` 字节的 Salt 组成。
+    *   验证方直接从这个还原出的 `DB’` 中**提取出最后 `sLen` 字节，这就是 Salt 值 `salt‘`**。
+
+5.  **重建与验证**：
+    *   验证方自己计算消息 `M` 的哈希 `mHash = Hash(M)`。
+    *   它使用刚提取的 `salt‘` 和计算出的 `mHash`，按照签名步骤 3 和 4 的方法，重建出哈希块 `H’’`。
+    *   **最终检查**：比较自己计算出的 `H’’` 和从 `EM’` 中解析出来的 `H‘` 是否完全相同。
+    *   如果两者一致，并且所有填充格式都正确，则签名验证通过。否则，失败。
+
+### 总结与图示
+
+**Salt 的流向可以概括为：**
+`salt` -> `DB` -> `maskedDB` -> `EM` -> `s` (签名值)
+
+**验证时 Salt 的恢复路径为：**
+`s` (签名值) -> `EM‘` -> `maskedDB‘` -> (`maskedDB‘` XOR `MGF(H’)`) -> `DB‘` -> `salt‘`
+
+**这种设计的巨大优势：**
+
+1.  **无需传输 Salt**：Salt 是自包含在签名中的，不需要额外的通信开销。
+2.  **安全性**：攻击者无法从签名 `s` 或 `maskedDB` 中直接看到或猜出 Salt，因为它被 MGF 生成的掩码保护着。只有能正确“解密”（即通过 XOR 操作）出 `DB` 的人才能得到 Salt，而这个操作需要正确的 `H‘`，这又依赖于原始消息 `M` 的正确性。
+3.  **确定性验证**：尽管签名本身是概率性的（每次不同），但验证过程是确定性的。对于给定的 `(M, s)`，验证结果总是确定的。
+
+希望这个详细的解释能帮助你彻底理解 PSS 中 Salt 的精妙之处！
+
+
+好的，我们来深入探讨一下 RSA-OAEP（Optimal Asymmetric Encryption Padding，最优非对称加密填充）。它是一种用于 RSA 加密的、可证明安全的填充方案，旨在取代不安全的 PKCS#1 v1.5 加密填充。
+
+### 核心设计思想
+
+OAEP 的设计灵感来自于 Feistel 网络，其核心思想是：
+1.  **概率性加密**：通过引入随机数，使得每次加密相同消息都会产生完全不同的密文。
+2.  **增强安全性**：其安全性在“随机预言机模型”下可以被证明（即破解它的难度等同于解决 RSA 难题本身）。
+3.  **防止攻击**：特别能够抵抗针对 PKCS#1 v1.5 的 **Bleichenbacher 选择密文攻击**。
+
+---
+
+### RSA-OAEP 的结构与加密过程
+
+OAEP 的加密过程就是构建一个特殊的、结构化的、待加密的“消息块”的过程。我们假设 RSA 的模数 `n` 的长度为 `k` 字节（例如，2048 位 = 256 字节）。
+
+**输入：**
+*   原始消息 `M`
+*   一个可选的标签 `L`（通常为空字符串，可以用于绑定特定上下文）
+*   一个随机数生成器
+*   两个哈希函数（通常为 `Hash` 和 `MGF`，MGF 是掩码生成函数，通常由另一个哈希函数构成）
+
+**步骤：**
+
+1.  **参数与长度检查**：
+    *   消息 `M` 不能太长。其最大长度受限于 `k - 2*hLen - 2`，其中 `hLen` 是哈希函数的输出长度（例如 SHA-256 则为 32 字节）。这为随机数和固定填充预留了空间。
+
+2.  **生成随机数**：
+    *   生成一个长度为 `hLen` 的随机字节串 `seed`（种子）。这是概率性的来源。
+
+3.  **构造数据块 DB**：
+    *   数据块 `DB` 由三部分拼接而成：
+        `DB = lHash | PS | 0x01 | M`
+    *   **lHash**：对可选标签 `L` 进行哈希计算得到的值 `Hash(L)`。如果 `L` 为空，这就是 `Hash("")`，一个固定值。它的主要作用是让接收方可以验证上下文的一致性。
+    *   **PS**：一串 `0x00` 字节，作为填充位。其长度使得整个 `DB` 的长度为 `k - hLen - 1` 字节。
+    *   **0x01**：一个固定的分隔符，用于区分填充位和真实消息。
+    *   **M**：原始消息。
+
+4.  **应用掩码（Masking）**：
+    *   这是 OAEP 最核心、最精妙的一步，它使用了掩码生成函数 `MGF`。
+    *   **用 seed 掩码 DB**：使用 MGF 函数，以 `seed` 为输入，生成一个与 `DB` 等长的掩码 `dbMask`。
+        `dbMask = MGF(seed, length_of_DB)`
+    *   将 `DB` 与 `dbMask` 进行异或操作，得到**掩码后的数据块 `maskedDB`**。
+        `maskedDB = DB XOR dbMask`
+    *   现在，`DB` 中的消息 `M` 已经被随机化了。
+
+5.  **掩码 seed**：
+    *   接下来，再用 `maskedDB` 去掩码 `seed`，完成一种“双向绑定”。
+    *   使用 MGF 函数，以 `maskedDB` 为输入，生成一个与 `seed` 等长（`hLen`）的掩码 `seedMask`。
+        `seedMask = MGF(maskedDB, hLen)`
+    *   将 `seed` 与 `seedMask` 进行异或操作，得到**掩码后的种子 `maskedSeed`**。
+        `maskedSeed = seed XOR seedMask`
+
+6.  **形成编码消息 (EM)**：
+    *   将处理后的各部分拼接起来，形成一个长度为 `k` 字节的、结构化的待加密块。
+        `EM = 0x00 | maskedSeed | maskedDB`
+    *   **0x00**：一个前导零，有助于确保整个 `EM` 表示的数值小于 RSA 模数 `n`。
+
+7.  **RSA 加密**：
+    *   将 `EM` 视为一个大整数。
+    *   使用 RSA 的**公钥** `(e, n)` 对其进行加密计算，得到最终的密文 `c`。
+        `c = EM^e mod n`
+
+**整个过程可以用下图直观表示（这是一个非常重要的概念图）：**
+
+```mermaid
+flowchart TD
+    subgraph Inputs [输入]
+        direction LR
+        M[消息 M]
+        L[标签 L<br>通常为空]
+        RNG[[随机数生成器]]
+    end
+
+    RNG -- 生成 --> seed[随机种子 seed<br>长度 hLen]
+    L -- 哈希 --> lHash[lHash = Hash(L)<br>长度 hLen]
+
+    subgraph Construction [构造数据块 DB]
+        direction LR
+        lHash
+        PS[填充串 PS<br>全零字节]
+        Delim[分隔符 0x01]
+        M
+        Construction_Output[DB = lHash | PS | 0x01 | M]
+    end
+
+    seed -- MGF1 --> dbMask[dbMask = MGF(seed, len(DB))]
+    Construction_Output -- XOR --> maskedDB[maskedDB = DB XOR dbMask]
+
+    maskedDB -- MGF1 --> seedMask[seedMask = MGF(maskedDB, hLen)]
+    seed -- XOR --> maskedSeed[maskedSeed = seed XOR seedMask]
+
+    maskedSeed --> EM[编码消息 EM]
+    maskedDB --> EM
+    EM --> Final[EM = 0x00 | maskedSeed | maskedDB]
+
+    Final -- 转换为整数 --> RSA[RSA公钥加密<br>c = EM⁡<sup>e</sup> mod n]
+    RSA --> Ciphertext[输出密文 c]
+```
+
+---
+
+### RSA-OAEP 的解密与验证过程
+
+解密是加密的逆过程，其核心是**恢复并验证 `EM` 的结构**。
+
+**输入：** 密文 `c`，私钥 `(d, n)`，标签 `L`（必须与加密时相同，通常为空）。
+
+**步骤：**
+
+1.  **RSA 解密**：
+    *   使用 RSA 的**私钥** `(d, n)` 对密文 `c` 进行解密，得到一个大整数。
+    *   将这个整数转换为长度为 `k` 字节的字节串，即恢复出编码消息 `EM`。
+    *   如果解密失败或 `EM` 的长度不为 `k`，则立即中止并返回错误。
+
+2.  **解析 EM**：
+    *   按照结构解析 `EM`：`EM = 0x00 | maskedSeed | maskedDB`
+    *   检查第一个字节是否为 `0x00`，如果不是，则说明密文无效，中止。
+
+3.  **恢复 seed**：
+    *   从 `EM` 中取出 `maskedSeed`（前 `hLen` 字节）和 `maskedDB`（剩余部分）。
+    *   计算 `seedMask`：`seedMask = MGF(maskedDB, hLen)`
+    *   恢复出随机种子 `seed`：`seed = maskedSeed XOR seedMask`
+
+4.  **恢复数据块 DB**：
+    *   计算 `dbMask`：`dbMask = MGF(seed, length_of_maskedDB)`
+    *   恢复出数据块 `DB`：`DB = maskedDB XOR dbMask`
+
+5.  **解析和验证 DB**：
+    *   这是**最关键的安全检查步骤**。
+    *   将 `DB` 解析为：`lHash' | PS | 0x01 | M'`
+    *   **验证**：
+        a. 计算 `Hash(L)`，与解析出的 `lHash‘` 比较，必须完全相同。
+        b. 检查填充串 `PS` 是否全部由 `0x00` 字节组成。
+        c. 检查 `0x01` 这个分隔符是否存在。
+    *   如果以上任何一项检查失败，**不应返回解密出的消息 `M‘`，而应返回一个通用的“解密错误”**。这是为了防止攻击者通过错误信息进行侧信道攻击（就像 Bleichenbacher 攻击那样）。
+
+6.  **输出明文**：
+    *   只有所有验证都通过，才输出解析出的消息 `M‘` 作为原始明文 `M`。
+
+### 总结与特点
+
+| 特性 | 说明 |
+| :--- | :--- |
+| **安全性** | **可证明安全**，抵抗选择密文攻击（CCA2）。是现代应用的首选。 |
+| **随机性** | **概率性加密**，依赖随机数 `seed`，相同明文每次加密产生不同密文。 |
+| **结构验证** | 解密时进行严格的格式验证（`lHash`，`PS`，`0x01`），任何无效输入都会导致失败，且不会返回任何具体错误信息。 |
+| **错误处理** | 必须**以一种“无信息”的方式失败**，不泄露任何关于失败原因的具体细节，这是其安全性的重要组成部分。 |
+| **应用** | TLS 1.3 中 RSA 加密的唯一指定方式。现代密码学库（如 OpenSSL, .NET, Java）的默认或推荐选项。 |
+
+简单来说，OAEP 通过引入随机数和两次掩码操作（MGF），将消息、随机数和固定哈希值“混合”成一个结构化的、随机化的整体，再交给 RSA 加密。解密方则通过反向操作和严格的格式检查来确保密文的完整性和真实性，任何篡改都会被检测并导致解密失败。这种设计使其极其安全。
@@ -0,0 +1,18 @@
+RSA 算法有：指数模、CRT 两种不同的实现方法。
+
+### **RSA 核心公式（指数模）**
+
+1. **密钥生成**：
+    - 选择两个大素数 `p` 和 `q`，计算模数 `n = p * q`
+    - 计算欧拉函数 `φ(n) = (p-1) * (q-1)`
+    - 选择公钥指数 `e`，满足 `1 < e < φ(n)` 且 `gcd(e, φ(n)) = 1`
+    - 计算私钥指数 `d = e⁻¹ mod φ(n)`（模逆元）
+        
+2. **加密/解密**：
+    - 加密：`c = m^e mod n`（明文 `m`，密文 `c`）
+    - 解密：`m = c^d mod n`
+        
+3. **签名/验签**：
+    - 签名：`s = m^d mod n`
+    - 验签：`m' = s^e mod n`，检查 `m' == m`
+
@@ -0,0 +1,146 @@
+RSA 算法是一种非对称加密算法。加密密钥（即公开密钥）PK 是公开信息，而解密密钥（即秘密密钥）SK是需要保密的。而加密算法 E 和解密算法 D 也都是公开的。虽然解密密钥 SK 是由公开密钥 PK 决定的，但却不能根据 PK 计算出 SK 。
+
+根据数论，寻求两个大素数比较简单，而将它们的乘积进行因式分解却极其困难，因此可以将乘积公开作为加密密钥称作公钥。如果公钥加密的信息只有私钥解得开，那么只要私钥不泄漏，通信就是安全的。
+
+
+#### 数学知识
+
+> **公因子**
+> 一个数学概念，指的是能同时整除几个整数的整数，可以用辗转相除法算出。
+
+
+**质数（素数）**
+
+>一个大于1的自然数，除了1和它自身外，不能被其他自然数整除的数叫做质数；否则称为合数（规定1既不是质数也不是合数）。
+
+
+**互质关系**
+
+>  如果两个正整数，除了1以外，没有其他公因子，我们就称这两个数是互质关系（coprime）。比如，15和32没有公因子，所以它们是互质关系。 两个合数存在互质关系吗？例如 15，44 也没有公因子，这说明不是质数也可以构成互质关系。
+
+**互质关系结论**
+_1. 任意两个质数构成互质关系，比如 13 和  61。_
+_2. 一个数是质数，另一个数只要不是前者的倍数，两者就构成互质关系，比如3和10。_
+_3. 如果两个数之中，较大的那个数是质数，则两者构成互质关系，比如97和57。_
+_4. 1和任意一个自然数是都是互质关系，比如1和99。_
+_5. p是大于1的整数，则 p和 p-1 构成互质关系，比如57和56。_
+_6. p是大于1的奇数，则 p和 p-2 构成互质关系，比如17和15。_
+
+**欧拉函数**
+请思考以下问题：
+
+>任意给定正整数n，请问在小于等于 n 的正整数之中，有多少个与n构成互质关系？（比如，在1到8之中，有多少个数与8构成互质关系？）
+
+计算这个值的方法就叫做[欧拉函数](https://zh.wikipedia.org/wiki/%E6%AC%A7%E6%8B%89%E5%87%BD%E6%95%B0)，以φ(n)表示。在1到8之中，与8形成互质关系的是1、3、5、7，所以 φ(n) = 4。
+
+φ(n) 的计算方法并不复杂，但是为了得到最后那个公式，需要一步步讨论。
+
+**第一种情况**
+
+如果n=1，则 φ(1) = 1 。因为1与任何数（包括自身）都构成互质关系。
+
+**第二种情况**
+
+如果n是质数，则 φ(n)=n-1 。因为质数与小于它的每一个数，都构成互质关系。比如5与1、2、3、4都构成互质关系。
+
+**第三种情况**
+
+如果n是质数的某一个次方，即 n = p^k (p为质数，k为大于等于1的整数)，则
+
+$$ \phi (\sideset{}{^k}p)=\sideset{}{^k}p-\sideset{}{^{k-1}}p $$
+
+比如 φ(8) = φ(2^3) =2^3 - 2^2 = 8 - 4 = 4。
+
+这是因为只有当一个数不包含质数p，才可能与n互质。而包含质数p的数一共有p^(k-1)个，即1×p、2×p、3×p、...、p^(k-1)×p，把它们去除，剩下的就是与n互质的数。
+
+上面的式子还可以写成下面的形式：
+
+$$ \phi (\sideset{}{^k}p)=\sideset{}{^k}p-\sideset{}{^{k-1}}p = \sideset{}{^k}p(1-\frac{1}{p}  )$$
+
+
+**第四种情况**
+如果n可以分解成两个互质的整数之积，
+
+> 　　n = p1 × p2
+
+则
+
+> 　　φ(n) = φ(p1p2) = φ(p1)φ(p2)
+
+即积的欧拉函数等于各个因子的欧拉函数之积。比如，φ(56)=φ(8×7)=φ(8)×φ(7)=4×6=24。
+
+这一条的证明要用到["中国剩余定理"](https://en.wikipedia.org/wiki/Chinese_remainder_theorem)，思路：如果a与p1互质(a<p1)，b与p2互质(b<p2)，c与p1p2互质(c<p1p2)，则c与数对 (a,b) 是一一对应关系。由于a的值有φ(p1)种可能，b的值有φ(p2)种可能，则数对 (a,b) 有φ(p1)φ(p2)种可能，而c的值有φ(p1p2)种可能，所以φ(p1p2)就等于φ(p1)φ(p2)。
+
+
+**第五种情况**
+因为任意一个大于 1 的正整数，都可以写成一系列质数的积。
+$$ n=\sideset{}{_1^{k1}}p\sideset{}{_2^{k2}}p...\sideset{}{_r^{kr}}p $$
+根据第4条的结论，得到
+$$  \phi(n)=\phi(\sideset{}{_1^{k1}}p)\phi(\sideset{}{_2^{k2}}p)...\phi(\sideset{}{_r^{kr}}p)  $$
+再根据第3条的结论，得到
+$$  \phi(n)=\sideset{}{_1^{k1}}p\sideset{}{_2^{k2}}p...\sideset{}{_r^{kr}}p(1-\frac{1}{\sideset{}{_1}p})(1-\frac{1}{\sideset{}{_2}p})(1-\frac{1}{\sideset{}{_r}p})  $$
+也就等于
+
+$$  \phi(n)=n(1-\frac{1}{\sideset{}{_1}p})(1-\frac{1}{\sideset{}{_2}p})(1-\frac{1}{\sideset{}{_r}p})  $$
+这就是欧拉函数的通用公式。例如计算 1323 在小于等于 1323 的正整数之中，有多少个与 n 构成互质关系？带入公式得到 756。真太神奇了。
+
+
+**欧拉定理**
+欧拉函数的用处，就在于欧拉定理。欧拉定理指的是：如果两个正整数a和n互质，则n的欧拉函数 φ(n) 可以让下面的等式成立：
+
+$$ \sideset{}{^{\phi(n)}}a\equiv 1 (\bmod n ) $$
+
+也就是说，a 的 φ(n) 次方被 n 除的余数为1。或者说，a的φ(n)次方减去1，可以被n整除。比如，3和7互质，而7的欧拉函数φ(7)等于6，所以3的6次方（729）减去1，可以被7整除（728/7=104）。
+
+欧拉定理的证明比较复杂，无力证明，只要记住它的结论就行了。
+
+欧拉定理可以大大简化某些运算。比如，7和10互质，根据欧拉定理有： $$ \sideset{}{^{\phi(10)}}7\equiv 1 (\bmod 10 ) $$
+已知 φ(10) 等于4，所以马上得到 7 的 4 倍数次方的个位数肯定是 1。
+
+
+
+**模反元素**
+
+如果两个正整数a和n互质，那么一定可以找到整数b，使得 ab-1 被n整除，或者说ab被n除的余数是1。
+
+$$ ab \equiv 1 (\bmod n )  $$
+
+这时，b就叫做a的["模反元素"](https://zh.wikipedia.org/wiki/%E6%A8%A1%E5%8F%8D%E5%85%83%E7%B4%A0)。
+
+比如，3和11互质，那么3的模反元素就是4，因为 (3 × 4)-1 可以被11整除。显然，模反元素不止一个， 4加减11的整数倍都是3的模反元素 {...,-18,-7,4,15,26,...}，即如果b是a的模反元素，则 b+kn 都是a的模反元素。
+
+
+
+### **RSA原理**
+
+**密钥生成过程**
+
+|步骤|概述|公式|说明|
+|---|---|---|---|
+|1|随机p，q|p,q |选择一对不相等且足够大的质数 |
+|2|求n|n = p\*q |计算质数p，q的乘积 |
+|3|求φ(n) |φ(n) = (p-1)(q-1) |计算 n 的欧拉函数|
+|4|求e|1 < e < φ(n)|选一个和 φ(n) 互质的整数e|
+|5|求d|ed = 1 (mod φ(n))|计算出e对于φ(n)的模反元素d|
+|6|公钥 |e,n|PK(e, n) |
+|7|私钥 |d,n |SK(d, n)|
+
+
+
+**第一步：随机 p，q**
+p，q 为不相等且足够大的质数。
+
+**第二步：求n**
+
+n 的长度就是密钥长度。例如：n = p * q = 11 * 3 = 33;
+
+33 写成二进制是100001，一共有6位，所以这个密钥就是6位。实际应用中，RSA密钥一般是1024位，重要场合则为2048位。
+
+
+**第三步：求 n 的欧拉函数φ(n)**
+
+根据欧拉函数，求 n 的欧拉函数φ(n)= φ(pq)= φ(p) φ(q)= (p-1)(q-1)
+
+**第四步：求e**
+
+> 随机选择一个整数e，条件是1< e < φ(n)，且e与φ(n) 互质。
@@ -0,0 +1,3 @@
+https://www.ruanyifeng.com/blog/2013/06/rsa_algorithm_part_one.html
+# RSA算法原理（一）
+[用同余加密——RSA算法的理论与基础实现](https://zhuanlan.zhihu.com/p/369674316)
@@ -0,0 +1,32 @@
+椭圆曲线密码学（Elliptic Curve Cryptography，ECC）中常用的曲线参数主要是由各种标准化组织定义的，包括但不限于：
+
+1. NIST（National Institute of Standards and Technology，美国国家标准与技术研究院）定义的曲线，例如：
+    - P-256（也称为 secp256r1）
+    - P-384（也称为 secp384r1）
+    - P-521（也称为 secp521r1）
+
+2. SECG（Standards for Efficient Cryptography Group）定义的曲线，例如：
+    - secp256k1（由于其在比特币中的使用而知名）
+
+3. ANSI（American National Standards Institute，美国国家标准协会）定义的曲线
+    
+4. Brainpool 曲线，例如：
+    - brainpoolP256r1
+    - brainpoolP384r1
+    - brainpoolP512r1
+
+5. FRP（Fast Randomizable Primality）曲线 
+
+国密 SM2 是中国自己定义的椭圆曲线密码算法标准，它不同于 NIST 或 SECG 定义的曲线。SM2 是由中国国家密码管理局推荐的公钥密码算法标准，它的全称是《SM2椭圆曲线公钥密码算法》。
+
+SM2 算法使用的椭圆曲线参数如下：
+
+- 椭圆曲线方程：y^2 = x^3 + ax + b
+- 素数 p（定义域的大小）：0xFFFFFFFEFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF00000000FFFFFFFFFFFFFFFF
+- 系数 a：0xFFFFFFFEFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF00000000FFFFFFFFFFFFFFFC
+- 系数 b：0x28E9FA9E9D9F5E344D5A9E4BCF6509A7F39789F5B645345C4C4FEA1E654DFF8B
+- 基点（G）的 x 坐标：0x32C4AE2C1F1981195F9904466A39C9948FE30BBFF2660BE1715A4589334C74C7
+- 基点（G）的 y 坐标：0xBC3736A2F4F6779C59BDCEE36B692153D0A9877CC62A474002DF32E52139F0A0 ^e79417
+- 阶 n：0xFFFFFFFEFFFFFFFFFFFFFFFFFFFFFFFF7203DF6B21C6052B53BBF40939D54123
+
+
@@ -0,0 +1,419 @@
+**号主：老杨丨11年资深网络工程师，更多网工提升干货，请关注公众号：网络工程师俱乐部**
+
+  
+
+上午好，我的网工朋友
+
+企业分支之间经常有互联的需求，企业互联的方式很多，可以使用专线线路或者Internet线路。  
+部分企业从成本和需求出发会选择使用Internet线路进行互联，但是使用Internet线路存在安全风险，如何保障数据在传输时不会被窃取？
+
+有的朋友会说[GRE](https://zhida.zhihu.com/search?content_id=252529020&content_type=Article&match_order=1&q=GRE&zhida_source=entity)，但**是在GRE隧道中不会对报文进行加密因此通过抓包是可以看到数据的报文信息，那怎么确保信息数据的安全呢？**
+
+这就要提到今天要讲的**[IPSec](https://zhida.zhihu.com/search?content_id=252529020&content_type=Article&match_order=1&q=IPSec&zhida_source=entity) VPN**了，一起来看看IPSec VPN是如何运作并确保信息安全的。
+
+  
+
+**今日文章阅读福利：****《 VPN技术思维导图 》**
+
+****既然讲到VPN相关，另外再分析一份VPN相关的好资源给你，私信我，发送暗号**“VPN”**，即可获取技术之路一把好武器。****
+
+  
+
+# **01** **IPSec基本概念**
+
+IPsec（IP Security）协议族是IETF制定的一系列安全协议，**它为端到端IP报文交互提供了基于密码学的、可互操作的、高质量的安全保护机制。**
+
+通过对数据加密、认证，IPsec使得数据能够在Internet网络上安全的传输。**IPsec VPN技术可以和多种VPN技术结合使用，使得企业互联更加灵活安全。**
+
+![](https://pic3.zhimg.com/v2-461cf3f9dcd7880ca34a126d2f84b644_1440w.jpg)
+
+IPSec隧道
+
+  
+
+![](https://pic2.zhimg.com/v2-cdc038282e5583760f0b872476076b2b_1440w.jpg)
+
+GRE Over IPSec
+
+**IPSec不是一个单独的协议，它给出了IP网络上数据安全的一整套体系结构**，包括[AH](https://zhida.zhihu.com/search?content_id=252529020&content_type=Article&match_order=1&q=AH&zhida_source=entity)、[ESP](https://zhida.zhihu.com/search?content_id=252529020&content_type=Article&match_order=1&q=ESP&zhida_source=entity)、[IKE](https://zhida.zhihu.com/search?content_id=252529020&content_type=Article&match_order=1&q=IKE&zhida_source=entity)等协议。
+
+![](https://pic1.zhimg.com/v2-f8acd5d3d08a032624afa141e274798e_1440w.jpg)
+
+  
+
+**IPSec体系结构**
+
+IPSec通过加密与验证等方式，从以下几个方面保障了用户业务数据在Internet中的安全传输:
+
+- **数据来源验证:**接收方验证发送方身份是否合法:
+    
+  
+- **数据加密:**发送方对数据进行加密，以密文的形式在nternet上传送，接收方对接收的加密数据进行解密后处理或直接转发;
+    
+
+- **数据完整性:**接收方对接收的数据进行验证，以判定报文是否被改;
+    
+  
+- **抗重放:**接收方拒绝旧的或重复的数据包，防止恶意用户通过重复发送捕获到的数据包所进行的攻击。
+    
+
+  
+
+****01 数据加密****
+
+**数据加密可以避免数据转发时被读取。数据加密一般有两种方案：**
+
+- **对称加密：**使用同一个密码加密/解密，效率很高，但是对称加密在互相交互密钥时存在密钥被截取的风险。
+    
+- **非对称加密：**使用公钥加密，私钥解密，安全性很高但是加解密效率很低。
+    
+
+  
+
+****02 数据认证****
+
+**数据认证的主要目的是确认数据是否被篡改，数据认证主要基于Hash算法。**
+
+- 数据通过Hash算法计算出一个唯一的Hash值，Hash值携带在数据中转发给对端。
+    
+  
+- 对端设备对数据重新进行Hash，得出Hash值。将收到的Hash值与计算出的Hash值进行比对，一致说明没有被篡改。
+    
+
+![](https://pic4.zhimg.com/v2-8987c97e8b087009f7170c13ff0f054f_1440w.jpg)
+
+数据认证方式简介
+
+  
+
+IPsec提供了两种安全机制：**加密和认证**。
+
+- IPsec采用对称加密算法对数据进行加密和解密。数据发送方和接收方使用相同的密钥进行加密、解密。
+    
+- IPsec采用HMAC（Hash-based Message Authentication Code）功能，比较数字签名进行数据完整性和真实性认证。
+    
+
+  
+
+****03 IPsec加密基本思路****
+
+IPsec同时使用对称加密与非对称加密，保证了安全也兼顾了性能。
+
+- 将对称加密所用的密钥，使用非对称算法加密并传递。
+    
+- 数据通过交互后的对称密钥加密。
+    
+
+![](https://pica.zhimg.com/v2-8165faddc5d68817e9736df6f8188bb2_1440w.jpg)
+
+IPsec加密基本思路
+
+  
+
+简单说就是双方通过使用非对称加密算法对同一密码进行加密得到一个对称秘钥，**然后使用该对称秘钥对数据进行加密**。一个前提就是密码是双方知道的，一般还是通过口头告知、文档等形式获取。
+
+  
+
+****04 安全联盟介绍****
+
+SA（Security Association，安全联盟） 可以帮助IPsec对特定要素进行约定，比如：**加密算法使用DES，认证算法使用MD5，封装方式使用Tunnel等。**
+
+IPsec技术在数据加密，数据验证，数据封装等方面有多种实现方式或算法，**两端的设备使用IPsec进行通信时需要保证一致的加密算法，验证算法等**。因此需要一种机制帮助两端设备协商这些参数。
+
+**建立IPsec SA一般有两种方式：**
+
+- **手工方式：**手工方式建立IPsec SA管理成本很高，加密验证方式需要手工配置，手工刷新SA，且SA信息永久存在安全性较低，适用于小型网络。
+    
+- **IKE方式：**IKE方式建立IPsec SA管理成本比较低，加密验证方式通过DH算法生成，SA信息有生成周期，且SA动态刷新，适用于小型，中大型网络。
+    
+
+IKE SA的主要作用是**构建一条安全的通道，用于交互IPsec SA。**
+
+IPsec SA，由一个三元组来唯一标识，这个三元组包括安全参数索引SPI、目的IP地址和使用的安全协议号（AH或ESP）。
+
+前面我们说到了IPSec框架中涉及到数据加密和认证，而实际情况下加密算法和认证算法很多，而IPSec中必须保证两端算法一致才能协商成功，那怎么协商呢？就是**通过SA来定义，通过在SA中指定加密算法、认证算法、封装模式、传输层协议等内容。**
+
+而在IPSec中有两个阶段：**IKE阶段和IPSec阶段，两个是承上启下的作用。**
+
+  
+
+****05 密钥交换介绍****
+
+**IPSec需要交互一个双方认可的对称秘钥，那怎么交互呢？**
+
+**现网中交互对称密钥一般会使用密钥分发协议：IKE（Internet Key Exchange，因特网密钥交换）。**
+
+IKE协议建立在[ISAKMP](https://zhida.zhihu.com/search?content_id=252529020&content_type=Article&match_order=1&q=ISAKMP&zhida_source=entity)（安全联盟和密钥管理协议）定义的框架上，是基于UDP的应用层协议。
+
+**它为IPsec提供了自动协商密钥、建立IPsec安全联盟的服务，能够简化IPsec的配置和维护工作。**
+
+![](https://pic3.zhimg.com/v2-bda576af0edfe2c74dd68cd486ba079c_1440w.jpg)
+
+密钥交换介绍
+
+  
+
+**IKE支持的认证算法有：**MD5、SHA1、SHA2-256、SHA2-384、SHA2-512、SM3。
+
+**I****KE支持的加密算法有：**DES、3DES、AES-128、AES-192、AES-256、SM1和SM4。
+
+ISAKMP由RFC2408定义，定义了**协商、建立、修改和删除SA的过程和包格式。**ISAKMP只是为SA的属性和协商、修改、删除SA的方法提供了一个通用的框架，并没有定义具体的SA格式。 **ISAKMP报文可以利用UDP或者TCP，端口都是500，一般情况下常用UDP协议，所以在防火墙上放通IPSec的流量可以允许UDP 500/4500端口的流量通过。**
+
+  
+
+****06 安全协议介绍****
+
+IPSec的加密与解密大致是在原有的报文头部增加一层或多层头部以实现加密，在传输层中
+
+IPsec有两种传输层协议提供认证或加密服务：**AH（认证头），ESP（封装安全载荷）。**
+
+- AH仅支持认证功能，不支持加密功能。
+    
+- ESP支持认证和加密功能。
+    
+
+AH仅支持认证功能，不支持加密功能。AH在每一个数据包的标准IP报头后面添加一个AH报文头。AH对数据包和认证密钥进行Hash计算，接收方收到带有计算结果的数据包后，执行同样的Hash计算并与原计算结果比较，传输过程中对数据的任何更改将使计算结果无效，这样就提供了数据来源认证和数据完整性校验。**AH协议的完整性验证范围为整个IP报文。**
+
+ESP支持认证和加密功能。 **ESP在每一个数据包的标准IP报头后面添加一个ESP报文头，并在数据包后面追加一个ESP尾（ESP Trailer和ESP Auth data）。**
+
+与AH不同的是，ESP将数据中的有效载荷进行加密后再封装到数据包中，以保证数据的机密性，但ESP没有对IP头的内容进行保护，除非IP头被封装在ESP内部（采用隧道模式）。
+
+**关键字段含义：**
+
+- **Sequence Number：**是一个从1开始的单项递增的计数器，唯一地标识每一个数据包，用于防止重放攻击。
+    
+- **SPI：**IPsec安全参数索引，用于唯一标识IPsec安全联盟。
+    
+- **Authentication Data：**该字段包含数据完整性校验值 ICV（Integrity Check Value），用于接收方进行完整性校验。可选择的认证算法有MD5、SHA1、SHA2、SM3。
+    
+
+简单理解就是将内网源IP怎样进行再封装增加传输层报头，AH仅支持认证功能，**不支持加密功能，而ESP支持认证和加密功能,我一般情况下都是使用的ESP协议**。
+
+![](https://pica.zhimg.com/v2-fec62d7afc822baaca14c7ac17d77ec0_1440w.jpg)
+
+ESP模式
+
+  
+
+![](https://pic4.zhimg.com/v2-64ba3d01bb8a70fa7e0c23739c0ed873_1440w.jpg)
+
+AH模式
+
+  
+
+![](https://pic2.zhimg.com/v2-cfd4ed3896f8331386238e450c6a8247_1440w.jpg)
+
+不同模式的报文抓包
+
+### 
+
+****07 封装模式介绍****
+
+在传输层使用安全协议还涉及到一个封装模式的问题。**封装模式是指将AH或ESP相关的字段插入到原始IP报文中，以实现对报文的认证和加密，封装模式有传输模式和隧道模式两种。**
+
+现网中多使用隧道模式进行封装。就是说这个报文的字段摆放顺序是怎样的。
+
+在传输模式中，AH头或ESP头被插入到IP头与传输层协议头之间，保护TCP/UDP/ICMP负载。**由于传输模式未添加额外的IP头，所以原始报文中的IP地址在加密后报文的IP头中可见。**
+
+在隧道模式下，AH头或ESP头被插到原始IP头之前，另外生成一个新的报文头放到AH头或ESP头之前，保护IP头和负载。
+
+**总结：**
+
+**IPSec是一个框架，通过IPSec实现的VPN称为IPSec VPN。IPSec通过加密和认证来实现安全传输。****第一阶段首先需要协商秘钥一致**，通过秘钥交换IKE来协商，生成一个IKE的SA(安全联盟)，里面定义了加密算法、认证算法、隧道模式等。
+
+**第二阶段使用一阶段的IKE SA进行加密数据**，可以选择AH或者ESP进行封装，AH不支持加密，ESP支持加密和认证，封装模式可以选择隧道模式或者传输模式，区别在于封装后数据包的头部不一样，一般情况下使用ESP安全协议以及隧道传输模式即可。
+
+  
+
+# **02** **IPSec VPN工作原理**
+
+IPsec的基本工作流程如下：
+
+- 通过IKE协商第一阶段协商出IKE SA。
+    
+- 使用IKE SA加密IKE协商第二阶段的报文，即IPsec SA。
+    
+- 使用IPsec SA加密数据。
+    
+
+![](https://pic1.zhimg.com/v2-96243e613ee4078e8179085238c62acc_1440w.jpg)
+
+IPsec基本工作流程
+
+  
+
+简单理解就是先创建一条安全协商的道路（IKE SA），然后通过IKE SA经过算法达到一个秘钥（IPSec SA）,接着使用IPSec SA对传输的流量进行加密与验证，这第三步就涉及到哪些流量需要加密，**我们需要通过一些方式将对应流量引入到IPSec VPN隧道中来进行传输。**
+
+  
+
+# **03** **IKE 协商**
+
+前面我们学习了IPSec双方需要协商出一个SA来进行算法的匹配，一般情况下我们使用IKE方式建立IPsec SA。**IKE是建立在ISAKMP定义的框架上，是基于UDP的应用层协议**。
+
+**它为IPsec提供了自动协商密钥、建立IPsec安全联盟的服务，能够简化IPsec的配置和维护工作。**
+
+简单说就是我们通过IKE这个框架协商出双方认可的**加密算法、认证算法、传输模式等等**。
+
+而IKE目前有两个版本：**[IKEv1](https://zhida.zhihu.com/search?content_id=252529020&content_type=Article&match_order=1&q=IKEv1&zhida_source=entity)和[IKEv2](https://zhida.zhihu.com/search?content_id=252529020&content_type=Article&match_order=1&q=IKEv2&zhida_source=entity)。**
+
+  
+
+****01 IKEv1****
+
+采用IKEv1协商安全联盟主要分为两个阶段：
+
+- **第一阶段：**通信双方协商并建立IKE协议本身使用的安全通道，即建立一个IKE SA；
+    
+  
+- **第二阶段：**利用第一阶段已通过认证与安全保护的安全通道，建立一对用于数据安全传输的IPsec SA。
+    
+
+![](https://pic2.zhimg.com/v2-91acb096759ca73ff526ff84b63c284b_1440w.jpg)
+
+IKEv1
+
+  
+
+**IKEv1协商第一阶段介绍：**
+
+IKEv1协商第一阶段的目的是建立IKE SA。**IKE SA建立后对等体间的所有ISAKMP消息都将通过加密和验证，这条安全通道可以保证IKEv1第二阶段的协商能够安全进行。**
+
+IKEv1协商第一阶段支持两种协商模式：**主模式（Main Mode） 和野蛮模式（Aggressive Mode）。**
+
+**主模式：**
+
+**主模式包含三次双向交换，用到了六条ISAKMP信息，协商过程如图1所示。这三次交换分别是：**
+
+- **消息①和②用于提议交换，发起方发送一个或多个IKE安全提议，响应方查找最先匹配的IKE安全提议，并将这个IKE安全提议回应给发起方。**匹配的原则为协商双方具有相同的加密算法、认证算法、认证方法和Diffie-Hellman组标识。
+    
+  
+- 消息③和④用于**密钥信息交换**，双方交换Diffie-Hellman公共值和nonce值，用于IKE SA的认证和加密密钥在这个阶段产生。
+    
+
+- 消息⑤和⑥用于**身份和认证信息交换（双方使用生成的密钥发送信息）**，双方进行身份认证和对整个主模式交换内容的认证。
+    
+
+**野蛮模式：**
+
+野蛮模式只用到**三条信息**，**前两条消息①和②用于协商IKE安全提议，交换Diffie-Hellman公共值、必需的辅助信息以及身份信息，并且消息②中还包括响应方发送身份信息供发起方认证，消息③用于响应方认证发起方。**
+
+与主模式相比，野蛮模式**减少了交换信息的数目**，提高了协商的速度，但是没有对身份信息进行加密保护。
+
+实际情况下如果双方都有公网IP使用主模式，如果一方是拨号网络使用野蛮模式，因为IP不固定，而且野蛮模式需要协商发起方主动向固定IP的一端发起，**野蛮模式安全性相对较低。**
+
+**IKEv1协商第二阶段介绍：**
+
+IKEv1协商第二阶段的目的是建立用来安全传输数据的IPsec SA，并为数据传输衍生出密钥。
+
+第二阶段采用**快速模式（Quick Mode）**。该模式使用IKEv1协商第一阶段中生成的密钥对ISAKMP消息的完整性和身份进行验证，并对ISAKMP消息进行加密，故保证了交换的安全性。
+
+![](https://pic4.zhimg.com/v2-84c7cb34d813267dd23a0bff8a86799b_1440w.jpg)
+
+快速模式协商过程
+
+  
+
+至此IKEv1就成功协商出了IKE SA和IPSec SA用于数据加密。
+
+  
+
+****02 IKEv2****
+
+**IKEv2简化了IKEv1协商SA的过程。IKEv2通常使用2次交换共4条消息就可以完成一对IPsec SA的建立**，如果要求建立的IPsec SA大于一对时，每一对IPsec SA只需额外增加1次创建子SA交换，也就是2条消息就可以完成。
+
+IKEv2定义了三种交换：**初始交换（Initial Exchanges）、创建子SA交换（Create_Child_SA Exchange）以及通知交换（Informational Exchange）**。
+
+  
+
+#### **1.初始交换**
+
+IKEv2通过初始交换就可以完成第一对IPsec SA的协商建立。初始交换包含两次交换四条消息。
+
+![](https://pic1.zhimg.com/v2-21cfaf691383be566b52ef05bab5bede_1440w.jpg)
+
+IKEv2初始交换介绍
+
+  
+
+**工作过程：**
+
+- 消息①和②属于**第一次交换**（称为IKE_SA_INIT交换），**以明文方式完成IKE SA的参数协商，包括协商加密和验证算法，交换临时随机数和DH交换**。IKE_SA_INIT交换后生成一个共享密钥材料，通过这个共享密钥材料可以衍生出IPsec SA的所有密钥。
+    
+  
+- 消息③和④属于**第二次交换**（称为IKE_AUTH交换），**以加密方式完成身份认证、对前两条信息的认证和IPsec SA的参数协商**。IKEv2支持RSA签名认证、预共享密钥认证以及扩展认证方法EAP（Extensible Authentication Protocol）。发起者通过在消息3中省去认证载荷来表明需要使用EAP认证。
+    
+
+就是如果是一条IPSec SA的建立只需要初始交换就可以完成，不需要用到子SA交换等等，更加简单快捷。
+
+报文抓包如下：
+
+只需要4个报文即可完成协商。
+
+![](https://pic4.zhimg.com/v2-61c76cc751c9f41c11046133b1f5c943_1440w.jpg)
+
+IKEv2是一次性把需要协商的数据都发送过去的模式。
+
+![](https://pic1.zhimg.com/v2-48fa5933d9312f32d5e87be5789e278e_1440w.jpg)
+
+IKEv2的初始交换中，**并没有直接区分为主模式（Main Mode）和野蛮模式（Aggressive Mode）这两种模式**，而是通过初始交换（Initial Exchanges）来完成类似于IKEv1中这两种模式的协商过程。
+
+**在IKEv2中，初始交换包括IKE_SA_INIT交换和IKE_AUTH交换，这两个交换过程顺序完成后，可以建立一个IKEv2 SA和一对IPsec SA。**
+
+**具体来说，IKEv2的初始交换配置如下：**
+
+- **IKE_SA_INIT交换：**这个交换完成IKEv2 SA参数的协商以及密钥交换。它对应于IKEv1的主模式的第1、3个包，以及野蛮模式的第1、2个包。
+    
+  
+- **IKE_AUTH交换：**这个交换完成通信对等体的身份认证以及IPsec SA的创建。它对应于IKEv1的主模式的第5、6个包，以及野蛮模式的第3个包。
+    
+
+**在IKEv2中，通过配置不同的认证方法和参数，可以实现类似于IKEv1中主模式和野蛮模式的功能。**例如，如果需要快速完成身份认证和密钥交换，可以使用类似于野蛮模式的配置，减少消息交换的数量。**如果需要更安全的身份认证过程，可以使用类似于主模式的配置，增加消息交换的数量以提供更强的安全性。**
+
+  
+
+#### **2.创建子SA交换介绍**
+
+当一个IKE SA需要创建多对IPsec SA时，需要使用创建子SA交换来协商多于一对的IPsec SA。**创建子SA交换还可以用于IKE SA的重协商。**
+
+创建子SA交换包含一个交换两条消息，对应IKEv1协商阶段2，交换的发起者可以是初始交换的协商发起方，也可以是初始交换的协商响应方。
+
+![](https://pic2.zhimg.com/v2-f2405e4af5ce12071708e35d446589e1_1440w.jpg)
+
+创建子SA交换介绍
+
+  
+
+#### **3.IKEv2通知交换介绍**
+
+运行IKE协商的两端有时会传递一些控制信息，例如错误信息或者通告信息，这些信息在IKEv2中是通过通知交换完成的。
+
+通知交换必须在IKE SA保护下进行，也就是说通知交换只能发生在初始交换之后。**控制信息可能是IKE SA的，那么通知交换必须由该IKE SA来保护进行；也可能是某子SA的，那么该通知交换必须由生成该子SA的IKE SA来保护进行。**
+
+![](https://pic2.zhimg.com/v2-c91630c533d997edf55a426171d29491_1440w.jpg)
+
+IKEv2通知交换介绍
+
+  
+
+# **04** **定义IPsec被保护流**
+
+**前面通过IKE已经协商出IPSec SA了，现在需要对分支间的数据进行保护，哪些流量需要进行加密保护呢？**我们需要通过一些方式来进行定义。
+
+IPsec是基于定义的感兴趣流触发对特定数据的保护，可以通过以下两种方式定义：
+
+- **ACL方式**，由ACL来指定要保护的数据流范围，筛选出需要进入IPsec隧道的报文。
+    
+- **路由方式**，通过IPsec虚拟隧道接口建立IPsec隧道，将所有路由到IPsec虚拟隧道接口的报文都进行IPsec保护。
+    
+
+ACL可以**更加精细控制源目地址、源目端口等流量，路由方式比较便捷**，但是**需要创建tunnel隧道接口方式**来实现，支持动态路由协议。
+
+通过IKE协商出**IPSec SA秘钥**，通过ACL或者路由匹配到感兴趣流量，最后将IPSec策略应用到指定的接口就可以实现IPSec VPN了。
+
+**总结：**
+
+通过IKE协商SA，IKE分v1和v2，一般情况下我用的应该是v1，v2可以快速协商出SA，然后通过ACL或者路由定义感兴趣流量，**将IKE提议、IPSec提议、创建IPSec策略、应用到接口串联起来就可以实现IPSec VPN的应用了，其实就是理论比较复杂，实际配置不算太难。**  
+
+  
+
+**整理：老杨丨11年资深网络工程师，更多网工提升干货，请关注公众号：网络工程师俱乐部**
@@ -0,0 +1,29 @@
+根据搜索结果，“TLCP”指的是**传输层密码协议**（Transport Layer Cryptography Protocol），是中国国家标准（GB/T 38636-2020）中定义的、完全采用国密算法（如SM2、SM3、SM4）的安全通信协议。
+
+至于GmSSL项目中为何能看到TLS 1.2、1.3和TLCP，却没有TLS 1.0和1.1，主要有两个原因：一是国密标准的特殊性，二是基于安全性和合规性的设计。
+
+为了让你更清晰地了解GmSSL所支持的协议及其特点，我整理了下面的表格：
+
+| 协议名称              | 标准依据                                       | GmSSL支持情况         | 主要特点与目的                                                 |
+| :---------------- | :----------------------------------------- | :---------------- | :------------------------------------------------------ |
+| **TLCP**          | 国家标准 **GB/T 38636-2020**，前身是GM/T 0024-2014 | **支持** (TLCP 1.1) | **纯国密算法**。为中国网络环境定制的传输层安全协议，强调合规性，是GmSSL的重点支持协议。        |
+| **TLS 1.3**       | 国际标准 (RFC 8446)                            | **支持**            | **现代国际标准**。安全性最高、性能最佳。GmSSL也支持其中国密算法套件（RFC 8998）。       |
+| **TLS 1.2**       | 国际标准 (RFC 5246)                            | **支持**            | **广泛兼容的国际标准**。为了与现有国际互联网生态兼容，GmSSL同样支持包含国密算法套件的TLS 1.2。 |
+| **TLS 1.1 / 1.0** | 国际标准 (已过时)                                 | **不支持**           | **陈旧且存在已知安全缺陷**。出于安全性考虑，现代密码库（包括GmSSL）通常已放弃支持。          |
+
+### 🔍 深入解析两个核心问题
+
+**1. TLCP是什么？**
+TLCP是一个独立的国家标准协议。它并非国际TLS协议的直接修改版，而是基于中国密码标准体系重新设计的。其核心特点包括：
+- **强制使用国密算法**：全面采用SM2（非对称加密/签名）、SM3（杂凑）、SM4（对称加密）等国密算法。
+- **独特的“双证书”体系**：要求服务器端同时使用“加密证书”和“签名证书”两套证书，将密钥交换与身份认证分离，增强了安全性与监管能力。
+- **独立的协议版本号**：为了避免与国际TLS协议混淆，TLCP在通信中使用独立的协议版本号 `0x0101`。
+
+**2. 为什么GmSSL不支持TLS 1.0/1.1？**
+这是GmSSL主动的设计选择，主要基于两方面原因：
+- **安全性考量**：TLS 1.0和1.1协议已被证实存在多个严重安全漏洞，在现代安全实践中已被普遍弃用。
+- **合规性聚焦**：GmSSL的核心目标是提供符合中国密码管理要求的解决方案。它优先实现了**代表国密标准的TLCP**，以及**当前最安全、最主流的国际标准TLS 1.3和广泛使用的TLS 1.2**，并在这些版本中集成了国密算法套件。这样既确保了合规，又兼顾了安全性与互通性。
+
+总而言之，你可以将GmSSL理解为：一个以支持**国密标准TLCP**为核心，同时兼容**安全的国际标准TLS 1.2/1.3（含国密套件）**，并主动摒弃了**过时不安全协议**的密码工具箱。
+
+如果你正在使用GmSSL进行开发，需要根据你的通信对方（是国密环境还是国际环境）来选择启用TLCP或TLS协议。
@@ -0,0 +1,28 @@
+TLS 1.0 与 TLS 1.1 的主要区别在于，TLS 1.1 是对 TLS 1.0 已知安全漏洞的**针对性修补版本**。虽然它们现在都已过时，但了解其区别有助于理解安全协议的演进脉络。
+
+下面的表格清晰地列出了它们的核心差异：
+
+| 特性/方面          | **TLS 1.0** (RFC 2246, 1999年)                      | **TLS 1.1** (RFC 4346, 2006年)                           | 区别的意义与影响                                  |
+| :------------- | :------------------------------------------------- | :------------------------------------------------------ | :---------------------------------------- |
+| **针对CBC攻击的防护** | **无**。初始化向量(IV)是显式且可预测的，易受**BEAST攻击**。             | **有**。规定必须使用**显式的、不可预测的IV**，并建议在记录中发送IV。                | 这是最重要的安全修补，直接封堵了TLS 1.0最危险的理论攻击路径之一。      |
+| **应对填充预言攻击**   | **无防护**。对填充错误的处理方式，可能泄露信息，导致**Lucky Thirteen**等攻击。 | **有改进**。规定必须统一所有错误的处理方式（统一返回“bad_record_mac”警报），但未根本解决。 | 提高了攻击难度，但真正的解决是在TLS 1.2中引入了HMAC等更健壮的验证方式。 |
+| **IANA注册与扩展**  | **未明确定义**。对协议扩展和新算法的支持方式比较模糊。                      | **明确定义**。为算法参数等引入了IANA注册机制，为未来协议扩展铺平了道路。                | 提升了协议的灵活性和可维护性，是协议成熟化的标志。                 |
+| **其他调整**       | 依赖**MD5/SHA-1**等较弱的哈希函数。                           | 新增对 **AES** 密码套件的正式支持。                                  | 反映了当时密码学的发展，但未触及核心算法弱点。                   |
+
+### 🔍 核心区别详解
+
+**1. 对抗CBC攻击：从“可预测”到“显式IV”**
+这是最关键的改进。在TLS 1.0中，每条加密记录的初始向量(IV)是**从前一条记录的密文中推导出来的**，这使得攻击者有可能预测并构造恶意请求（BEAST攻击）。TLS 1.1强制要求每条记录的IV都必须是**独立、显式且不可预测的**，从根本上切断了这种攻击的可能性。
+
+**2. 错误处理：从“信息泄露”到“统一模糊”**
+在TLS 1.0中，服务器对接收到的错误数据包（如填充错误、MAC校验错误）可能会返回不同的错误警报。攻击者可以像“询问神谕”一样，通过观察这些细微的差异来逐步破解密文。TLS 1.1规定，对于这类错误必须**统一返回完全相同的通用错误警报**，使攻击者无法从服务器响应中获取有效信息。
+
+### 💎 总结与定位
+
+- **关系**：TLS 1.1本质上是TLS 1.0的**安全补丁版**。它修复了最紧迫的安全问题，但没有进行架构或算法上的重大革新。
+- **根本局限**：两者都**深度依赖已不安全的MD5和SHA-1哈希算法**，且TLS 1.1未能完全解决填充预言攻击（直到TLS 1.2才彻底解决）。因此，它们的安全基线在当今看来仍然很低。
+- **现状**：**TLS 1.0和1.1均已遭全球淘汰**。所有主流浏览器、操作系统和现代安全标准（如PCI DSS）都已默认禁用它们。目前的标准是**TLS 1.2和1.3**。
+
+因此，虽然TLS 1.1比1.0更安全，但这只是“五十步”与“一百步”的区别。在现代应用中，两者都应被**视为不安全协议而严格禁用**。
+
+如果你是在维护一个必须兼容古董设备的特殊系统，了解这些细节可能有用；但在任何新项目或安全审计中，正确的做法都是直接启用TLS 1.2/1.3，并明确禁用1.0和1.1。
@@ -0,0 +1 @@
+deliver 函数
@@ -0,0 +1,65 @@
+
+进入编译环境
+sh dev.sh
+
+
+进入 nginx 目录
+cd nginx-1.18.0
+
+make clean
+修改版编译参数
+```
+./configure \
+--prefix=/usr/local/nginx \
+--with-http_ssl_module \
+--with-http_stub_status_module \
+--with-http_realip_module \
+--with-http_auth_request_module \
+--with-threads \
+--with-openssl="/app/gmssl/gmssl" \
+--with-cc-opt="-Iapp/gmssl/gmssl/include" \
+--with-ld-opt="-lm" \
+--with-stream \
+--with-stream_ssl_module \
+--with-debug
+```
+
+
+GMSSL 版本（不建议）
+```
+./configure --prefix=/usr/local/nginx \
+--with-http_ssl_module \
+--with-gmssl=./GmSSL/ \
+--with-stream \
+--with-stream_ssl_module \
+--without-http_upstream_zone_module \
+--without-stream_upstream_zone_module \
+--with-http_auth_request_module \
+--with-debug
+```
+
+
+GMSSL 版本（不建议）
+```
+./configure --prefix=/usr/local/nginx --with-http_ssl_module --with-http_auth_request_module --without-http_upstream_zone_module --with-gmssl=./GmSSL/ --with-debug
+```
+
+
+
+make
+make install
+
+容器内路径：/usr/local/nginx
+容器外路径：/app/ssl/gateway.lib/target-nginx
+
+
+
+进入 docker-image 目录，进行容器构建。
+拷贝 nginx 文件为 gateway
+test1.sh 测试
+国密浏览器访问 8443 端口
+
+打包
+sh build.sh
+docker tag gateway.lib gateway.lib:20251209
+docker save gateway.lib:20251209 -o gateway.lib.20251209.tar
@@ -0,0 +1,634 @@
+该文章已生成可运行项目，预览并下载项目源码
+
+      在[数字经济](https://so.csdn.net/so/search?q=%E6%95%B0%E5%AD%97%E7%BB%8F%E6%B5%8E&spm=1001.2101.3001.7020)加速发展的今天，网络通信安全已成为关键基础设施的核心保障。我国自主研发的国密算法（如 SM2、SM3、SM4 等）作为国家密码标准，在金融、政务、能源等关键领域的合规要求日益明确。然而，传统 Web 服务器（如 Nginx）主要支持国际通用加密算法（如 RSA、ECC），难以直接满足国密合规需求。在此背景下，openHiTLS 社区推出的 “nginx-with-openHiTLS” 项目应运而生，通过集成自主创新的 openHiTLS 密码库，为 Nginx 赋予国密算法与 TLCP 协议支持，成为构建安全可靠加密体系的重要技术方案。
+
+### 国密改造的核心诉求：
+
+       [国密算法](https://so.csdn.net/so/search?q=%E5%9B%BD%E5%AF%86%E7%AE%97%E6%B3%95&spm=1001.2101.3001.7020)（国家商用密码算法）是我国自主设计的加密标准，包括 SM2（非对称加密）、SM3（哈希算法）、SM4（对称加密）等，旨在保障国家信息安全与数据主权。随着《网络安全法》《密码法》等法规的实施，关键行业对 “国密合规” 的要求已从 “可选” 变为 “强制”。
+
+      传统 Nginx 作为全球主流的 Web 服务器，虽支持 TLS 1.2/1.3 等国际协议，但缺乏对国密算法及 TLCP（传输层密码协议，我国基于国密算法的 TLS 协议标准）的原生支持。若要在关键业务中使用 Nginx，必须通过技术改造实现国密协议与算法的集成 —— 这正是 openHiTLS 社区的核心目标：**基于 Nginx 稳定版本（1.24），通过集成 openHiTLS 密码库，让 Web 服务无缝支持国密标准，同时保留 Nginx 原有的高性能与稳定性**。
+
+### nginx-with-openHiTLS：技术特性解析
+
+nginx-with-openHiTLS 并非对 Nginx 的重构，而是在其基础上进行模块化扩展，核心特性包括：
+
+1. **原生支持 TLCP 协议**  
+    作为国密标准的传输层协议，TLCP 可基于 SM2/SM3/SM4 算法实现端到端加密，解决了传统 TLS 协议依赖国际算法的合规性问题。
+    
+2. **兼容 TLS 1.2 协议**  
+    保留对国际通用协议的支持，满足混合加密场景需求（如同时服务国内合规用户与国际用户）。
+    
+3. **完善的客户端证书验证机制**  
+    支持基于国密证书的双向认证，可通过配置 CA 证书链与验证深度，强化对客户端身份的合法性校验，适用于金融交易、政务服务等高安全场景。
+    
+
+### 部署指南：从编译到运行的全流程
+
+nginx-with-openHiTLS 的部署需依赖 openHiTLS 密码库的编译与集成，以下为详细步骤（基于 Linux 系统）：
+
+#### 1. 环境准备
+
+确保系统满足基础依赖：
+
+- 操作系统：Linux（如 CentOS、Ubuntu）
+- 编译工具：GCC 编译器、Make 工具
+- 依赖库：PCRE（正则表达式支持）
+
+#### 2. 编译 openHiTLS 密码库
+
+bash
+
+```cobol
+# 1. 克隆代码仓库git clone https://gitcode.com/openHiTLS/openhitls.git # 2. 进入目录并创建构建文件夹cd openHiTLS && mkdir -p ./build && cd ./build # 3. 生成构建配置（根据架构选择）# 3.1 通用64位构建python3 ../configure.py --enable hitls_bsl hitls_crypto hitls_tls hitls_pki hitls_auth --lib_type static --bits=64 --system=linux # 3.2 x86_64架构优化构建python3 ../configure.py --enable hitls_bsl hitls_crypto hitls_tls hitls_pki hitls_auth --lib_type static --bits=64 --system=linux --asm_type x8664 # 3.3 armv8架构优化构建python3 ../configure.py --enable hitls_bsl hitls_crypto hitls_tls hitls_pki hitls_auth --lib_type static --bits=64 --system=linux --asm_type armv8 # 4. 生成构建脚本并编译安装cmake ..make && make install
+```
+
+#### 3. 编译并安装 nginx-with-openHiTLS
+
+bash
+
+```cobol
+# 1. 配置Nginx编译选项（指定openHiTLS路径）cp auto/configure ../configure --prefix=/path/to/install \  --with-cc-opt="-std=c99" \  --with-http_ssl_module \  --with-openhitls=/path/to/openhitls  # 替换为openHiTLS实际安装路径 # 2. 编译并安装make && make install
+```
+
+#### 4. 国密协议配置示例
+
+部署完成后，需通过 Nginx 配置文件启用 TLCP 协议与国密证书，典型配置如下：
+
+nginx
+
+```cobol
+server {    listen 443 ssl;    server_name example.com;  # 替换为实际域名     # 启用TLCP协议（国密传输层协议）    ssl_protocols TLCP;        # 国密证书配置（需同时指定签名与加密证书）    ssl_certificate /path/to/sign.crt;     # 签名证书（SM2）    ssl_certificate /path/to/enc.crt;      # 加密证书（SM2）    ssl_certificate_key /path/to/sign.key; # 签名私钥    ssl_certificate_key /path/to/enc.key;  # 加密私钥        # 客户端证书验证（双向认证场景）    ssl_verify_client on;                         # 开启客户端验证    ssl_client_certificate /path/to/ca-chain.crt; # 客户端CA证书链    ssl_verify_depth 3;                           # 验证深度（最多追溯3级CA）}
+```
+
+#### 5. 启动与验证
+
+bash
+
+```cobol
+# 进入安装目录cd /path/to/nginx # 指定配置文件启动./sbin/nginx -c ./conf/nginx.conf # 验证启动状态（查看错误日志排查问题）tail -f /path/to/nginx/error.log
+```
+
+### 关键注意事项与故障排除
+
+1. **证书格式与权限**  
+    国密证书需使用 PEM 格式，且证书 / 私钥文件权限需限制为`600`（仅所有者可读写），避免权限泄露导致安全风险。
+    
+2. **TLCP 协议的特殊要求**  
+    启用 TLCP 时必须同时配置签名证书与加密证书（国密算法设计要求），缺少任一证书会导致协议握手失败。
+    
+3. **常见错误排查**
+    
+    - 证书格式错误：通过`openssl x509 -in cert.crt -text`验证 PEM 格式合法性；
+    - 依赖缺失：编译失败时检查 GCC、PCRE 等依赖是否安装完整；
+    - 协议不兼容：客户端需支持 TLCP 协议才能建立连接，可通过`openssl s_client -connect example.com:443 -tls1_2`测试基础连通性。
+
+### 开源实践：nginx-with-openHiTLS开源代码实现
+
+代码下载链接：[GitCode - 全球开发者的开源社区,开源代码托管平台](https://gitcode.com/openHiTLS/nginx/tree/branches/stable-1.24/src "GitCode - 全球开发者的开源社区,开源代码托管平台")
+
+> 【openHiTLS密码开源社区】
+> 
+>  openHiTLS旨在打造算法先进、性能卓越、高效敏捷、安全可靠的密码套件，通过轻量级、可剪裁的软件技术架构满足各行业不同场景的多样化要求，让密码技术应用更简单，同时探索后量子等先进算法创新实践，构建密码前沿技术底座！  
+>  项目地址:[https://gitcode.com/openHiTLS/openhitls](https://gitcode.com/openHiTLS/openhitls "https://gitcode.com/openHiTLS/openhitls")
+
+![](https://i-blog.csdnimg.cn/direct/c19256d9901241a6a30afa567744a1bc.png)密码开源先锋聚焦密码学与开源技术的知识分享平台
+
+![](https://g.csdnimg.cn/extension-box/2.0.0/image/weixin.png)微信公众号
+
+![](https://g.csdnimg.cn/extension-box/2.0.0/image/ic_move.png)
+
+本文章已经生成可运行项目一键运行
+
+生成项目![查看更多](https://csdnimg.cn/release/blogv2/dist/pc/img/btnInscodeAiAskWhite.png)
+
+关注博主即可阅读全文 ![](https://csdnimg.cn/release/blogv2/dist/pc/img/arrowDownAttend.png) 
+
+[![](https://i-avatar.csdnimg.cn/355cd0deee474cf1ba93a435aae2c294_openHiTLS.jpg!1)openHiTLS密码开源社区](https://openhitls.blog.csdn.net/)
+
+关注
+
+- ![](https://csdnimg.cn/release/blogv2/dist/pc/img/toolbar/like.png)38
+- ![](https://csdnimg.cn/release/blogv2/dist/pc/img/toolbar/unlike.png)
+- ![](https://csdnimg.cn/release/blogv2/dist/pc/img/toolbar/collect.png)32
+    
+    觉得还不错?一键收藏![](https://csdnimg.cn/release/blogv2/dist/pc/img/collectionCloseWhite.png)
+    
+- [![](https://csdnimg.cn/release/blogv2/dist/pc/img/toolbar/comment.png)0](https://blog.csdn.net/openHiTLS/article/details/150497042#commentBox)
+- ![](https://csdnimg.cn/release/blogv2/dist/pc/img/toolbar/share.png)分享
+- ![](https://csdnimg.cn/release/blogv2/dist/pc/img/toolbar/more.png)
+
+专栏目录
+
+[
+
+_nginx_ 同一端口同时支持_国密_和标_密_功能
+
+](https://blog.csdn.net/Big_Bristlegass/article/details/140845641)
+
+[Big_Bristlegass的博客](https://blog.csdn.net/Big_Bristlegass)
+
+ ![](https://csdnimg.cn/release/blogv2/dist/pc/img/readCountWhite.png) 1810
+
+[
+
+_nginx_支持同一端口，支持_国密_和标_密_
+
+](https://blog.csdn.net/Big_Bristlegass/article/details/140845641)
+
+[
+
+_NGINX_学习记录__nginx_ root
+
+](https://blog.csdn.net/qq_43542296/article/details/127204254)
+
+12-19
+
+[
+
+worker_processes和worker_connections可以实际的设置_nginx_的总体最大连接数,比如worker_processes设置为2,worker_connections设置为1024,那么_nginx_的总体最大连接数就是2048个。但是这些连接数,不仅包含了_nginx_和客户端的链接,还包含了_nginx_和被代理的服务端的链接,因此不代表_nginx_的并发能力是2048,具体设置多少,要根据压测...
+
+](https://blog.csdn.net/qq_43542296/article/details/127204254)
+
+[
+
+HTTPS配置_-__-_基于_nginx_
+
+](https://blog.csdn.net/nero_claudius/article/details/91891384)
+
+12-12
+
+[
+
+_nginx__:_[emerg]the"ssl"parameter requires ngx_http_ssl_modulein/usr/local/_nginx_/conf/_nginx_.conf 智能体编程shell 1 查看你最初配置_nginx_时的参数 /usr/local/_nginx_/sbin/_nginx_ _-_V 智能体编程shell 1 显示如下(如果没有–_with__-_http_ssl_module,则说明未添加http_ssl_module模块) configure arguments_:_ _-__-_pref...
+
+](https://blog.csdn.net/nero_claudius/article/details/91891384)
+
+[
+
+_nginx__国密_证书(gmssl)安装
+
+](https://blog.csdn.net/qq_44877496/article/details/138184055)
+
+[qq_44877496的博客](https://blog.csdn.net/qq_44877496)
+
+ ![](https://csdnimg.cn/release/blogv2/dist/pc/img/readCountWhite.png) 4237
+
+[
+
+本文档基于此安装包安装若目标机无法上网，无法执行yum，可通过手动下载安装包，rpm执行安装，部分rpm安装包如下。
+
+](https://blog.csdn.net/qq_44877496/article/details/138184055)
+
+[
+
+_nginx_深度学习2——https之生成秘钥和CA证书
+
+](https://blog.csdn.net/qq_22059611/article/details/89082938)
+
+[苏云南雁的博客](https://blog.csdn.net/qq_22059611)
+
+ ![](https://csdnimg.cn/release/blogv2/dist/pc/img/readCountWhite.png) 665
+
+[
+
+openssl version 查看 _nginx_ _-_v 1，生成秘钥和CA证书 步骤一：生成key秘钥 步骤二：生成证书签名请求文件（csr文件） 步骤三：生成证书签名文件（CA证书，一般是第三方，学习过程可以自己弄） 具体步骤，在_nginx_下建立一个目录，输入： openssl genrsa _-_idea _-_out jesonc.key 1024 然后输入验证_密_码，然后...
+
+](https://blog.csdn.net/qq_22059611/article/details/89082938)
+
+[
+
+配置_Nginx_,完善_Nginx_启动脚本_上线时脚本修改_nginx_配置
+
+](https://blog.csdn.net/jun54555/article/details/4207961)
+
+12-18
+
+[
+
+Starting _nginx__-_0.6.17_:_ start_-_stop_-_daemon_:_ /lib/tls/libc.so.6_:_ version `GLIBC_2.4' not found (required by start_-_stop_-_daemon) # ls _-_lt /lib/tls/libc* # 版本过低,在Ubuntu中【/lib/libc.so.6 _-_> libc_-_2.6.1.so】 lrwxrwxrwx 1 root root 13 Mar 1 2007 /lib/tls/libc.so.6 _-_> l...
+
+](https://blog.csdn.net/jun54555/article/details/4207961)
+
+[
+
+深度学习_Nginx_第二章_:__Nginx_ 关于SSL安全协议__nginx_ ssl 算法
+
+](https://blog.csdn.net/ligupeng7929/article/details/97752462)
+
+9-27
+
+[
+
+深度学习_Nginx_第二章_:__Nginx_ 关于SSL安全协议 本文深入探讨了_Nginx_在SSL安全协议中的作用,包括对称加_密_、非对称加_密_原理,CA如何验证证书及防止证书过期,以及不同类型的SSL证书。此外,还详细介绍了TLS通讯过程,并着重分析了_Nginx_在握手性能方面的考虑,特别是对称加_密_和非对称加_密_算法的影响。
+
+](https://blog.csdn.net/ligupeng7929/article/details/97752462)
+
+[
+
+【_密_码学实战】_openHiTLS_ mac命令行：消息认证码工具
+
+最新发布
+
+](https://openhitls.blog.csdn.net/article/details/152713883)
+
+[开源代码仓：https://gitcode.com/openHiTLS/openhitls](https://blog.csdn.net/openHiTLS)
+
+ ![](https://csdnimg.cn/release/blogv2/dist/pc/img/readCountWhite.png) 1107
+
+[
+
+`hitls mac`是_openHiTLS__密_码工具包中用于计算消息认证码（MAC）的命令行工具，核心功能为验证消息完整性与真实性。它支持HMAC、CMAC、GMAC及_国密_（SM3、SM4_-_CBC_-_MAC）等多类算法，提供_密_钥（明文/十六进制）、输入输出（文件/标准流、二进制/十六进制）等丰富选项，兼具硬件加速、大文件分块处理等性能优化特性。
+
+](https://openhitls.blog.csdn.net/article/details/152713883)
+
+[
+
+天安tassl+原生_nginx_搭建_国密_网站
+
+](https://blog.csdn.net/qlau2007/article/details/139225533)
+
+[qlau2007的博客](https://blog.csdn.net/qlau2007)
+
+ ![](https://csdnimg.cn/release/blogv2/dist/pc/img/readCountWhite.png) 2107
+
+[
+
+基于天安tassl和原生_nginx_搭建_国密_网站测试
+
+](https://blog.csdn.net/qlau2007/article/details/139225533)
+
+[
+
+_Nginx___nginx_100%windows
+
+](https://blog.csdn.net/m0_74337295/article/details/134035058)
+
+12-19
+
+[
+
+_Nginx_配置 3.1 _nginx_的基本功能 3.2 _nginx_的扩展功能 4. _nginx_的模块与工作原理 4.1 _nginx_的模块分类 4.2_nginx_工作原理 4.3echo模块用法 5.1_nginx_的安装 5.2_nginx_安装后配置 6.1 _nginx_.conf配置详解 6.2 用于调试、定位问题的配置参数 6.3 正常运行必备的配置参数 ...
+
+](https://blog.csdn.net/m0_74337295/article/details/134035058)
+
+[
+
+_Nginx_手册_输入一个路径,实现将该路径下所有的文件归类。相同类型的文...
+
+](https://blog.csdn.net/weixin_38374686/article/details/127720596)
+
+12-17
+
+[
+
+–prefix=/usr/local/_nginx_ –user=_nginx_ –group=_nginx_ –_with_out_-_http_uwsgi_module –_with_out_-_http_scgi_module –_with_out_-_http_browser_module –_with__-_pcre –_with__-_http_addition_module –_with__-_http_ssl_module –_with__-_http_realip_module –_with__-_http_sub_module ...
+
+](https://blog.csdn.net/weixin_38374686/article/details/127720596)
+
+[
+
+_Nginx__国密__改造_
+
+](https://blog.csdn.net/qq_49081692/article/details/130964954)
+
+[qq_49081692的博客](https://blog.csdn.net/qq_49081692)
+
+ ![](https://csdnimg.cn/release/blogv2/dist/pc/img/readCountWhite.png) 4771
+
+[
+
+_国密_web服务器，_国密__nginx_，_nginx__国密_，_国密__改造_
+
+](https://blog.csdn.net/qq_49081692/article/details/130964954)
+
+[
+
+搭建支持_国密_GmSSL的_Nginx_环境
+
+](https://blog.csdn.net/Bejpse/article/details/145804164)
+
+[](https://blog.csdn.net/Bejpse)
+
+ ![](https://csdnimg.cn/release/blogv2/dist/pc/img/readCountWhite.png) 1672
+
+[
+
+2、安装包准备：需要GmSSL、_国密__Nginx_，可通过互联网下载或者从 https_:_//download.csdn.net/download/m0_46665077/89936158 下载_国密_GmSSL安装包和_国密__Nginx_安装包。1.配置 _nginx_ 开机自启，创建 /etc/systemd/system/_nginx_.service 的服务文件。_国_际RSA证书存放：/usr/local/gmssl/ssl/rsa/_国密_证书存放：/usr/local/gmssl/ssl/gm/
+
+](https://blog.csdn.net/Bejpse/article/details/145804164)
+
+[
+
+RSA盲签名技术解析及代码实现_实践__rsa rfc
+
+](https://blog.csdn.net/openHiTLS/article/details/153263461)
+
+11-28
+
+[
+
+5.2 技术_实践__:__openHiTLS_的标准化实现 值得关注的是,_openHiTLS_已基于RFC9474标准完成了RSA盲签名技术的工程化实现,为开发者与企业提供了标准化、高可用的技术工具包。该实现严格遵循“盲化_-_签名_-_去盲”的核心流程,通过关键函数封装算法逻辑,以下结合核心代码片段说明其实现思路_:_ ...
+
+](https://blog.csdn.net/openHiTLS/article/details/153263461)
+
+[
+
+_nginx__-_tmp.tar.gz
+
+](https://download.csdn.net/download/w277608109/19855832)
+
+06-27
+
+[
+
+标签中的“_国密_服务器”表明这个_Nginx_配置是为满足中_国_对加_密_技术的要求而优化的，能够处理基于SM2、SM3和SM4的加_密_通信。 “gmssl静态库_国密_版”进一步确认了库文件是GMSSL的静态版本，集成了中_国_的加_密_算法。 ...
+
+](https://download.csdn.net/download/w277608109/19855832)
+
+[
+
+信创_-__nginx__-__国密_ssl_改造_
+
+](https://blog.csdn.net/twobun/article/details/136169543)
+
+[twobun的博客](https://blog.csdn.net/twobun)
+
+ ![](https://csdnimg.cn/release/blogv2/dist/pc/img/readCountWhite.png) 2348
+
+[
+
+信创 _nginx_ _国密__改造_
+
+](https://blog.csdn.net/twobun/article/details/136169543)
+
+[
+
+_国密_GmSSL安装包+_国密__Nginx_安装包+搭建_国密_应用服务器
+
+](https://download.csdn.net/download/m0_46665077/89936158)
+
+10-30
+
+[
+
+_国密_GmSSL和_国密__Nginx_是专门为中_国_商用_密码算法_设计的安全工具包，它们在确保网络安全、数据传输加_密_以及防止信息泄露方面发挥着重要作用。GmSSL是基于OpenSSL_改造_的，它支持_国_产_密码算法_，如SM2、SM3、SM4等，可...
+
+](https://download.csdn.net/download/m0_46665077/89936158)
+
+[
+
+换_Nginx__-__with__-_Gmsslv3 怎么编译到_nginx_里面
+
+](https://wenku.csdn.net/answer/5xd6vcxqnr)
+
+09-13
+
+[
+
+现在用户明确询问如何将_Nginx__-__with__-_Gmsslv3（即支持_国密_SSL协议版本3的_Nginx_）编译到_Nginx_中。注意，用户提到的“_Nginx__-__with__-_Gmsslv3”可能是一个特定的支持_国密_的_Nginx_分支或补丁。 根据之前的知识，我们知道...
+
+](https://wenku.csdn.net/answer/5xd6vcxqnr)
+
+[
+
+编译 _Nginx__-__with__-_GmSSLv3 时可能会遇到哪些常见错误及解决办法？
+
+](https://wenku.csdn.net/answer/12findmsna)
+
+09-13
+
+[
+
+如何验证_Nginx__-__with__-_GmSSLv3是否成功支持_国密_算法？ 2. 在_Nginx__-__with__-_GmSSLv3中如何配置_国密_双证书？ 3. 运行_Nginx__-__with__-_GmSSLv3时可能遇到哪些问题？ 4. 如何调试_Nginx__-__with__-_GmSSLv3的TLS握手过程？ ### 编译 ...
+
+](https://wenku.csdn.net/answer/12findmsna)
+
+[
+
+编译_nginx_支持_国密_SSL协议
+
+](https://devpress.csdn.net/v1/article/detail/108080409)
+
+[gmssl的博客](https://blog.csdn.net/gmssl)
+
+ ![](https://csdnimg.cn/release/blogv2/dist/pc/img/readCountWhite.png) 6619
+
+[
+
+1 背景 _Nginx_自身支持标准的SSL协议，但并不支持_国密_SSL协议。本文描述了_Nginx_配置的_国密_SSL协议（单向）的完整过程，仅供学习和参考之用。 _Nginx_无需修改源码、支持任意版本_Nginx_。 2 环境 服务器OS是CentOS7.7的64位版本，IP位192.168.0.98，客户端OS是WindowsXP。 _Nginx_是_Nginx__-_1.18.0。 浏览器是360安全浏览器（支持_国密_）。 3 安装方法一：源码编译 GMSSL.cn提供一个OpenSSL的_国密_版库，可与_nginx_编译，生成的ngi
+
+](https://devpress.csdn.net/v1/article/detail/108080409)
+
+[
+
+_Nginx__国密_化
+
+](https://blog.csdn.net/xuxunaa/article/details/126589156)
+
+[前端摸鱼第一名](https://blog.csdn.net/xuxunaa)
+
+ ![](https://csdnimg.cn/release/blogv2/dist/pc/img/readCountWhite.png) 2984
+
+[
+
+【代码】_Nginx__国密_化保姆教程
+
+](https://blog.csdn.net/xuxunaa/article/details/126589156)
+
+[
+
+ubuntu18.04搭建基于_国密_算法的_nginx_环境
+
+](https://devpress.csdn.net/v1/article/detail/122635880)
+
+[a1309525802的博客](https://blog.csdn.net/a1309525802)
+
+ ![](https://csdnimg.cn/release/blogv2/dist/pc/img/readCountWhite.png) 4741
+
+[
+
+ubuntu18.04搭建基于_国密_算法的_nginx_环境 ubuntu18.04安装 https_:_//mirrors.tuna.tsinghua.edu.cn/ubuntu_-_releases/18.04/ 可以选择安装桌面版的或者服务器版的,看个人需求 安装基本依赖 #进入root用户 sudo _-_i #更新源 apt update apt upgrade #安装gcc apt install gcc #安装make apt install make #安装git apt install git #安装li
+
+](https://devpress.csdn.net/v1/article/detail/122635880)
+
+[
+
+麒麟V10安装支持_国密_GmSSL的_Nginx_
+
+](https://blog.csdn.net/qq_37437139/article/details/145136608)
+
+[qq_37437139的博客](https://blog.csdn.net/qq_37437139)
+
+ ![](https://csdnimg.cn/release/blogv2/dist/pc/img/readCountWhite.png) 1867
+
+[
+
+按照官网的操作配置完了不好使，还没解决
+
+](https://blog.csdn.net/qq_37437139/article/details/145136608)
+
+[
+
+构建网络信息安全的中_国_方案 _-_ _国密_SSL/_TLCP_协议介绍以及_国密__Nginx_服务器部署
+
+热门推荐
+
+](https://devpress.csdn.net/v1/article/detail/134562784)
+
+[new9232的博客](https://blog.csdn.net/new9232)
+
+ ![](https://csdnimg.cn/release/blogv2/dist/pc/img/readCountWhite.png) 1万+
+
+[
+
+_国密_SSL协议指的是采用_国密_算法，符合_国密_标准的安全传输协议。简而言之，_国密_SSL就是SSL/TLS协议的_国密_版本。
+
+](https://devpress.csdn.net/v1/article/detail/134562784)
+
+- [关于我们](https://www.csdn.net/company/index.html#about)
+- [招贤纳士](https://www.csdn.net/company/index.html#recruit)
+- [商务合作](https://fsc-p05.txscrm.com/T8PN8SFII7W)
+- [寻求报道](https://marketing.csdn.net/questions/Q2202181748074189855)
+- ![](https://g.csdnimg.cn/common/csdn-footer/images/tel.png)400-660-0108
+- ![](https://g.csdnimg.cn/common/csdn-footer/images/email.png)[kefu@csdn.net](mailto:webmaster@csdn.net)
+- ![](https://g.csdnimg.cn/common/csdn-footer/images/cs.png)[在线客服](https://csdn.s2.udesk.cn/im_client/?web_plugin_id=29181)
+- 工作时间 8:30-22:00
+
+- [公安备案号11010502030143](http://www.beian.gov.cn/portal/registerSystemInfo?recordcode=11010502030143)
+- [京ICP备19004658号](http://beian.miit.gov.cn/publish/query/indexFirst.action)
+- [京网文〔2020〕1039-165号](https://csdnimg.cn/release/live_fe/culture_license.png)
+- [经营性网站备案信息](https://csdnimg.cn/cdn/content-toolbar/csdn-ICP.png)
+- [北京互联网违法和不良信息举报中心](http://www.bjjubao.org/)
+- [家长监护](https://download.csdn.net/tutelage/home)
+- [网络110报警服务](https://cyberpolice.mps.gov.cn/)
+- [中国互联网举报中心](http://www.12377.cn/)
+- [Chrome商店下载](https://chrome.google.com/webstore/detail/csdn%E5%BC%80%E5%8F%91%E8%80%85%E5%8A%A9%E6%89%8B/kfkdboecolemdjodhmhmcibjocfopejo?hl=zh-CN)
+- [账号管理规范](https://blog.csdn.net/blogdevteam/article/details/126135357)
+- [版权与免责声明](https://www.csdn.net/company/index.html#statement)
+- [版权申诉](https://blog.csdn.net/blogdevteam/article/details/90369522)
+- [出版物许可证](https://img-home.csdnimg.cn/images/20250103023206.png)
+- [营业执照](https://img-home.csdnimg.cn/images/20250103023201.png)
+- ©1999-2025北京创新乐知网络技术有限公司
+
+[![](https://i-avatar.csdnimg.cn/355cd0deee474cf1ba93a435aae2c294_openHiTLS.jpg!1)](https://openhitls.blog.csdn.net/)
+
+[openHiTLS密码开源社区](https://openhitls.blog.csdn.net/ "openHiTLS密码开源社区")
+
+博客等级 ![](https://csdnimg.cn/identity/blog6.png)
+
+码龄1年
+
+[
+
+189
+
+原创
+
+](https://openhitls.blog.csdn.net/)
+
+3991
+
+点赞
+
+3127
+
+收藏
+
+881
+
+粉丝
+
+关注
+
+[私信](https://im.csdn.net/chat/openHiTLS)
+
+### 更多优质【一键运行】博文
+
+- [1WPS表格在一列里批量导入图片](https://blog.csdn.net/qq_41674785/article/details/134180384)
+- [2NumPy常用30个经典案例](https://blog.csdn.net/m0_75067629/article/details/145543113)
+- [3基于STM32的智能指针仪表盘系统设计与实现](https://blog.csdn.net/weixin_29476595/article/details/153556122)
+- [4chrome浏览器禁用js中的debugger](https://blog.csdn.net/A20190518/article/details/111037945)
+- [5C语言 根据年份数与月份数计算某月天数](https://blog.csdn.net/XD_YinG_Ye/article/details/153514582)
+
+[查看更多![查看更多](https://csdnimg.cn/release/blogv2/dist/pc/img/runBlogWhite.png)](https://blog.csdn.net/rank/list/blog_project)
+
+### 热门文章
+
+- [一文搞懂一次性密码：OTP、HOTP、TOTP详解 ![](https://csdnimg.cn/release/blogv2/dist/pc/img/readCountWhite.png) 3159](https://openhitls.blog.csdn.net/article/details/151608861)
+- [SM4算法工作模式（ECB、CBC、CFB、OFB、CTR、GCM、CCM 、XTS）：原理、特点与应用 ![](https://csdnimg.cn/release/blogv2/dist/pc/img/readCountWhite.png) 2737](https://openhitls.blog.csdn.net/article/details/151288800)
+- [无密码认证FIDO2 框架：重构数字世界的信任基石（附代码示例） ![](https://csdnimg.cn/release/blogv2/dist/pc/img/readCountWhite.png) 2712](https://openhitls.blog.csdn.net/article/details/150954617)
+- [唯密文攻击（Ciphertext Only）深度技术解析及未来趋势 ![](https://csdnimg.cn/release/blogv2/dist/pc/img/readCountWhite.png) 2684](https://openhitls.blog.csdn.net/article/details/153332376)
+- [ChaCha20 密码算法：从原理到代码实现的全方位解析【附源码】 ![](https://csdnimg.cn/release/blogv2/dist/pc/img/readCountWhite.png) 2541](https://openhitls.blog.csdn.net/article/details/151066232)
+
+### 分类专栏
+
+- [
+    
+    ![](https://i-blog.csdnimg.cn/columns/default/20201014180756928.png?x-oss-process=image/resize,m_fixed,h_64,w_64)开源社区动态](https://blog.csdn.net/openhitls/category_12997573.html)25篇
+- [
+    
+    ![](https://i-blog.csdnimg.cn/columns/default/20201014180756913.png?x-oss-process=image/resize,m_fixed,h_64,w_64)前沿技术动态](https://blog.csdn.net/openhitls/category_12989402.html)56篇
+- [
+    
+    ![](https://i-blog.csdnimg.cn/columns/default/20201014180756913.png?x-oss-process=image/resize,m_fixed,h_64,w_64)密码学实战](https://blog.csdn.net/openhitls/category_13027034.html)65篇
+- [
+    
+    ![](https://i-blog.csdnimg.cn/columns/default/20201014180756757.png?x-oss-process=image/resize,m_fixed,h_64,w_64)密码学基础](https://blog.csdn.net/openhitls/category_13034220.html)59篇
+- [
+    
+    ![](https://i-blog.csdnimg.cn/columns/default/20201014180756930.png?x-oss-process=image/resize,m_fixed,h_64,w_64)密码行业标准](https://blog.csdn.net/openhitls/category_13026355.html)12篇
+
+上一篇：
+
+[SLH-DSA：抗量子时代的 X.509 PKI 数字签名方案](https://blog.csdn.net/openHiTLS/article/details/150487435)
+
+下一篇：
+
+[后量子迁移：Composite ML-DSA复合签名方案解析](https://blog.csdn.net/openHiTLS/article/details/150511107)
+
+### 大家在看
+
+- [Git提交无数量限制](https://blog.csdn.net/zhangchen124/article/details/156199759)
+- [华为云CSBS代理核心作用解析 ![](https://csdnimg.cn/release/blogv2/dist/pc/img/readCountWhite.png) 518](https://blog.csdn.net/yunlaoda7/article/details/156153098)
+- [AI大模型工程师学习指南](https://blog.csdn.net/YoungOne2333/article/details/156199286)
+- [爬虫入门：从零解析代码 ![](https://csdnimg.cn/release/blogv2/dist/pc/img/readCountWhite.png) 546](https://blog.csdn.net/2401_88591507/article/details/156050630)
+- [CSS核心概念详解](https://blog.csdn.net/2511_94359082/article/details/156195300)
+
+### 最新文章
+
+- [成长故事 | 华中科技大学金轩宇：从CTF走进开源世界，我的开源探索之旅](https://openhitls.blog.csdn.net/article/details/156070157)
+- [成长故事 | 西安电子科技大学杨文杰：从密码套件的调用者成长为开源社区的贡献者](https://openhitls.blog.csdn.net/article/details/155803890)
+- [任正非最新讲话！1.4万字全文，信息量很大（任正非与ICPC主席、教练及获奖选手座谈会纪要）](https://openhitls.blog.csdn.net/article/details/155735120)
+
+2025
+
+[12月6篇](https://openhitls.blog.csdn.net/?type=blog&year=2025&month=12)
+
+[11月7篇](https://openhitls.blog.csdn.net/?type=blog&year=2025&month=11)
+
+[10月50篇](https://openhitls.blog.csdn.net/?type=blog&year=2025&month=10)
+
+[09月55篇](https://openhitls.blog.csdn.net/?type=blog&year=2025&month=09)
+
+[08月62篇](https://openhitls.blog.csdn.net/?type=blog&year=2025&month=08)
+
+[07月6篇](https://openhitls.blog.csdn.net/?type=blog&year=2025&month=07)
+
+[06月4篇](https://openhitls.blog.csdn.net/?type=blog&year=2025&month=06)
+
+### 目录
+
+1. [国密改造的核心诉求：](https://blog.csdn.net/openHiTLS/article/details/150497042#t0)
+2. [nginx-with-openHiTLS：技术特性解析](https://blog.csdn.net/openHiTLS/article/details/150497042#t1)
+3. [部署指南：从编译到运行的全流程](https://blog.csdn.net/openHiTLS/article/details/150497042#t2)
+4. 1. [1. 环境准备](https://blog.csdn.net/openHiTLS/article/details/150497042#t3)
+    2. [2. 编译 openHiTLS 密码库](https://blog.csdn.net/openHiTLS/article/details/150497042#t4)
+    3. [3. 编译并安装 nginx-with-openHiTLS](https://blog.csdn.net/openHiTLS/article/details/150497042#t5)
+    4. [4. 国密协议配置示例](https://blog.csdn.net/openHiTLS/article/details/150497042#t6)
+    5. [5. 启动与验证](https://blog.csdn.net/openHiTLS/article/details/150497042#t7)
+5. [关键注意事项与故障排除](https://blog.csdn.net/openHiTLS/article/details/150497042#t8)
+6. [开源实践：nginx-with-openHiTLS开源代码实现](https://blog.csdn.net/openHiTLS/article/details/150497042#t9)
+
+收起 ![](https://csdnimg.cn/release/blogv2/dist/pc/img/arrowup-line-top-White.png)
+
+[![](https://i-operation.csdnimg.cn/images/df6c67fa661c48eba86beaeb64350df0.gif)](https://mall.csdn.net/vip?utm_source=25618_vip_blogrighticon)[![](https://csdnimg.cn/release/blogv2/dist/pc/img/toolbar/Group.png)](https://ai.csdn.net/chat?utm_source=cknow_pc_blogdetail&spm=1001.2101.3001.10583)![](https://g.csdnimg.cn/side-toolbar/3.6/images/mobile.png)![](https://g.csdnimg.cn/side-toolbar/3.6/images/customer.png)![](https://g.csdnimg.cn/side-toolbar/3.6/images/totop.png)
@@ -0,0 +1,36 @@
+tls_ctx_init(&ctx, TLS_protocol_tlcp, TLS_server_mode)
+tls_ctx_set_cipher_suites(&ctx, server_ciphers, sizeof(server_ciphers)/sizeof(int))
+tls_ctx_set_tlcp_server_certificate_and_keys(&ctx, certfile, signkeyfile, signpass, enckeyfile, encpass)
+	tls_ctx_set_ca_certificates(&ctx, cacertfile, TLS_DEFAULT_VERIFY_DEPTH)
+
+bind
+accept
+
+tls_init(&conn, &ctx)
+tls_set_socket(&conn, conn_sock)
+tls_do_handshake(&conn)
+tls_recv
+tls_send
+tls_socket_close
+
+
+
+
+tls_ctx_init
+tls_ctx_set_cipher_suites
+
+
+
+
+
+
+
+
+
+
+{ERR_REASON(SSL_R_DECRYPTION_FAILED), "decryption failed"},  
+{ERR_REASON(SSL_R_DECRYPTION_FAILED_OR_BAD_RECORD_MAC),  
+ "decryption failed or bad record mac"},
+
+
+SSL_read /  / ssl3_get_record
@@ -0,0 +1 @@
+![[4c7c04b4a5b75a31c9e5a5054560bef2.png]]
@@ -0,0 +1,180 @@
+个人博客：www.fuzoupyy.work
+
+前两天有个刚做网络的小兄弟问我：“现在不都流行SSL VPN或者[WireGuard](https://zhida.zhihu.com/search?content_id=266937248&content_type=Article&match_order=1&q=WireGuard&zhida_source=entity)了吗？[IPsec](https://zhida.zhihu.com/search?content_id=266937248&content_type=Article&match_order=1&q=IPsec&zhida_source=entity)这种‘老古董’是不是没必要学了？”
+
+我当时差点一口老血喷屏幕上。
+
+兄弟，你这就好比在说，现在开自动挡的车多了，手动挡的原理就不重要了？IPsec这玩意儿，就像是网络世界的“重型装甲车”，它是笨重，配置是繁琐，但在Site-to-Site（站点对站点）的连接上，它依然是无可撼动的霸主。你看看现在的公有云，AWS也好，阿里云也罢，跟IDC做专线互联备份的时候，哪个推荐的不是IPsec？
+
+别看WireGuard现在火得一塌糊涂，真到了复杂的企业级环境，还得是IPsec坐镇。
+
+今天咱们就来扒一扒IPsec的底裤，顺便教大家用开源神器[StrongSwan](https://zhida.zhihu.com/search?content_id=266937248&content_type=Article&match_order=1&q=StrongSwan&zhida_source=entity)搭建一套企业级的VPN。
+
+### **为什么IPsec让人头大？**
+
+咱们先不谈配置，先聊聊为什么这玩意儿难懂。
+
+绝大多数人晕菜，是因为被IKE、[ISAKMP](https://zhida.zhihu.com/search?content_id=266937248&content_type=Article&match_order=1&q=ISAKMP&zhida_source=entity)、[ESP](https://zhida.zhihu.com/search?content_id=266937248&content_type=Article&match_order=1&q=ESP&zhida_source=entity)、[AH](https://zhida.zhihu.com/search?content_id=266937248&content_type=Article&match_order=1&q=AH&zhida_source=entity)、Phase 1、Phase 2这些缩写给绕晕了。
+
+其实，你把IPsec想象成**“押镖”**。
+
+你要把一车黄金（数据包）从北京运到上海。路上有土匪（黑客），你不能直接运。
+
+**第一种方式：AH（Authentication Header）** 这就像是在车厢上贴了个封条，上面盖了皇帝的印（签名）。到了上海，一看封条没坏，就知道东西没被换过，也是朝廷发出来的。 **但是！** 封条只能保证东西没被换，**它不加密**。黄金还是黄金，土匪在路边能看个精光。而且，最坑爹的是，AH会对整个IP头做签名。大家都知道现在网络到处都是NAT（地址转换），路由器一改IP地址，签名就这就对不上了，封条就“碎”了。所以，**在现在的网络环境里，AH基本就是个废柴，很少用。**
+
+**第二种方式：ESP（Encapsulating Security Payload）** 这个厉害了。它不仅贴封条，还把黄金装进了保险箱（加密）。土匪截了车，只能看到一个铁箱子，里面是啥完全不知道。 ESP最骚的操作是“隧道模式”。它不光把数据加密，它还把原来的车牌（原IP头）也给拆下来扔进保险箱，然后在外面挂个新车牌（新IP头）。这就是为什么我们在隧道里抓包，只能看到两个网关之间的公网IP在通信，完全看不到内网IP。
+
+### **那个让人抓狂的协商过程：IKE**
+
+真正让人掉头发的，是IKE（Internet Key Exchange）。
+
+你想啊，两个网关（路由器或服务器）素不相识，怎么建立信任？怎么商量用什么密码？直接在公网上喊：“喂！密码是123456！”那不找死吗？
+
+所以得谈判。这个谈判过程就是IKE。
+
+**第一阶段（Phase 1）：建立管理连接** 这就像两个外交官见面，先得在一个绝对安全的屋子里坐下来。 他们要确认对方身份（Pre-Shared Key预共享密钥，或者证书），然后商量：“咱俩待会怎么聊天？用什么加密算法？” 这一步要是通了，就建立了一个叫**ISAKMP SA**的东西。你可以理解为，外交官的保密电话接通了。
+
+这里有个大坑。Phase 1有两种模式：**主模式（Main Mode）**和**野蛮模式（Aggressive Mode）**。 名字听着挺唬人。主模式慢，一来一回6个包，但是安全，它会隐藏身份信息。野蛮模式快，3个包搞定，但是它会把身份ID明文广播出去。 以前为了快，很多老设备喜欢用野蛮模式，现在为了安全，大家基本都切回主模式了。
+
+**第二阶段（Phase 2）：建立数据连接** 外交官电话通了（Phase 1成功），现在开始聊正事：怎么运黄金。 这时候商量的才是真正用来加密用户数据的密钥（IPsec SA）。 这就是所谓的“快速模式”（Quick Mode）。
+
+这也是为什么你看日志的时候，经常看到Phase 1过了，Phase 2报错。通常是因为两边的“感兴趣流”（Subnet，也就是你要通的内网网段）没对上。左边说我要通192.168.1.0/24，右边配置写的是192.168.2.0/24，聊不到一块去，崩了。
+
+### **[NAT-T](https://zhida.zhihu.com/search?content_id=266937248&content_type=Article&match_order=1&q=NAT-T&zhida_source=entity)：穿越NAT的救命稻草**
+
+刚才说了，AH过不了NAT。其实ESP过NAT也费劲。 因为NAT路由器会修改端口号，而IPsec设计之初是基于IP层的，没端口号这概念（ESP协议号是50）。
+
+为了解决这个问题，聪明的工程师搞了个**NAT-T（NAT Traversal）**。 简单说，就是把ESP数据包再包一层UDP头部，通常是用UDP 4500端口。这样NAT路由器一看：“哦，是UDP啊，改端口我会！” 于是，IPsec就能在NAT环境里活下来了。
+
+**敲黑板：** 如果你的VPN服务器在防火墙后面，记得防火墙除了开**UDP 500**（IKE协商用），还得开**UDP 4500**（NAT穿透用）。好多人配半天不通，就是因为4500端口没开。
+
+  
+
+---
+
+  
+
+### **实战：用StrongSwan搭建从阿里云到本地IDC的隧道**
+
+理论扯多了容易困，咱们来点实操。 Linux下做IPsec，以前有Openswan、Libreswan，但现在**StrongSwan**是绝对的一哥。它对IKEv2的支持最好，配置也相对“阳间”一点（虽然也没好到哪去）。
+
+假设场景：
+
+- **阿里云（左边 Left）：**  
+    
+
+- 公网IP：1.1.1.1
+- 内网段：172.16.0.0/16
+
+  
+
+- **本地IDC（右边 Right）：**  
+    
+
+- 公网IP：2.2.2.2
+- 内网段：192.168.10.0/24
+
+  
+
+系统咱们就用[CentOS 7](https://zhida.zhihu.com/search?content_id=266937248&content_type=Article&match_order=1&q=CentOS+7&zhida_source=entity)或者[Ubuntu 20.04](https://zhida.zhihu.com/search?content_id=266937248&content_type=Article&match_order=1&q=Ubuntu+20.04&zhida_source=entity)，都差不多。
+
+**1. 安装StrongSwan** 这就不用我教了吧？ `yum install strongswan` 或者 `apt install strongswan`。
+
+**2. 开启内核转发（这点最容易忘！）** 很多人配好了VPN，发现ping不通内网，查了一圈发现是Linux没开启路由转发。 编辑 `/etc/sysctl.conf`：
+
+```bash
+net.ipv4.ip_forward = 1
+# 如果有IPv6也顺手开了
+net.ipv6.conf.all.forwarding = 1
+```
+
+执行 `sysctl -p` 生效。
+
+**3. 配置 ipsec.conf** 这是核心配置文件。虽然StrongSwan出了新的 `swanctl.conf` 格式，但为了照顾老玩家的习惯，咱们还是用经典的 `ipsec.conf`。
+
+阿里云那台机器（1.1.1.1）的配置 `/etc/strongswan/ipsec.conf`：
+
+```bash
+config setup
+    # 开启调试日志，排错的时候很有用，平时可以关了
+    charondebug="ike 2, knl 2, cfg 2"
+    uniqueids=no
+
+conn ali-to-idc
+    authby=secret       # 使用预共享密钥认证
+    auto=start          # 服务启动时自动连接
+    type=tunnel         # 隧道模式
+    keyexchange=ikev2   # 强烈建议用IKEv2，比v1快且稳
+    
+    # 左边（本机/阿里云）配置
+    left=1.1.1.1        # 本机公网IP
+    leftid=1.1.1.1      # 标识ID，通常和IP一样
+    leftsubnet=172.16.0.0/16  # 本机要暴露给对端的内网段
+    
+    # 右边（远端/IDC）配置
+    right=2.2.2.2
+    rightid=2.2.2.2
+    rightsubnet=192.168.10.0/24
+    
+    # 加密算法（这个得两边商量好，必须一模一样！）
+    ike=aes256-sha256-modp1024!
+    esp=aes256-sha256!
+    
+    # 存活检测
+    dpddelay=30s
+    dpdtimeout=120s
+    dpdaction=restart
+```
+
+**本地IDC那台机器的配置，基本就是反过来。** 把 `left` 换成 2.2.2.2，`right` 换成 1.1.1.1，subnet也对调一下。
+
+这里有个细节：**`left` 不一定非得写公网IP。** 如果你的服务器是在NAT后面（比如AWS EC2，或者家里路由器后面的虚拟机），`left` 其实应该写内网IP，然后 `leftid` 写公网IP。这块逻辑如果没理顺，StrongSwan根本起不来。
+
+**4. 配置密码 ipsec.secrets** 这个文件简单，就是存密码的。两边得一样。
+
+```bash
+# 格式：IP1 IP2 : PSK "你的超强密码"
+1.1.1.1 2.2.2.2 : PSK "YoyouIsHandsome2025"
+```
+
+记得这个文件权限要设成600，不然StrongSwan会报错说不安全。
+
+**5. 启动与排错** 启动：`systemctl start strongswan` 查看状态：`strongswan statusall`
+
+如果一切顺利，你会看到类似 `Security Associations (1 up, 0 connecting)` 的字样，那就是通了！
+
+### **要是通不了怎么办？（运维的日常崩溃）**
+
+这时候就显出真本事了。 要是状态里显示 `CONNECTING` 然后一直卡着，或者直接 `0 up`，千万别慌。
+
+**第一招：看日志。** `tail -f /var/log/syslog` 或者 `/var/log/messages`。 如果你看到 `NO_PROPOSAL_CHOSEN`，这绝对是两边加密算法没对齐。比如一边配了AES128，另一边是AES256；或者一边是SHA1，另一边是SHA256。仔细检查 `ike=` 和 `esp=` 这两行。
+
+**第二招：检查防火墙。** 再强调一遍，UDP 500 和 UDP 4500。 还有，云厂商的安全组！阿里云的安全组入方向开了吗？
+
+**第三招：MSS（最大报文段长度）问题。** 这是个隐形杀手。 VPN加上了ESP头，包变大了。如果原来是1500字节，加上头就超了，会被分片或者丢弃。 现象就是：**ping是通的，但SSH连不上，或者网页打不开。** 这时候需要在防火墙（iptables）里做个手脚，把MSS改小点：
+
+```bash
+iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu
+```
+
+或者暴力点，直接设成1300：
+
+```bash
+iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --set-mss 1300
+```
+
+这招下去，90%的“怪病”都能好。
+
+### **总结**
+
+说实话，配置IPsec VPN是一件挺枯燥的事，配置文件里哪怕多了一个空格，或者少了一个感叹号，都能让你查半天。
+
+但这就是运维的价值所在啊。 当那条隧道打通，两边内网的数据像流水一样无缝传输的时候，那种成就感，真的是WireGuard这种“傻瓜式”工具给不了的（虽然我也很爱WireGuard，哈哈）。
+
+而且，搞懂了IPsec，你再去看SD-WAN，看云专线，其实底层逻辑都是通的。
+
+我知道这篇内容有点硬，可能大家得消化一会儿。建议收藏起来，下次被VPN折磨的时候，拿出来对一对配置，说不定就救了你的命。
+
+技术这东西，没有什么捷径，就是一遍遍试错试出来的。
+
+如果你在配置过程中遇到了奇葩的报错，或者对加密算法的选择有疑问，欢迎在评论区留言，咱一起探讨探讨。
@@ -0,0 +1,12 @@
+![[Pasted image 20251204155744.png]]
+
+
+![[73ed7d2b9783ef80009955aaae11eea7.png]]
+
+
+![[64c875d94cda00b1e27f782f87c80945.png]]
+
+
+
+
+
@@ -0,0 +1,369 @@
+---
+published:
+created: 2025-10-18
+tags:
+  - clippings
+---
+
+## 背景
+
+[OpenSSL](https://zhida.zhihu.com/search?content_id=751981217&content_type=Answer&match_order=1&q=OpenSSL&zhida_source=entity) 有2大核心：一个是实现 TLS 协议，一个是加密解密库。
+
+接下来，不得不开始讲解极为复杂的加密解密了。
+
+这里有许多数学知识，本人也不懂，只是作为调包侠，知道输入输出而已。
+
+今天，先讲一个大体框架。
+
+---
+
+## 引子
+
+现在主流浏览器和大多数 Web 服务器，都采用 [TLS1.3](https://zhida.zhihu.com/search?content_id=751981217&content_type=Answer&match_order=1&q=TLS1.3&zhida_source=entity) 。
+
+以下是一个典型的通讯过程（TLS1.3）：
+
+![](https://pic3.zhimg.com/v2-837ffc4578f86fee62efb0065d420fa8_1440w.jpg)
+
+第1个包：客户向服务器发送 [Client Hello](https://zhida.zhihu.com/search?content_id=751981217&content_type=Answer&match_order=1&q=Client+Hello&zhida_source=entity)。向服务器打招呼，我要和你建立 TLS 连接。
+
+第2个包：服务器回应 [Server Hello](https://zhida.zhihu.com/search?content_id=751981217&content_type=Answer&match_order=1&q=Server+Hello&zhida_source=entity)。服务器回应：好吧，现在开始建立TLS 连接。
+
+第2个包，一共有6个记录层 [Record Layer](https://zhida.zhihu.com/search?content_id=751981217&content_type=Answer&match_order=1&q=Record+Layer&zhida_source=entity)。
+
+前2个记录层，明文传输：分别是握手协议；Change Cipher（开始加密的信号）
+
+后4个记录层，都是加密的，需要客户端解密。
+
+以下是客户端和服务器在前2个包中沟通的内容。
+
+```
+packet 1: length is 1759
+IP header length is 20
+TCP header length is 20
+Source Port: 11128
+Dest Port: 443
+
+TLS: client to server
+TLS part: len is 1719
+record layer: handshake
+handleshake layer: ClientHello
+Random:     3df8b4e7ae0d778d09a45721d5dfbc064e6dc6b368a1e7c1767ae849eb996824
+Session ID: 56c1d0ef0363be4943c0fa9014229a150d18a8ee7e00e271cb18a37ec449cb99
+total 16 cipher suites
+Extensions length: 1605
+extension_type=UNKNOWN(27242), length=0
+extension_type=server_name(0), length=14
+server_name = localhost
+extension_type=supported_versions(43), length=7
+extension_type=session_ticket(35), length=0
+extension_type=UNKNOWN(65037), length=186
+extension_type=key_share(51), length=1263
+group: UNKNOWN(27242), len = 1
+group: X25519MLKEM768(4588), len = 1216
+group: ecdh_x25519(29), len = 32
+
+extension_type=signed_certificate_timestamps(18), length=0
+extension_type=supported_groups(10), length=12
+extension_type=application_layer_protocol_negotiation(16), length=14
+extension_type=UNKNOWN(17613), length=5
+extension_type=extended_master_secret(23), length=0
+extension_type=psk_key_exchange_modes(45), length=2
+extension_type=status_request(5), length=5
+extension_type=signature_algorithms(13), length=18
+extension_type=ec_point_formats(11), length=2
+extension_type=compress_certificate(27), length=3
+extension_type=renegotiate(65281), length=1
+extension_type=UNKNOWN(39578), length=1
+
+========================
+packet 2: length is 1474
+IP header length is 20
+TCP header length is 20
+Source Port: 443
+Dest Port: 11128
+
+TLS: server to client
+TLS part: len is 1434
+record layer: handshake
+handleshake layer: ServerHello
+Random:     a80ae047daa2f5d800b479277f5543408c7127061af40f7cbe8296218632aa81
+Session ID: 56c1d0ef0363be4943c0fa9014229a150d18a8ee7e00e271cb18a37ec449cb99
+Cipher Suite: TLS_AES_256_GCM_SHA384(0x1302)
+Extensions length: 46
+extension_type=supported_versions(43), length=2
+extension_type=key_share(51), length=36
+group: ecdh_x25519(29), len = 32
+
+record layer: change cipher spec
+record layer: app data
+record layer: app data
+record layer: app data
+record layer: app data
+```
+
+经过以上沟通，双方获取以下参数。
+
+### 已知参数
+
+加密套件：Cipher Suite：TLS\_AES\_256\_GCM\_SHA384
+
+[ECDHE](https://zhida.zhihu.com/search?content_id=751981217&content_type=Answer&match_order=1&q=ECDHE&zhida_source=entity) 方法：X25519
+
+| 名称 | 长度 | 来源 |
+| --- | --- | --- |
+| 客户端随机数 | 32字节 | TLS 通讯： client hello |
+| 服务器随机数 | 32字节 | TLS 通讯： server hello |
+| 客户端ECDHE公钥 | 32字节 | TLS 通讯： client hello, key share, x25519, key exchange |
+| 服务器ECDHE公钥 | 32字节 | TLS 通讯： Server hello, key share, x25519, key exchange |
+| TLS 版本 V1.3 | NA | TLS 通讯： server hello，supported version |
+| 加密算法 | NA | TLS 通讯： server hello， cipher suite: AES\_256\_GCM |
+| 散列算法 | NA | TLS 通讯： server hello， cipher suite: SHA384 |
+| ECDHE 密钥交换协议 | NA | TLS 通讯： server hello，key share, group: x25519 |
+
+### TLS\_AES\_256\_GCM\_SHA384
+
+TLS\_AES\_256\_GCM\_SHA384 ：就是服务器和客户端沟通后，决定采取的加密方法。
+
+简单解释一下。
+
+**`TLS_AES_256_GCM_SHA384` = 协议 + 密钥加密算法 + 消息认证算法**
+
+- **密码套件**： `TLS_AES_256_GCM_SHA384`
+- **加密算法**： `AES_256_GCM` (256位密钥的AES-GCM模式)
+- **哈希算法**： `SHA-384`
+
+### `AES_256_GCM`
+
+- **含义**：**用于批量数据加密的对称加密算法**。
+- **拆解**：
+- **`AES`**：**高级加密标准**。这是目前全球最流行、最安全的对称加密算法之一。它被美国政府选为保护机密信息的标准。
+	- **`256`**：**密钥长度**。表示使用 256 位（32字节）的密钥。在 AES 算法中，密钥越长，理论上越难被暴力破解
+	- **`GCM`**：**伽罗瓦/计数器模式**。这是一种加密模式，它同时提供了**保密性**（加密）和**完整性认证**（确保数据在传输过程中未被篡改）。
+
+**简单来说，`AES_256_GCM` 负责对实际传输的网页内容、数据等所有应用层信息进行快速、高强度的加密和解密。**
+
+  
+
+### SHA384
+
+- **含义**：**用于“握手阶段”认证的散列算法**。
+- **拆解**：
+- **`SHA`**：**安全散列算法**。这是一种密码学散列函数，能将任意长度的数据映射为固定长度的、唯一的“指纹”（散列值）。
+	- **`384`**：**输出长度**。表示产生 384 位的散列值。
+
+  
+
+**在 TLS 1.3 中，`SHA384` 的作用与 TLS 1.2 不同：**
+
+- **在 TLS 1.2 中**，SHA 系列算法可能用于计算消息认证码（如 HMAC-SHA256），以确保每条记录的完整性。
+- **在 TLS 1.3 中**，数据完整性主要由上面的 `GCM` 模式负责。`SHA384` 在这里主要用于 **握手过程的认证**。具体来说，它被用来生成“握手消息”的摘要，用于创建**伪随机函数** 和计算 **Finished** 消息的验证码，以确保整个 TLS 握手过程没有被篡改。
+
+  
+
+### ECDHE
+
+Group: x25519 (29)
+
+`x25519` 是一种**密钥交换算法**，更具体地说，它是**椭圆曲线迪菲-赫尔曼** 密钥交换协议的一种高效、安全的实现。
+
+密钥交换的目的是：**在不安全的网络（如互联网）上，让通信的双方（例如你的浏览器和网站服务器）协商出一个只有他们俩才知道的共享秘密。** 这个共享秘密后续会被用作对称加密（如上面提到的 AES\_256\_GCM）的密钥。
+
+`x25519` 就是用来安全地完成这个协商过程的现代方法。
+
+- **`X`**： 代表“Montgomery X”，指的是它在椭圆曲线上使用的特定坐标系统和计算公式（蒙哥马利曲线）。
+- **`25519`**： 指的是它所基于的椭圆曲线，即 **Curve25519**。这条曲线由密码学家 Daniel J. Bernstein 设计，其核心域是一个由素数 2255−192255−19 定义的有限域，故名 Curve25519。
+
+所以，`x25519` 就是 **在 Curve25519 椭圆曲线上执行迪菲-赫尔曼密钥交换的函数**。
+
+  
+
+ECDHE过程简述
+
+在 TLS 握手过程中：
+
+1. 客户端说：“我支持 `x25519`。”
+2. 服务器选择 `x25519`，并生成一个临时的密钥对（私钥 + 公钥），将其公钥发送给客户端。
+3. 客户端也生成一个临时的 `x25519` 密钥对，并计算与服务器公钥的共享秘密，然后将自己的公钥发送给服务器。
+4. 服务器用自己的私钥和客户端的公钥计算，得到**同一个共享秘密**。Pre-Master secret，预备主密钥
+5. 双方随后使用这个共享秘密派生出用于加密数据的会话密钥。
+
+---
+
+## TLS1.3密钥
+
+经过上面的步骤，可以计算出PMS（预备主密钥, Pre-Master Secret），然后用这个密钥加密，解密。
+
+打完收工，文章结束。
+
+想多了。
+
+TLS 要是这么简单，也不至于让我学习了好多天，才搞清楚大概。
+
+![](https://pica.zhimg.com/v2-390b61289c1c4a364ac3b39baaab69aa_1440w.jpg)
+
+TLS 的密钥种类，大约有十几种。
+
+上图是密钥是如何一步一步生成的，看的头大吧，头大是正常的。
+
+具体请看：RFC8446 TLS1.3 协议。
+
+[RFC 8446: The Transport Layer Security (TLS) Protocol Version 1.3www.rfc-editor.org/rfc/rfc8446](https://link.zhihu.com/?target=https%3A//www.rfc-editor.org/rfc/rfc8446)
+
+### 密钥
+
+什么是密钥？
+
+其实就是一长串数字，长度可能是32字节，48字节，或64字节。
+
+这个数字是随机产生的，用于加密和解密。
+
+### 密钥分类
+
+在 TLS 1.3 中，按用途划分，密钥主要分为以下四个层次，每一层都有其特定用途：
+
+1. **早期数据传输密钥**：用于 0-RTT 数据加密。只有启用 0-RTT 模式时才会生成。
+2. **握手数据传输密钥**：用于加密握手消息（如 Certificate, CertificateVerify, Finished）。保护握手过程本身不被窥探。
+3. **应用数据传输密钥**：用于加密和解密上层（如 HTTP）传输的应用数据。这是我们最常说的“通信密钥”。
+4. **更新主密钥**：用于在连接过程中主动更新后续的应用密钥，以提供更强的后向安全性。
+
+  
+
+| 类别 | 方向 | 密钥名称 | 数量 |
+| --- | --- | --- | --- |
+| 握手流量 | 客户端 → 服务器 | client\_handshake\_key, client\_handshake\_iv | 2 |
+|  | 服务器 → 客户端 | server\_handshake\_key, server\_handshake\_iv | 2 |
+| 应用流量 | 客户端 → 服务器 | client\_application\_key, client\_application\_iv | 2 |
+|  | 服务器 → 客户端 | server\_application\_key, server\_application\_iv | 2 |
+| 0-RTT流量 | 客户端 → 服务器 | client\_early\_traffic\_key, client\_early\_traffic\_iv | 2 |
+| Finished验证 | 双向 | client\_finished\_key, server\_finished\_key | 2 |
+| PSK | 双向 | resumption\_master\_secret   pre-shared key | 2 |
+| 总计 |  |  | 14 |
+
+客户和服务器通讯，读和写用不同的密钥，增加安全性。
+
+那么，刚才协商的 PMS，（预备主密钥, Pre-Master Secret），在哪里？
+
+这个表格指的是最终使用的密钥。
+
+为了产生这些密钥，需要产生一些中间密钥。
+
+```
+Early Secret = HKDF-Extract(salt, IKM) = HKDF-Extract(0, PSK) = HKDF-Extract(0, 0)
+Handshake Secret = HKDF-Extract(salt, IKM) = HKDF-Extract(Derive-Secret(Early Secret, "derived", ""), (EC)DHE)
+Master Secret = HKDF-Extract(salt, IKM) = HKDF-Extract(Derive-Secret(Handshake Secret, "derived", ""), 0)
+```
+
+**IKM** 是 **Input Keying Material（输入密钥材料）** 的缩写，这是密钥派生函数的原始输入材料。
+
+这里的IKM，就是指 PMS，预备主密钥, Pre-Master Secret。
+
+就是从 PMS 产生 Early 密钥，
+
+Early 密钥产生握手密钥（Handshake Secret）；
+
+再从握手密钥产生主密钥（Master Secret）。
+
+握手密钥产生握手期间的密钥对；
+
+主密钥产生数据传输期间的密钥对。
+
+HKDF-Extract 指的是什么？
+
+Salt：指的是什么？
+
+这里不做说明，请自行查看RFC。
+
+### 先做减法
+
+先去除一些不常用的密钥。
+
+resumption\_master\_secret：用来生成 PSK，可以不用
+
+client\_early\_traffic\_key， client\_early\_traffic\_iv：0-RTT，可以不用
+
+  
+
+### 必用密钥
+
+以下密钥是一定会用到的密钥。
+
+一切密钥的起点：ECDHE 私钥。
+
+ECDHE 私钥相当于种子，种子确定，后面的密钥都确定了。
+
+当然，后面这些密钥还需要一些材料：比如TLS 协议中的随机数，TLS 数据包本身产生的哈希值等。
+
+| 密钥名称 | 作用 | 谁派生的 |
+| --- | --- | --- |
+| 临时密钥 |  |  |
+| PMS，预备主密钥 | 一切密钥的基础 | ECDHE私钥和对方的公钥 |
+| Early， 早期密钥 | 密钥的基础 | PMS 预备主密钥派生 |
+| Handshake，握手密钥 | 产生握手阶段的密钥 | Early 早期密钥派生 |
+| Master，主密钥 | 产生数据传输阶段的密钥 | Handshake 握手密钥派生 |
+| 中间密钥 |  |  |
+| CLIENT\_HANDSHAKE\_TRAFFIC\_SECRET | 用于产生最终密钥 | Handshake 握手密钥派生 |
+| SERVER\_HANDSHAKE\_TRAFFIC\_SECRET | 用于产生最终密钥 | Handshake 握手密钥派生 |
+| CLIENT\_TRAFFIC\_SECRET\_0 | 用于产生最终密钥 | Master 主密钥派生 |
+| SERVER\_TRAFFIC\_SECRET\_0 | 用于产生最终密钥 | Master 主密钥派生 |
+
+最终密钥的类型：TLS\_AES\_256\_GCM\_SHA384 为例
+
+```
+- \`客户端写密钥\` - 用于客户端加密/服务器解密。48字节
+- \`服务器写密钥\` - 用于服务器加密/客户端解密。48字节
+- \`客户端写 IV\` - 初始化向量。12字节
+- \`服务器写 IV\` - 初始化向量。12字节
+```
+
+IV(Initialization Vector)：初始向量，还有一个名字：nonce，也是一个随机数。
+
+真正做加密解密的，其实是写密钥和初始向量IV。
+
+---
+
+## 总结
+
+啰啰嗦嗦这么多，写得我头大，看的人估计也蒙了。
+
+没办法，TLS 就是这么复杂。
+
+为了写 MITM 代理，不仅要看懂协议，还要在 OpenSSL 开源代码中找到相应的函数，
+
+实现所有的计算。
+
+从最初的 ECDHE 私钥开始，计算十几个密钥，容易吗。
+
+还好，我已经建立了一个项目，专门学习这件事。
+
+如果密钥计算错误，后面的包一定解析错误，没法继续。
+
+破解 https 流量包，真的很难。
+
+谁不难呢？
+
+学习OpenSSL，调用 OpenSSL 库都这么难，写 OpenSSL 库就更难了。
+
+## 后记
+
+[![](https://picx.zhimg.com/v2-a1b5f8ff4e7d54f863be51081b631633.jpg?source=7e7ef6e2&needBackground=1)openssl-5-立项openssl-dec1 赞同 · 0 评论](https://zhuanlan.zhihu.com/p/1960580134147958148) 文章
+
+这个项目，用来学习 TLS协议和 Open SSL。
+
+解密https：用MITM 技术，两边欺骗，用自己的私钥
+
+现在是学习阶段，只要解析抓到的https：破解需要 ECDHE 私钥，从哪里取得私钥？
+
+这里先卖个关子，以后再说。
+
+现在假设已经取得本次https 通讯的ECDHE 私钥，需要破解本次https，怎么做？
+
+就需要计算上面提到的所有密钥，然后用密钥解密。
+
+下一节，先讲 ECDHE：计算预备主密钥 PMS。
+
+再下一节，讲如何从 PMS 生成 Early 密钥，再生成握手密钥，再生成主密钥；
+
+最后，讲最终密钥的诞生。
+
+都是用 c 语言实现，调用OpenSSL 库，实际项目展示。
@@ -0,0 +1,38 @@
+[NIST 后量子密码标准征集提案 - Ding Key Exchange](%E4%BF%A1%E5%AE%89+c5006103-ca4f-4a85-95c4-a6af67150bdc/NIST+%E5%90%8E%E9%87%8F%E5%AD%90%E5%AF%86%E7%A0%81%E6%A0%87%E5%87%86%E5%BE%81%E9%9B%86%E6%8F%90%E6%A1%88+-+Ding+Key+Exchange%20fde331e3-7eb2-497e-996a-7a719f2ed50c.md)
+
+[国内算法标准介绍](%E4%BF%A1%E5%AE%89+c5006103-ca4f-4a85-95c4-a6af67150bdc/%E5%9B%BD%E5%86%85%E7%AE%97%E6%B3%95%E6%A0%87%E5%87%86%E4%BB%8B%E7%BB%8D%20f0c4456b-c391-4d50-9032-8c5f43b0d25d.md)
+
+[SSL VPN产品常见问题问答](%E4%BF%A1%E5%AE%89+c5006103-ca4f-4a85-95c4-a6af67150bdc/SSL+VPN%E4%BA%A7%E5%93%81%E5%B8%B8%E8%A7%81%E9%97%AE%E9%A2%98%E9%97%AE%E7%AD%94%203f2724eb-6212-4ddc-90a1-d904676fb2d7.md)
+
+[PKI技术规范](%E4%BF%A1%E5%AE%89+c5006103-ca4f-4a85-95c4-a6af67150bdc/PKI%E6%8A%80%E6%9C%AF%E8%A7%84%E8%8C%83%20abf96506-5c16-4a03-ac32-1839f6dcc2a3.md)
+
+[LDAP模型简介](%E4%BF%A1%E5%AE%89+c5006103-ca4f-4a85-95c4-a6af67150bdc/LDAP%E6%A8%A1%E5%9E%8B%E7%AE%80%E4%BB%8B%202ea0c61c-1e7f-48d4-8a4e-43a790113dd1.md)
+
+[PKCS](%E4%BF%A1%E5%AE%89+c5006103-ca4f-4a85-95c4-a6af67150bdc/PKCS%20183e00f5-5a58-4754-921c-b52c536ec7ba.md)
+
+[图解 ECDHE 密钥交换算法](%E4%BF%A1%E5%AE%89+c5006103-ca4f-4a85-95c4-a6af67150bdc/%E5%9B%BE%E8%A7%A3+ECDHE+%E5%AF%86%E9%92%A5%E4%BA%A4%E6%8D%A2%E7%AE%97%E6%B3%95%20118cb81b-7cb1-471e-9fc2-ccfd0897265d.md)
+
+
+
+[RFC PKCS](%E4%BF%A1%E5%AE%89+c5006103-ca4f-4a85-95c4-a6af67150bdc/RFC+PKCS%204eb23dea-bc96-4397-badb-08fd3a4b4d3b.md)
+
+[项目管理](%E4%BF%A1%E5%AE%89+c5006103-ca4f-4a85-95c4-a6af67150bdc/%E9%A1%B9%E7%9B%AE%E7%AE%A1%E7%90%86%200577dadf-ecb3-4551-b005-8502d52e9076.md)
+
+[国密及PKCS7的OID](%E4%BF%A1%E5%AE%89+c5006103-ca4f-4a85-95c4-a6af67150bdc/%E5%9B%BD%E5%AF%86%E5%8F%8APKCS7%E7%9A%84OID%20cea170ba-032d-4330-99b9-883d6a4b9f53.md)
+
+[[开源+免费] 一款释放数据价值的项目，开源隐私计算平台](%E4%BF%A1%E5%AE%89+c5006103-ca4f-4a85-95c4-a6af67150bdc/%5B%E5%BC%80%E6%BA%90+%E5%85%8D%E8%B4%B9%5D+%E4%B8%80%E6%AC%BE%E9%87%8A%E6%94%BE%E6%95%B0%E6%8D%AE%E4%BB%B7%E5%80%BC%E7%9A%84%E9%A1%B9%E7%9B%AE%EF%BC%8C%E5%BC%80%E6%BA%90%E9%9A%90%E7%A7%81%E8%AE%A1%E7%AE%97%E5%B9%B3%E5%8F%B0%20cdc79c72-d449-49ec-b9e7-cea4a9a1654c.md)
+
+[0028 密码模块安全技术要求](%E4%BF%A1%E5%AE%89+c5006103-ca4f-4a85-95c4-a6af67150bdc/0028+%E5%AF%86%E7%A0%81%E6%A8%A1%E5%9D%97%E5%AE%89%E5%85%A8%E6%8A%80%E6%9C%AF%E8%A6%81%E6%B1%82%205b0b1d2f-cdfd-4c9e-9f10-aba05fe594b8.md)
+
+[国密规范整理](%E4%BF%A1%E5%AE%89+c5006103-ca4f-4a85-95c4-a6af67150bdc/%E5%9B%BD%E5%AF%86%E8%A7%84%E8%8C%83%E6%95%B4%E7%90%86%2055695b92-a4a1-4cd2-a924-7f447f0e60c7.md)
+
+[常见密码算法整理](%E4%BF%A1%E5%AE%89+c5006103-ca4f-4a85-95c4-a6af67150bdc/%E5%B8%B8%E8%A7%81%E5%AF%86%E7%A0%81%E7%AE%97%E6%B3%95%E6%95%B4%E7%90%86%2096365711-a286-4773-b41b-6952a0b919d3.md)
+
+[公网服务](%E4%BF%A1%E5%AE%89+c5006103-ca4f-4a85-95c4-a6af67150bdc/%E5%85%AC%E7%BD%91%E6%9C%8D%E5%8A%A1%2034fc074a-f3e4-45d3-ac3f-0d8ba86bbf04.md)
+
+[网关](%E4%BF%A1%E5%AE%89+c5006103-ca4f-4a85-95c4-a6af67150bdc/%E7%BD%91%E5%85%B3%20c8d457aa-67b3-4082-979d-a34fe5b23ae2.md)
+
+[算法模式-GCM模式](%E4%BF%A1%E5%AE%89+c5006103-ca4f-4a85-95c4-a6af67150bdc/%E7%AE%97%E6%B3%95%E6%A8%A1%E5%BC%8F-GCM%E6%A8%A1%E5%BC%8F%207ea48eed-5208-4455-a689-327346ac4fc6.md)
+
+[消息认证中容易混淆的概念（Hash，Mac，Hmac，CMAC，GMAC，GCM，AEAD, Mac-Tag, Nonce）](%E4%BF%A1%E5%AE%89+c5006103-ca4f-4a85-95c4-a6af67150bdc/%E6%B6%88%E6%81%AF%E8%AE%A4%E8%AF%81%E4%B8%AD%E5%AE%B9%E6%98%93%E6%B7%B7%E6%B7%86%E7%9A%84%E6%A6%82%E5%BF%B5%EF%BC%88Hash%EF%BC%8CMac%EF%BC%8CHmac%EF%BC%8CCMAC%EF%BC%8CGMAC%EF%BC%8CGCM%EF%BC%8CAEAD,+Mac-Tag,+Nonce%EF%BC%89%20cd82dca5-b108-4403-ba78-4c5a175a5960.md)
+
@@ -0,0 +1,10 @@
+4 个安全等级：
+
+- 安全一级
+
+    
+
+    
+
+
+
@@ -0,0 +1,112 @@
+LDAP模型是从X.500协议中继承而来的，是LDAP的一个组成部分，用于指导客户如何使用目录服务。LDAP定义了4个模型，包括信息模型(Information Model)、命名模型(Naming Model)、功能模型(Functional Model)、安全模型(Security Model)。
+
+**1.信息模型**
+
+LDAP信息模型用于描述LDAP中信息的表达方式，包含3部分：条目（Entries）、属性（Attribute）、值(Values)。LDAP使用专有逻辑格式存储信息，这种模型既不是关系的，也不是完全面向对象的。简单概括为：
+
+① LDAP中信息逻辑上表示为条目。
+
+② 条目包含一到多个对象类。
+
+③ 每个对象类由多个属性组成。
+
+④ 每个属性包含一到多个同一类型的数值。
+
+⑤ 对象类和属性的类型定义构成了schema。
+
+条目是目录中最基本的信息单元，可以理解为目录树中的一个节点。LDAP客户和服务器使用条目共享信息，条目是LDAP服务器的基本元素。执行搜索时服务器返回一组匹配条目，但修改时一次只能影响服务器中的一个条目。条目可以被任何支持LDAP的客户端创建，或通过使用服务器工具导入，也可由应用程序基于非LDAP数据或用户信息创建。
+
+在目录中添加一个条目时，该条目必须包含一个或者多个对象类（objectClass），每一个对象类规定了该条目中的必选属性和可选属性。图6-1展示了一个典型目录的一部分，它反映了现实世界中一个组织的管理对象。
+
+![http://scanywhere.com/images/technology/LDAP-1.jpg](http://scanywhere.com/images/technology/LDAP-1.jpg)
+
+**图6-1 组织结构目录树**
+
+每一个条目都有一个DN（distinguished name，辨别名），用于唯一标识条目在目录中的位置，本书将在命名模型中详细介绍DN。
+
+每个条目都是由多个属性组成的，每一个属性描述了对象的一个约束。每个属性具有一个类型和一个或多个值。该类型描述了包含在属性中的信息类型，其值中包含实际数据。
+
+例如，表6-1描述了一个人员条目，属性包括全称、名、姓、电话号码、电子邮件地址。
+
+|||
+|-|-|
+|属性类型|属性值|
+|cn|张三|
+|telephoneNumber|5804669062300098|
+|mail|zs@163.com|
+
+**表6-1人员属性**
+
+属性有与之关联的语法和匹配规则，属性语法指定可以在属性中存放的数据格式，如INTEGER语法允许值中只包含数字，不能包含非数字字符。
+
+匹配规则作用有二：第一，比较值是否相等；第二，对值进行排序。
+
+**2．命名模型**
+
+LDAP命名模型定义了如何在目录系统中组织数据以及如何从目录系统中查找数据命名模型的灵活性可以使你很方便地以想要的方式组织数据。例如，可以把组织中所有员放在一个容器下，所有组放在一个容器下，或按组织结构的地理分布组织目录结构。
+
+LDAP命名模型指定将条目按类似倒立的树结构进行规划，非常类似于UNIX系统的文件系统，如图6-2和图6-3所示。
+
+![http://scanywhere.com/images/technology/LDAP-2.jpg](http://scanywhere.com/images/technology/LDAP-2.jpg)
+
+**图6-2 目录树结构**
+
+![http://scanywhere.com/images/technology/LDAP-3.jpg](http://scanywhere.com/images/technology/LDAP-3.jpg)
+
+**图6-3 UNIX 文件系统**
+
+
+
+在LDAP目录中任何一个节点都可以包含信息，同时也可以是一个容器，也就是说任何一个LDAP条目都可以有子节点。图6-4表示了一个典型的目录结构，在目录树中，条目ou-People，dc-example，dc=com和条目ou=Devices，dc=example，dc=com都既包含属性又包含子节点。
+
+通过命名模型，可以给出目录中任何条目的唯一名称，从而可以毫无歧义地引用任一个条目。在LDAP中使用DN来引用条目。
+
+在目录中，按目录树从下到上对条目进行命名，如图6-4中的灰色条同的DN名称为uid=bjensen，ou=people，dc=example，dc=com。因为这种树形结构决定了从根节点到其他任何节点的路径是唯一的，所以说每一个条目的DN是唯一的。
+
+![http://scanywhere.com/images/technology/LDAP-4.jpg](http://scanywhere.com/images/technology/LDAP-4.jpg)
+
+**图6-4 典型目录结构**
+
+在DN中最左边的内容称为相对辨别名（RDN，Relative Distinguished Name）。如ou=People，dc=example，dc=com的RDN为ou=People。对于共享同一个父节点的所有节点的RDN必须是唯一的。如果不属于同一个父节点，则节点的RDN可以相同。当特殊字符出现在DN中时，必须进行转义，如表6-2所示。
+
+||||
+|-|-|-|
+|字符|数值|转义序列|
+|在DN或RDN开始或结尾的空格|32|\空格|
+|在DN或RDN开始的#|35|\#|
+|逗号（，）|44|\，|
+|加号（+）|43|\+|
+|双引号（“）|34|\”|
+|反斜线（\）|92|\\|
+|小于符（<）|60|\<|
+|大于符（>）|62|\>|
+|分号（;）|59|\;|
+
+表6-2 特殊字符转义表
+
+**3.功能模型**
+
+LDAP功能模型描述了LDAP协议可以采用的相关操作，以访问存储在目录树中的数据。在LDAP中共有4类10种操作。
+
+①查询类操作，如搜索、比较。
+
+②更新类操作，如添加条目、删除条目、修改条目、修改条目名。
+
+③认证类操作，如绑定、解绑定。
+
+④其他操作，如放弃和扩展操作。
+
+除了扩展操作，另外9种是LDAP的标准操作。扩展操作是LDAP中为了增加新的功能提供的一种标准的扩展框架，当前已经成为LDAP标准的扩展操作，有修改密码和StartTLS扩展，在新的RFC标准和草案中正在增加一些新的扩展操作，不同的LDAP厂商也均定义了自己的扩展操作。
+
+**4．安全模型**
+
+安全模型提供一个安全框架，保护目录中的信息不被非法访问。LDAP中的安全模型主要通过身份认证、安全通道和访问控制(ACL)实现。
+
+LDAP是一个面向连接的协议，在能够对LDAP目录进行任何操作之前，LDAP客户端必须获得一个到LDAP服务端的连接，在这个过程中需要对LDAP客户端的身份进行验证，这一过程可以理解为用户绑定。
+
+LDAP v2只支持简单的密码验证。LDAP v3实现了SASL安全框架，SASL为多种验证协议提供了一种标准的验证方法，对于不同的验证系统，可以实现特定的SASL机制。
+
+在LDAP中提供了基于SSL/TLS的通信安全保障。SSL/TLS基于PKI信息安全技术，LDAP通过StartTLS方式启动TLS服务，可以提供通信中的数据保密性、完整性保护；通过强制客户端证书认证的TLS服务，同时可以实现对客户端身份和服务器端身份的双向验证。
+
+在用户通过验证之后，可以为该用户分配附加的权限。比如，一些用户只能查看特定的条目，而不能修改；一些用户可以查看并且修改所有的条目等。这一过程可以理解为访问控制。
+
@@ -0,0 +1,22 @@
+## 后量子密码 (Post-quantum Cryptography) 及背景
+
+1994 年，Peter Shor 提出了著名的量子算法。Shor 的量子算法可以实现：当足够大的量子计算机存在时，一些数论中的困难问题可以被有效解决，例如：离散对数问题（及其椭圆曲线版本），并可以被用于分解大整数。注意到离散对数问题（及其椭圆曲线版本）和大整数分解问题是目前广泛应用的公钥密码学算法（[Diffie-Hellman 密钥交换协议](https://zh.wikipedia.org/wiki/%E8%BF%AA%E8%8F%B2-%E8%B5%AB%E7%88%BE%E6%9B%BC%E5%AF%86%E9%91%B0%E4%BA%A4%E6%8F%9B)、[RSA](https://zh.wikipedia.org/wiki/RSA%E5%8A%A0%E5%AF%86%E6%BC%94%E7%AE%97%E6%B3%95)、[椭圆曲线 (ECC)](https://zh.wikipedia.org/wiki/%E6%A4%AD%E5%9C%86%E6%9B%B2%E7%BA%BF%E5%AF%86%E7%A0%81%E5%AD%A6) 等）的困难性的基础。在没有量子计算机和对应的算法时，现有的经典公钥密码算法配合较为合适的参数（例如 2048 比特的 RSA）可以被认为在一定时间内是安全的。但是，一旦大型的量子计算机成功建造，Shor 的算法被认为可以快速且完全攻破大多数目前使用的公钥密码算法，即使参数被显著增大 $^{[1]}$。
+
+*[1] 这里的“参数被显著增大”指的是在计算和通信开销可接受范围内的情况。当参数被“急剧增大”时，RSA 算法被认为可以“抵抗”量子计算机攻击。但此时，公钥的尺寸已经接近几百 M 甚至大于 1 GB。*
+
+在真实世界中，广泛应用于各类安全应用、协议中的密码学原语包括且不仅限于：公钥加密、数字签名、密钥交换等。基于所有的互联网服务都依赖于密码学算法，包括且不仅限于 TLS、HTTPS、SSH、邮件、电子商务、移动支付、数字货币等。所有网络、软件、系统、应用安全等所有现代互联网的应用都将受到严峻的挑战。
+
+后量子密码学 (Post-quantum Cryptography) 的任务是构造可以抵抗经典和量子计算机攻击的新的密码学算法，以应对量子计算机对于密码学的威胁。主要的后量子密码学实现技术有：基于格 (Lattice-based)、基于哈希 (Hash-based) 、基于编码 (Code-based) 、基于多变量 (Multivariate-based) 、基于格 (Lattice-based) 等。这四种方法各有其利弊。目前认为，在上述四种实现后量子密码算法的技术中，基于格的密码算法可以实现最强的安全性、最小的总通信开销、最快的计算速度和最多样化的密码算法设计。
+
+截至目前，Google 已对后量子密码学算法的实用性进行[实际测试](https://security.googleblog.com/2016/07/experimenting-with-post-quantum.html)。Google 将后量子密钥交换协议应用于 TLS 中，并在 Google Chrome 浏览器的 Canary 分支和部分 Google Play 服务器上成功进行了测试。
+
+您可以参考后量子密码学的 [Wikipedia 页面](https://en.wikipedia.org/wiki/Post-quantum_cryptography)、[Nature 上的文章](https://www.nature.com/articles/nature23461)或[较为系统的介绍后量子密码学的书](https://www.springer.com/us/book/9783540887010)等资源对后量子密码学进行更多的了解。您还可以参考这两篇较为详细的后量子密码学中文介绍：[“从量子计算到量子安全”](http://www.knowfar.org.cn/html/zhanlue/201612/22/641.htm)和[“后量子密码技术发展分析”](http://www.knowfar.org.cn/html/zhanlue/201701/13/657.htm)。
+
+# [https://if2007.github.io/2018/04/06/nist_pqc/#NIST-后量子密码标准征集工作](https://if2007.github.io/2018/04/06/nist_pqc/#NIST-后量子密码标准征集工作)NIST 后量子密码标准征集工作
+
+2016 年 12 月 20 日，美国国家标准技术研究所 (National Institute of Standards and Technology, NIST) [正式宣布](https://csrc.nist.gov/news/2016/public-key-post-quantum-cryptographic-algorithms)启动全世界范围内的后量子密码算法标准征集竞赛，旨在征集新一代的可以抵抗量子计算机攻击的公钥加密、数字签名和密钥交换协议。此竞赛欢迎全球范围内所有个人/组织向 NIST 提交密码算法的文档、工程实现。NIST 公开所有符合初步筛选标准的候选算法，供所有人进行分析和评论，利用所有人的力量共同制定新一代的密码学算法标准。
+
+候选算法的征集工作已于 2017 年 11 月 30 日截止，共有来自 25 个国家的 82 个候选算法被提交，其中 69 个符合 NIST 的初步筛选标准。全部 69 个候选算法涵盖了基于格、多变量、编码和哈希等的后量子密码学算法构造。所有候选算法的文档已于 2017 年 12 月[公布于 NIST 网站](https://csrc.nist.gov/projects/post-quantum-cryptography/round-1-submissions)。
+
+NIST 的后量子密码学专家 Dustin Moody 在 AsiaCrypt 2017 会议上对 NIST 的后量子密码标准征集竞赛和现状进行了详细的介绍。报告的 Slide 可以在[这里下载](https://csrc.nist.gov/CSRC/media/Projects/Post-Quantum-Cryptography/documents/asiacrypt-2017-moody-pqc.pdf)。
+
@@ -0,0 +1,35 @@
+RSA定义的 PKCS 各版本，用途各不相同；
+
+PKCS #1 定义私钥签名运算的填充方式， v1.5 是 PKCS1_PADDING, v2.1 是 PKCS1_PSS_PADING；
+
+PKCS#2：涉及了RSA的消息摘要加密，这已被并入PKCS#1中。
+
+PKCS#3：Diffie-Hellman密钥协议标准。PKCS#3描述了一种实现Diffie- Hellman密钥协议的方法。
+
+PKCS#4：最初是规定RSA密钥语法的，现已经被包含进PKCS#1中。
+
+PKCS #5  基于口令的加密标准。PKCS#5描述了使用由口令生成的密钥来加密8位位组串并产生一个加密的8位位组串的方法。PKCS#5可以用于加密私钥，以便于密钥的安全传输（这在PKCS#8中描述）。定义了加密运算的填充方式，8字节填充，Java标准接口支持；例如，串0x56在经过PKCS5填充之后会成为0x56 0x07 0x07 0x07 0x07 0x07 0x07 0x07因为需要填充7字节，因此填充的内容就是7。当然特殊情况下，如果已经满足了8的整倍数，按照PKCS5的规则，仍然需要在尾部填充8个字节，并且内容是0x08,目的是为了加解密时统一处理填充。
+
+PKCS#6：扩展证书语法标准。PKCS#6定义了提供附加实体信息的X.509证书属性扩展的语法（当PKCS#6第一次发布时，X.509还不支持扩展。这些扩展因此被包括在X.509中）。
+
+PKCS #7   密码消息语法标准。PKCS#7为使用密码算法的数据规定了通用语法，比如数字签名和数字信封。PKCS#7提供了许多格式选项，包括未加密或签名的格式化消息、已封装（加密）消息、已签名消息和既经过签名又经过加密的消息。 填充算法扩充了PKCS#5 的限制，填充长度可以是1-255字节；通过第三方库可以在Java中支持 PKCS#7 填充；
+
+PKCS#8：私钥信息语法标准。PKCS#8定义了私钥信息语法和加密私钥语法，其中私钥加密使用了PKCS#5标准；
+
+PKCS#9：可选属性类型。PKCS#9定义了PKCS#6扩展证书、PKCS#7数字签名消息、PKCS#8私钥信息和PKCS#10证书签名请求中要用到的可选属性类型。已定义的证书属性包括E-mail地址、无格式姓名、内容类型、消息摘要、签名时间、签名副本（counter signature）、质询口令字和扩展证书属性。
+
+PKCS#10：证书请求语法标准。PKCS#10定义了证书请求的语法。证书请求包含了一个唯一识别名、公钥和可选的一组属性，它们一起被请求证书的实体签名（证书管理协议中的PKIX证书请求消息就是一个PKCS#10）。
+
+PKCS#11：密码令牌接口标准。PKCS#11或“Cryptoki”为拥有密码信息（如加密密钥和证书）和执行密码学函数的单用户设备定义了一个应用程序接口（API）。智能卡就是实现Cryptoki的典型设备。注意：Cryptoki定义了密码函数接口，但并未指明设备具体如何实现这些函数。而且Cryptoki只说明了密码接口，并未定义对设备来说可能有用的其他接口，如访问设备的文件系统接口。
+
+PKCS#12：个人信息交换语法标准。PKCS#12定义了个人身份信息（包括私钥、证书、各种秘密和扩展字段）的格式。PKCS#12有助于传输证书及对应的私钥，于是用户可以在不同设备间移动他们的个人身份信息。
+
+PKCS#13：椭圆曲线密码标准。PKCS#13标准当前正在完善之中。它包括椭圆曲线参数的生成和验证、密钥生成和验证、数字签名和公钥加密，还有密钥协定，以及参数、密钥和方案标识的ASN.1语法。
+
+PKCS#14：伪随机数产生标准。PKCS#14标准当前正在完善之中。为什么随机数生成也需要建立自己的标准呢？PKI中用到的许多基本的密码学函数，如密钥生成和Diffie-Hellman共享密钥协商，都需要使用随机数。然而，如果“随机数”不是随机的，而是取自一个可预测的取值集合，那么密码学函数就不再是绝对安全了，因为它的取值被限于一个缩小了的值域中。因此，安全伪随机数的生成对于PKI的安全极为关键。
+
+PKCS#15：密码令牌信息语法标准。PKCS#15通过定义令牌上存储的密码对象的通用格式来增进密码令牌的互操作性。在实现PKCS#15的设备上存储的数据对于使用该设备的所有应用程序来说都是一样的，尽管实际上在内部实现时可能所用的格式不同。PKCS#15的实现扮演了翻译家的角色，它在卡的内部格式与应用程序支持的数据格式间进行转换。
+————————————————
+版权声明：本文为CSDN博主「zhbpd」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
+原文链接：[https://blog.csdn.net/zhbpd/article/details/107732995](https://blog.csdn.net/zhbpd/article/details/107732995)
+
@@ -0,0 +1,8 @@
+
+
+[PKI体系框架](PKI%E6%8A%80%E6%9C%AF%E8%A7%84%E8%8C%83+abf96506-5c16-4a03-ac32-1839f6dcc2a3/PKI%E4%BD%93%E7%B3%BB%E6%A1%86%E6%9E%B6%20ed780626-80e7-461a-8b12-81290718f525.md)
+
+[PKI/数字证书与私钥](PKI%E6%8A%80%E6%9C%AF%E8%A7%84%E8%8C%83+abf96506-5c16-4a03-ac32-1839f6dcc2a3/PKI+%E6%95%B0%E5%AD%97%E8%AF%81%E4%B9%A6%E4%B8%8E%E7%A7%81%E9%92%A5%20e89e4605-b474-4bc8-963d-ecdc5999a2ea.md)
+
+[PKI/CA与KMC](PKI%E6%8A%80%E6%9C%AF%E8%A7%84%E8%8C%83+abf96506-5c16-4a03-ac32-1839f6dcc2a3/PKI+CA%E4%B8%8EKMC%20dfb166ae-f52a-4cdb-90b6-499293b1f684.md)
+
@@ -0,0 +1,82 @@
+**1．CA最初目的是签发数字证书**
+
+为解决数字证书的签发问题，PKI引入CA．用于对数字证书进行集中签发。CA是Certificate Authority昀缩写，字面含义是证书权威，也称作CA中心、认证中心。CA中心拥有自己的公钥和私钥，使用其私钥给用户（包含CA巾心自己）签发数字证书，具体签发过程如下：
+
+(1)将用户身份信息和用户公钥信息，按照特定格式组成数据D。
+
+(2)选择摘要算法对数据D进行计算得到摘要H。
+
+(3)使用CA私钥对摘要H进行加密得到数字签名S。
+
+(4)将用户身份信息、用户公钥信息和数字签名S，按照特定格式就可组成数字证书。
+
+**2．CA应对数字证书的全生命周期进行管理**
+
+CA实际是一种特殊的公钥管理中心，为实现数字证书的安全性，应对数字证书的全生命周期进行管理，主要包括：
+
+(1)数字证书的签发和更新。证书签发主要针对新用户；证书更新主要针对已有证书用户，更新时公钥可以改变，也可以不变。
+
+(2)数字证书的作废（注销、撤销或吊销）。证书作废后将成无效证书，永远不能使用。
+
+(3)数字证书的冻结（挂失）和解冻。证书冻结后将成无效证书，但可以通过解冻恢复成有效状态。
+
+(4)数字证书的查询或下载。应提供公开服务方式，允许用户根据条件随时查询证书并下载。常用服务方式有HTTP和LDAP。
+
+(5)数字证书状态查询。应提供公开服务方式，允许用户随时查询证书状态，以便判断该证书是否处于有效状态。常用服务方式有CRL和OCSP。
+
+**3．KMC用于管理私钥**
+
+如果使用公钥（数字证书）对数据进行加密，则只有与公钥对应的私钥才能进行解密，从而可实现用户数据的保密性。当私钥丢失时，如果没有备份和恢复机制，将导致公钥加密的所有数据都无法解密，可能给用户带来损失。
+
+为解决私钥的备份与恢复问题，PKI引入了KMC，用于对私钥的全生命周期进行管理。KMC是Key Management Center的缩写。
+
+用户公私钥对可由KMC产生，提交CA签发数字证书后，将私钥和数字证书同时安全移交给用户，而KMC将私钥留作备份，可按需要给用户恢复。用户公私钥对也可由用户自己产生（使用软件或密码设备），在向CA中心申请数字证书时，可将私钥安全提交KMC留作备份。
+
+**4．双证书机制**
+
+为防止用户身份被冒用，应保证用户私钥的唯一性，不允许备份恢复。为防止公钥加密后的数据无法解密，应提供用户私钥的备份恢复机制。
+
+为解决这两种矛盾的应用需求，PKI引入双证书机制：签名证书和加密证书。
+
+签名证书及私钥只用于签名验签，不能用于加密解密；为保证签名私钥的唯一性，该公私钥对必须由用户自己产生，同时采用硬件技术（如只允许在硬件密码设备内产生公私钥对、私钥不允许导出等）保证无法复制，在证书签发过程中CA中心并不知道该私钥，只对其公钥进行操作。该私钥没有备份，因此永远不能恢复。
+
+加密证书及私钥只用于加密解密，不能用于签名验签。为实现解密私钥的备份恢复机制，该公私钥对必须由KMC产生，由CA签发完数字证书后安全移交给用户，用户应采用硬件技术保证该私钥的安全性。KMC可根据需要恢复该私钥。
+
+**5．LDAP**
+
+CA中心存储着所有数字证书，并通过公开服务形式供用户随时查询或下载。为解决数字证书查询或下载的性能问题，避免CA中心成为性能瓶颈，PKI引入了LDAP技术，通过LDAP方式对外提供高速证书查询或下载服务。
+
+专业的关系型数据库管理系统（如Oracle、DB2等）专门对结构化数据进行管理，应用系统只需通过SQL语句（报文协议）发送各种数据管理指令，而具体管理工作完全由数据库管理系统负责。尽管这种数据管理方式大大简化了应用系统的复杂度，但由于其读写功能相对均衡，很难满足高性能的查询服务。为获得高性能的查询服务，需要对数据管理的读取功能进行特殊优化，于是出现了目录服务技术（DAP，Directory Access Protocol）。目录服务技术对查询功能进行优化，比修改操作快10倍以上，适合快速响应和大容量查询服务。DAP技术通过目录树方式对数据进行管理，应用系统只需通过x.500协议就能对数据进行快速查询。
+
+由于X.500协议过于复杂，实现成本很高，于是国际组织对X.500进行了简化，形成LDAP标准，而且LDAP支持TCP/IP协议，更适合于互联网领域使用。LDAP为轻量目录访问协议，是Light-weight Directory Access Protocol的缩写。
+
+由于数字证书是可以公开的，CA中心也可以将其签发的数字证书存储到其他地方，供用户查询或下载。
+
+**6．CRL和OCSP**
+
+当用户私钥泄露后，CA中心有责任将该用户的证书标记为失效。但用户如何获得对方证书足否失效的状态呢？为方便用户获得证书状态，PKI引入了CRL和OCSP技术。
+
+(1) CRL(Certificate Revocation List)
+
+CRL为证书作废列表，是Certificate Revocation List的缩写，也称作证书黑名单，是一种特殊的文件格式，包含所有失效的证书清单、下次CRL生成时间和CA中心私钥的签名。
+
+CA中心定期生成CRL．并将下次生成时问写入CRL中，方便用户按时定期下载CRL。跟数字证书类似，CRL也是通过CA中心私钥的签名来保证CRL无法被篡改的。用户只需定期获取CRL后，就可在本地脱机验证证书是否失效，在下次CRL生成时间之前无需联系CA中心。
+
+由于CRL是可以公开的，CA中心也可以将其链发的CRL存储到其他地方，供用户查询或下载。CRL也可以发布到LDAP中，提供高速下载服务。
+
+(2) OCSP (Online Certificate Status Protocol)
+
+当CA中心将私钥已泄露的用户证书标记为失效后，如果还未到下次CRL生成时间，此时其他用户通过最新CRL并不知道该用户证书已经失效，依然将该用户当作有效用户继续进行各种保密通信和合法交易，因此可能会造成一定的损失。
+
+为解决CRL滞后的缺陷，避免给高实时性或高风险交易造成重大损失，PKI引入了OCSP，对用户提供实时的证书状态查询服务。OCSP为在线证书状态协议，是Online Certificate Status Protocol的缩写。当用户需要实时查询对方证书是否有效时，可通过OCSP协议实时访问CA中心获得对方证书的当前状态。
+
+**7．RA**
+
+在保证CA系统安全性的前提下，为方便证书业务远程办理、方便证书管理流程与应用系统结合，PKI引入了RA，专门用于对用户提供面对面的证书业务服务，负责用户证书办理／作废申请、用户身份审核、制作证书并移交用户等功能，而涉及证书签发时则提交CA系统集中处理。RA是Registry Authority的缩写，又称作RA中心、注册中心。有时候，证书管理流程会与应用业务流程结合，并不单独体现出来，如对于网上银行，证书管理流程就会融合到网银业务流程中。
+
+RA可以部署多个，既可以单独部署，也可以与应用系统集成。
+
+CA主要模块组成如下图所示。
+
+![http://scanywhere.com/images/technology/PKI-CA-KMC.jpg](http://scanywhere.com/images/technology/PKI-CA-KMC.jpg)
+
@@ -0,0 +1,70 @@
+**1．数字证书的最初目的是建立公钥与用户之间的对应关系**
+
+由于公钥是随机产生的，从公钥无法直接判断属于哪个用户。为解决公钥与用户映射关系问题，PKI引入数字证书，用于建立公钥与用户之间的对应关系。
+
+数字证书实际是一种特殊的文件格式，包含用户身份信息、用户公钥信息和CA私钥的数字签名。用户身份信息由姓名或名称、单位、城市、国家等组成。X.509标准规定了数字证书的具体格式。
+
+由于数字证书中包含用户身份信息和公钥信息，根据数字证书就可直接判断该公钥属于哪个用户。如某数字证书包含用户信息“诸葛亮”和公钥PK，则可判断公钥PK就是诸葛亮的。
+
+由于数字证书中包含CA私钥的数字签名，使用CA公钥对数字证书中CA私钥的数字签名进行解密处理后，就可立刻判断该数字证书是否被篡改，因此数字证书具有防伪性，于是，数字证书中公钥和用户之间对应关系也值得可信。当然，数字证书防伪性的前提是公钥算法和CA私钥都是安全的。
+
+由于数字证书中不包含秘密信息，因此数字证书可公开发布。
+
+数字证书主要内容显示如图2-2所示，其中，“使用者”为用户身份信息，“公钥”为用户公钥信息，“有效期”属于附加策略。
+
+![http://scanywhere.com/images/technology/pki-signature-privatekey.jpg](http://scanywhere.com/images/technology/pki-signature-privatekey.jpg)
+
+                                                        **图2-2 数字证书主要内容显示**
+
+**2．数字证书可作为网络身份证**
+
+现实生活中，公安部为每人颁发一张二代身份证，身份证上包含姓名、性别、出生日期、省份、身份证号、照片等信息。当购票、住店、坐飞机时，身份证持有人（或持证人）只需出示身份证即可证明自己的身份。只有通过以下四个方面的合法性验证，才能完全确认持证人的合法身份：
+
+(1)验证身份证是否伪造。需要专门的二代身份证读写设备来验证。
+
+(2)验证身份证信息是否正确。需要查询身份证数据库，需要公安部门提供；也可由公安部门在发放身份证时保证。
+
+(3)验证身份证是否与持证人一致。需要对比身份证上照片与持证人的长相。
+
+(4)验证身份证是否在黑名单上。需要查询黑名单数据库，如公安部通缉犯清单，需要公安部门提供。
+
+既然数字证书包含用户身份信息，而且具有防伪性且可以公开，那么数字证书持有人（或持证人）在网络世界中能否也像现实生活中一样，只需出示数字证书即可证明自己身份呢？答案是肯定的。如果能通过类似二代身份证的四个方面合法性验证，数字证书就可作为网络身份证。下面来确认一下，数字证书能否通过四个方面的合法性验证：
+
+(1)验证数字证书是否伪造。可通过CA公钥验证。
+
+(2)验证数字证书中信息是否正确。可由CA中心在签发数字证书时保证。
+
+(3)验证数字证书是否与持证人一致。可要求持证人使用私钥对特定数据进行加密或签名，然后使用数字证书中的公钥来解密该数据或验签，从而可验证持证人是否持有与数字证书中的公钥对应的私钥。
+
+(4)验证数字证书是否在黑名单上。可通过查询黑名单数据库来实现，但需要CA中心提供黑名单。
+
+因此，数字证书作为网络身份证，可有效解决网络世界中“你是谁”的问题。由于数字证书采用公钥密码技术实现，从技术上保证了每个人“钥匙”的唯一性，既不重复也无法复制，所以数字证书比现实生活中的各种钥匙安全很多。
+
+**3．数字证书可附加很多策略**
+
+由于数字证书具有防伪性和公开性，因此数字证书中不仅可包含用户身份信息和用户公钥信息，而且还可以附加其他策略信息，这些信息同样具有防伪性和公开性。
+
+X.509数字证书标准中规定常用策略信息主要包括：
+
+(1)有效期。包括起始时间和终止时问。
+
+(2)密钥用途。表示该公钥和私钥用于什么目的，如数据签名、数据加密、签发证书、用于安全电子邮件等。
+
+(3)别名。包括持证人别名和CA中心别名。
+
+(4)黑名单地址。
+
+(5)是否CA中心的数字证书。如果是CA中心的数字证书，则规定能签发几级证书。
+
+**4．CA中心的数字证书**
+
+用户在验证数字证书是否被篡改时，必须首先获得CA中心的公钥。为方便用户识别CA中心的公钥，CA中心也为自己签发数字证书。该证书包含CA中心公钥、CA中心身份信息和CA中心私钥的签名。CA中心的数字证书有时也称作CA证书。
+
+由于CA证书是验证其他证书合法性的前提和基础，所以CA证书的正确性至关重要。尽管可通过网络直接下载获取CA证书，但为避免被欺骗，需要通过其他方式验证CA证书的正确性。可通过电话方式、官方报纸或官方电视公布CA证书的摘要值，用户通过核对该摘要值即可确认该证书的正确性。
+
+**5．私钥**
+
+对于公钥密码技术，公钥和私钥是成对出现的。公钥以数字证书形式存在，可以公开，但私钥必须保密。为保证私钥的安全性，一般将私钥保存在硬件密码设备中（如个人的私钥可保存在USB Key或lC卡中，系统的私钥可保存在加密机或加密卡中），而且不允许私钥导出硬件密码设备：通过口令、指纹等方式来访问控制该硬件密码没备。如果将私钥保存在硬盘文件中，则需要通过口令进行加密保护，但私钥文件容易被复制。
+
+为保证私钥的唯一性，可只允许在硬件密码设备内产生公私钥对，通过硬件技术保证私钥无法导出，然后只导出公钥提交CA中心签发数字证节。
+
@@ -0,0 +1,44 @@
+PKI是Public Key Infrastructure的缩写，其主要功能是绑定证书持有者的身份和相关的密钥对（通过为公钥及相关的用户身份信息签发数字证书），为用户提供方便的证书申请、证书作废、证书获取、证书状态查询的途径，并利用数字证书及相关的各种服务（证书发布，黑名单发布，时间戳服务等）实现通信中各实体的身份认证、完整性、抗抵赖性和保密性。
+
+根据数字证书格式及密钥管理方式的不同，PKI也包括多种模式，如X.509模式、PGP模式、IBE/CPK模式、EMV模式等。X.509模式的PKI也称作PKIX。由于X.509标准已经成为数字证书格式的事实标准，因此大部分情况下PKI特指PKIX。如非特殊说明，本文中PKI均指PKIX。
+
+PKI体系框架主要包括三部分内容。
+
+**1．数字证书与私钥**
+
+用户或系统只有拥有自己的公钥和私钥后，才能实现数字签名和加解密功能。由于公钥是随机产生的，因此从公钥无法直接判断属于哪个用户。
+
+为解决公钥与用户映射关系问题，PKI引入了数字证书，用于建立公钥与用户之间的对应关系。数字证书实际上是一种特殊的文件格式，包含用户身份信息、用户公钥信息和CA私钥的数字签名。X.509标准规定了数字证书的具体格式。数字证书中只包含公钥，并不包括私钥。由于数字证书中包含CA私钥的数字签名，因此数字证书具有防伪性。由于数字证书中不包含秘密信息，因此数字证书具有公开性。数字证书作为网络身份证，可有效解决网络世界中“你是谁”的问题。
+
+为保证私钥的安全性，一般将私钥保存在硬件密码设备中（如个人的私钥可保存在USBKey或lC卡中，系统的私钥可保存在加密机或加密卡中），而且不允许私钥导出硬件密码设备：通过口令、指纹等方式来访问控制该硬件密码设备。如果将私钥保存在硬盘文件中，则需要通过口令进行加密保护，但私钥文件容易被复制。
+
+**2．数字证书的管理**
+
+为解决数字证书的签发问题，PKI引入CA，对数字证书进行集中签发。CA是Certificate Authority的缩写，字面含义是证书权威，也称作CA中心、认证中心。CA中心拥有自己的公钥和私钥，使用其私钥给用户（包含CA中心自己）签发数字证书。
+
+CA实际是一种特殊的公钥管理中心，为实现数字证书的安全性，对数字证书的全生命周期进行管理，主要包括：数字证书的签发和更新、数字证书的作废（注销、撤销或吊销）、数字证书的冻结（挂失）和解冻、数字证书的查询或下载、数字证书状态查询等。当私钥丢失时，如果没有备份和恢复机制，将导致公钥加密的所有数据都无法解密，可能给用户带来损失。为解决私钥的备份与恢复问题，PKI引入了KMC，用于对私钥的全生命周期进行管理。KMC是Key Management Center的缩写。用户公私钥对可由KMC产生，提交CA签发数字证书后，将私钥和数字证书同时安全移交给用户，而KMC将私钥留作备份，可按需要给用户恢复。用户公私钥对也可由用户自己产生（使用软件或密码设备），在向CA中心申请数字证书时，可将私钥安全提交KMC留作备份。
+
+为防止用户身份被冒用，应保证用户私钥的唯一性，不允许备份恢复。为防止公钥加密后的数据无法解密，应提供用户私钥的备份恢复机制。为解决这两种矛盾的应用需求，PKI引入双证书机制：签名证书和加密证书。签名证书及私钥只用于签名验签，不能用于加密解密，该公私钥对必须由用户自己产生，KMC不备份签名私钥。加密证书及私钥只用于加密解密，不能用于签名验签，该公私钥对必须由KMC产生，且KMC对加密私钥进行备份。
+
+CA中心存储着所有数字证书，并通过公开服务形式供用户随时查询或下载。为解决数字证书查询或下载的性能问题．避免CA中心成为性能瓶颈，PKI引入了LDAP技术，通过LDAP方式对外提供高速证书查询或下载服务。LDAP为轻量目录访问协议，是Light-weight Directory Access Protocol的缩写。
+
+当用户私钥泄露后，CA中心有责任将该用户的证书标记为失效。但用户如何获得对方证书是否失效的状态呢？为方便用户获得证书状态，PKI引入了CRL和OCSP技术。CRL为证书作废列表，是Certificate Revocation List的缩写，也称作证书黑名单。OCSP为在线证书状态协议，是Online Certificate Status Protocol的缩写。
+
+在保证CA系统安全性的前提下，为方便证书业务远程办理、方便证书管理流程与应用系统结合，PKI引入了RA，专门用RA对用户提供面对面的证书业务服务，负责用户证书办理／作废申请、用户身份审核、制作证书并移交用户等功能，而涉及证书签发时则提交CA系统集中处理。RA是Registry Authority的缩写，又称作RA中心、注册中心。有时候，证书管理流程会与应用业务流程结合，并不单独体现出来，如对于网上银行，证书管理流程就会融合到网银业务流程中。
+
+为保证CA系统在数字证书管理方面的规范性、合规性和安全性，PKI引入电子认证服务机构，以第三方运营的方式对外提供数字证书相关服务。《电子签名法》规定：“电子签名需要第三方认证的，由依法设立的电子认证服务提供者提供认证服务。”显然，电子签名法不仅赋予了电子签名的法律效力，而且明确了电子认证服务提供者的法律地位。电子认证服务提供者，又称作电子认证服务机构或CA中心，需要独立运营，不仅需要满足政策法规的各项要求，而且需要满足业务运营的业务需求。
+
+**3．数字证书的应用**
+
+基于数字证书可实现四种基本安全功能：身份认证、保密性、完整性和抗抵赖性。
+
+基于证书接口中间件（模块或组件），应用系统可以很方便地使用数字证书技术，从而提高应用系统的身份认证强度、保证应用系统中各种敏感数据的保密性、保证应用系统中各种敏感数据和交易记录的完整性、用户各种操作或交易的不可否认性（抗抵赖性）。
+
+PKI技术经过30多年的发展历程，已经形成比较完善的标准规范体系，几乎覆盖应用系统的各个方面，目前很多软件都已经支持数字证书技术，如操作系统、数据库系统、Web服务器、应用服务器等。由于受应用环境多样性和应用技术复杂性的影响或限制，在不同的应用环境和应用技术下，数字证书技术应用的方式可能差异很大。
+
+网上报税和网上银行是数字证书应用的典型案例。国内大部分省份上千万家企业已经通过数字证书在进行网上报税。数字证书（俗称U盾）已经成为国内网上银行的标准配置。如果没有数字证书，企业用户将不允许使用网上银行。上亿个人用户已经通过数字证书访问网上银行实现转账或汇款等资金操作。
+
+PKI体系框架如下图：
+
+![http://scanywhere.com/images/technology/pki-framework.jpg](http://scanywhere.com/images/technology/pki-framework.jpg)
+
@@ -0,0 +1,18 @@
+||名称|RFC|
+|-|-|-|
+|PKCS #1|RSA Cryptography Standard (RSA密码标准)|RFC 3447|
+|PKCS #2|已撤销，用以规范RSA加密摘要的转换方式，已并入PKCS #1|-|
+|PKCS #3|Diffie–Hellman Key Agreement Standard (DH秘钥协商标准)|-|
+|PKCS #4|已撤销，用以定义RSA秘钥的格式，已并入PKCS #1|-|
+|PKCS #5|Password-based Encryption Standard (基于口令的密码标准)|RFC 2898|
+|PKCS #6|Extended-Certificate Syntax Standard (扩展的证书语法标准)|-|
+|PKCS #7|Cryptographic Message Syntax Standard (密码消息语法标准)|RFC 2315|
+|PKCS #8|Private-Key Information Syntax Standard (私钥信息语法标准)|RFC 5958|
+|PKCS #9|Selected Attribute Types (可供选择的属性类型)|RFC 2985|
+|PKCS #10|Certification Request Standard (证书请求语法标准)|RFC 2986|
+|PKCS #11|Cryptographic Token Interface (密码Token接口标准)|-|
+|PKCS #12|Personal Information Exchange Syntax Standar (个人信息交换语法标准)|RFC 7292|
+|PKCS #13|Elliptic Curve Cryptography Standard (椭圆曲线密码标准)，正在制定中||
+|PKCS #14|Pseudo-random Number Generation (伪随机数生成算法PRNG)，正在制定中||
+|PKCS #15|Cryptographic Token Information Format Standard (密码Token信息格式标准)||
+
@@ -0,0 +1,18 @@
+**Q1：什么是VPN？**
+A1：VPN的英文全称是“Virtual Private Network”，翻译过来就是“虚拟专用网络”。顾名思义，虚拟专用网络我们可以把它理解成是虚拟出来的企业内部专线。
+　　虚拟专用网（VPN）被定义为通过一个公用网络（通常是因特网）建立一个临时的、安全的连接，是一条穿过混乱的公用网络的安全、稳定的隧道。虚拟专用网是对企业内部网的扩展。虚拟专用网可以帮助远程用户、公司分支机构、商业伙伴及供应商同公司的内部网建立可信的安全连接，并保证数据的安全传输。虚拟专用网可用于不断增长的移动用户的全球因特网接入，以实现安全连接；可用于实现企业网站之间安全通信的虚拟专用线路，用于经济有效地连接到商业伙伴和用户的安全外联网虚拟专用网。
+
+**Q2：什么是SSLVPN？**
+A2：从概念角度来说，SSL VPN即指采用SSL （Security Socket Layer）协议来实现远程接入的一种新型VPN技术。SSL协议是网景公司提出的基于WEB应用的安全协议，它包括：服务器认证、客户认证（可选）、SSL链路上的数据完整性和SSL链路上的数据保密性。对于内、外部应用来说，使用SSL可保证信息的真实性、完整性和保密性。目前SSL 协议被广泛应用于各种浏览器应用，也可以应用于Outlook等使用TCP协议传输数据的C/S应用。正因为SSL 协议被内置于IE等浏览器中，使用SSL 协议进行认证和数据加密的SSL VPN就可以免于安装客户端。相对于传统的IPSEC VPN而言，SSL VPN具有部署简单，无客户端，维护成本低，网络适应强等特点。
+
+**Q3：我们的SSL VPN设备支持的认证方式？**
+A3：我们的SSL VPN设备支持的认证方式：
+　　　本地数据库认证
+　　　AD域认证
+　　　LDAP认证
+　　　RADIUS认证
+　　　RSA SecurID认证
+　　　SSL 双向认证
+　　　MAC地址认证
+　　　手机动态密码认证
+
@@ -0,0 +1,182 @@
+![https://img2023.cnblogs.com/blog/759200/202309/759200-20230912173019683-350983077.png](7%20信安/标准/[开源+免费]+一款释放数据价值的项目，开源隐私计算平台+cdc79c72-d449-49ec-b9e7-cea4a9a1654c/759200-20230912173019683-350983077.png)
+
+在大数据和 AI 的时代背景下，数据已经成为了重要财富，大到政务数据、企业核心数据，小到个人信息、银行卡余额，**这些数据无一例外都是“隐私数据”，如果在使用和流转时发生泄漏都会造成巨大的损失。**
+
+那有没有什么方法，可以在不暴露数据隐私的前提下，让数据流动起来发挥更大的价值呢？在这个问题的驱使下我们找到了今天的主角——隐私计算。
+
+## 一、什么是隐私计算？
+
+隐私计算是指**在不泄露数据本身的情况下，实现数据分析和计算的技术，具有“数据可用不可见”的特点，让数据安全合规地流动起来。**
+
+下面用一个经典的百万富翁问题，来帮助理解什么是“数据可用不见”。
+
+![https://img2023.cnblogs.com/blog/759200/202309/759200-20230912173037042-1565994367.png](7%20信安/标准/[开源+免费]+一款释放数据价值的项目，开源隐私计算平台+cdc79c72-d449-49ec-b9e7-cea4a9a1654c/759200-20230912173037042-1565994367.png)
+
+假设有两个百万富翁，他们都想知道谁更富有，但又不想让对方或者第三方，知道自己具体有多少钱。
+
+- **数据本身**：具体的财富值（数据）
+
+- **计算**：比大小（可用）
+
+- **不泄露**：对方或第三方（不可见）
+
+按照常理，**进行比大小的计算是需要知道两个数是多少，才能比较大小，但这里不知道具体的数字**。所以上面这个问题在普通人看来是无解的，但其实这是一个密码学问题，也被称为“多方安全计算”（ MPC ）问题，由姚期智院士在 1982 提出，并给出了解决方案——混淆电路（篇幅有限这里不做详解），实现了数据的可用不可见。
+
+![https://img2023.cnblogs.com/blog/759200/202309/759200-20230913003503828-1699821043.png](7%20信安/标准/[开源+免费]+一款释放数据价值的项目，开源隐私计算平台+cdc79c72-d449-49ec-b9e7-cea4a9a1654c/759200-20230913003503828-1699821043.png)
+
+从隐私计算的技术发展时间线，我们不难看出隐私计算还是一个比较“新”的技术。随着零知识证明、差分隐私、全同态加密、联邦学习等技术的相继问世，目前已形成**三大应用技术路线多方安全计算（ MPC ）、联邦学习（ FL ）、可信执行环境（ TEE ），**隐私计算作为数据流通的重要技术已应用于金融、医疗、政务、广告等领域。
+
+- 金融：联合反洗钱、银(行)证(券)数据共享等
+
+- 医疗和健康：流行病接触者追踪等
+
+- 政务：案件调查、人口普查等
+
+随着欧盟 2018 年生效的《通用数据保护法案》，Google 、Facebook 等科技巨头都收到了巨额罚单。近两年，我国也相继出台了 **《数据安全法》** 和 **《个人信息保护法》**。因此，**如何让数据安全地流通起来，已经不再是一道附加题而是一道必答题。**
+
+如果我们把上面的“百万富翁”换成企业/机构的话，就可以很容易得出**隐私计算技术就是数据安全流通的答案 🔑。**
+
+## 二、PrimiHub
+
+那么，对于没有隐私计算技术背景的程序员、或是没有相关研发团队的企业/机构，**如何才能快速用上隐私计算技术，让数据流通起来创造更大的价值呢？**
+
+![https://img2023.cnblogs.com/blog/759200/202309/759200-20230912173100017-1094826619.jpg](7%20信安/标准/[开源+免费]+一款释放数据价值的项目，开源隐私计算平台+cdc79c72-d449-49ec-b9e7-cea4a9a1654c/759200-20230912173100017-1094826619.jpg)
+
+今天，HelloGitHub 给大家带来一款**由密码学专家团队打造的开源隐私计算平台——PrimiHub**，它开箱即用、支持 CLI 和可视化 Web 界面，让你无需具备隐私计算技术背景，就能上手发起隐私计算任务。
+
+> GitHub 地址：[https://github.com/primihub/primihub](https://github.com/primihub/primihub)
+
+![https://img2023.cnblogs.com/blog/759200/202309/759200-20230912173108533-648540079.png](7%20信安/标准/[开源+免费]+一款释放数据价值的项目，开源隐私计算平台+cdc79c72-d449-49ec-b9e7-cea4a9a1654c/759200-20230912173108533-648540079.png)
+
+下面，我将先介绍如何快速上手 PrimiHub ，最后通过演示一个完整的应用案例，让你能够真正的入门 PrimiHub ，并将隐私计算应用到实际的业务中。
+
+## 三、快速上手
+
+PrimiHub 是在隐私计算应用技术之上构建的隐私计算平台，封装了底层的密码学协议让开发者专注于业务、更容易上手。下面就让我们实际上手体验一下，让数据流动起来吧！
+
+### 3.1 安装
+
+虽然 PrimiHub 提供了 Docker 、可执行文件、本地编译的安装方式，但是如果你只是想在本地体验一下，我强烈推荐 Docker 一键安装，因为真的是太 easy 了 ～
+
+```Python
+# 第一步：下载
+git clone https://github.com/primihub/primihub.git
+# 第二步：进入目录
+cd primihub
+# 第三步：启动
+docker-compose up -d
+```
+
+### 3.2 发起任务
+
+PrimiHub 将复杂的隐私计算技术封装成了一个个任务，只需要修改配置文件，然后执行命令发起任务即可。
+
+![https://img2023.cnblogs.com/blog/759200/202309/759200-20230912173118353-885693980.png](7%20信安/标准/[开源+免费]+一款释放数据价值的项目，开源隐私计算平台+cdc79c72-d449-49ec-b9e7-cea4a9a1654c/759200-20230912173118353-885693980.png)
+
+PrimiHub 目前支持联合统计、隐私求交、匿踪查询、联邦学习等功能。
+
+- **联合统计**：多个参与方在不暴露私有数据的情况下，共同完成均值(AVG)、求和(SUM)、最大值(MAX)、最小值(MIN) 等计算
+
+- **隐私求交**：在不暴露参与方私有数据的情况下，实现两个或多个参与方之间的数据交集计算。
+
+- **匿踪查询**：保证用户向数据源方提交查询请求时，在数据源方不知道用户查询条件和结果的前提下完成查询。
+
+- **联邦学习**：一种分布式模型训练技术，在数据不动、模型出域的前提下完成全局模型的训练。
+
+下面是通过命令行发起一个「隐私求交」任务的全过程，`task_config_file` 参数指定配置文件。
+
+```Python
+# 1. 进入容器
+docker exec -it primihub-node0 bash
+# 2. 发起隐私求交任务
+./primihub-cli --task_config_file="example/psi_ecdh_task_conf.json"
+I20230616 13:40:10.683375    28 cli.cc:524] all node has finished
+I20230616 13:40:10.683745    28 cli.cc:598] SubmitTask time cost(ms): 1419
+# 3. 查看结果
+cat data/result/psi_result.csv
+"intersection_row"
+X3
+...
+```
+
+### 3.3 更多配置示例
+
+为了方便用户上手，PrimiHub 在 `example` 目录下，提供了 50 多种隐私计算任务的配置文件，可作为模板快速配置自己的数据源发起任务。
+
+|文件|任务|
+|-|-|
+|[mpc_statistics_sum_task_conf.json](https://github.com/primihub/primihub/blob/develop/example/mpc_statistics_sum_task_conf.json)|联合统计三方求和(SUM)任务|
+|[psi_ecdh_task_conf.json](https://github.com/primihub/primihub/blob/develop/example/psi_ecdh_task_conf.json)|隐私求交求两个集合的交集|
+|[keyword_pir_task_conf.json](https://github.com/primihub/primihub/blob/develop/example/keyword_pir_task_conf.json)|匿踪查询|
+|[hfl_plaintext.json](https://github.com/primihub/primihub/blob/develop/example/FL/linear_regression/hfl_plaintext.json)|线性回归横向联邦明文模式训练|
+|[hfl_paillier.json](https://github.com/primihub/primihub/blob/develop/example/FL/linear_regression/hfl_paillier.json)|线性回归横向联邦同态模式训练|
+|......|[更多配置示例](https://github.com/primihub/primihub/tree/develop/example)|
+
+## 四、应用案例
+
+这里我们将通过在 PrimiHub 管理平台模拟演示一个匿踪查询（隐匿查询）的应用案例：检察院要向公安机关查询张三（身份证号）是否有涉毒记录，但是公安机关不想把全量数据提供给检察院查询，检察院也不想暴露他们当前正在侦查的对象。
+
+上面的场景，双方可以通过 PrimiHub 的**隐匿查询功能**来满足双方需求，实现公安机关看不到检察院的查询，检察院也不用拿到公安机关的全量数据，下面开始操作。
+
+### 4.1 注册并登陆
+
+匿踪查询需要两方以上进行协同，所以需要选择「节点 1：模拟检察院」和「节点 2：模拟公安机关」进行注册。
+
+> 节点 1：[https://node1.primihub.com/#/register](https://node1.primihub.com/#/register)
+
+节点 2：[https://node2.primihub.com/#/register](https://node2.primihub.com/#/register)
+
+![https://img2023.cnblogs.com/blog/759200/202309/759200-20230912173134375-447872231.png](7%20信安/标准/[开源+免费]+一款释放数据价值的项目，开源隐私计算平台+cdc79c72-d449-49ec-b9e7-cea4a9a1654c/759200-20230912173134375-447872231.png)
+
+注册完成后打开两个网页分别登陆，刚模拟注册的检察院和公安机关的账号。
+
+### 4.2 匿踪查询
+
+#### 4.2.1 准备工作
+
+本地准备好待查询的数据如下表，以及查询条件身份证号：110221xxxxx
+
+|姓名|身份证号|籍贯|出生日期|涉赌时间|
+|-|-|-|-|-|
+|张三|110221xxxxx|北京市|...|...|
+|李四|1102211xxxx|北京市|...|...|
+|王二|11022119xxx|北京市|...|...|
+
+#### 4.2.2 上传数据资源
+
+打开「节点 2 」网页（公安机关账号）在「我的资源」点击「添加资源」按钮，将上面表格作为数据资源上传（实际场景中可通过配置数据库进行查询），最后点击保存。
+
+![https://img2023.cnblogs.com/blog/759200/202309/759200-20230912173142667-532651808.png](7%20信安/标准/[开源+免费]+一款释放数据价值的项目，开源隐私计算平台+cdc79c72-d449-49ec-b9e7-cea4a9a1654c/759200-20230912173142667-532651808.png)
+
+#### 4.2.3 新建匿踪查询任务
+
+打开「节点 1 」网页（检查院）在「隐匿查询」发起一次查询任务，在「选择查询资源」处选择上一步模拟公安机关上传的数据资源，最后点击「查询」按钮。
+
+![https://img2023.cnblogs.com/blog/759200/202309/759200-20230912173149146-1332073375.png](7%20信安/标准/[开源+免费]+一款释放数据价值的项目，开源隐私计算平台+cdc79c72-d449-49ec-b9e7-cea4a9a1654c/759200-20230912173149146-1332073375.png)
+
+#### 4.2.4 查看结果
+
+在「节点 1 」网页（检查院）的「隐匿查询」下可以查看上一步创建的「匿踪查询」任务状态，任务运行结束后，点击「导出结果」即可下载结果文件，查看匿踪查询返回的记录。
+
+![https://img2023.cnblogs.com/blog/759200/202309/759200-20230912173158702-715125436.png](7%20信安/标准/[开源+免费]+一款释放数据价值的项目，开源隐私计算平台+cdc79c72-d449-49ec-b9e7-cea4a9a1654c/759200-20230912173158702-715125436.png)
+
+至此，我们就用 PrimiHub 管理平台完成了一次完整的「匿踪查询」任务。模拟了检察院在公安机关提供的涉赌记录数据中，查询目标对象（ 110221xxxxx ）的涉赌信息。**在查询过程中，检察院仅获得查询对象的信息，公安机关也看不到检察院的查询记录，保证了检察院的办案独立性**。
+
+## 五、最后
+
+PrimiHub 是由原语科技开源的隐私计算平台，具有开箱即用、功能丰富、容易上手、灵活配置等特点。
+
+- **开箱即用**：拥有 [Web 界面](https://github.com/primihub/primihub-platform)、[命令行](https://docs.primihub.com/docs/category/%E5%88%9B%E5%BB%BA%E4%BB%BB%E5%8A%A1) 和 [Python SDK](https://docs.primihub.com/docs/category/python-sdk-client) 多种使用方式
+
+- **功能丰富**：支持匿踪查询、隐私求交、联合统计、联合建模、数据资源管理等功能
+
+- **灵活配置**：支持自定义扩展语法、语义、安全协议等
+
+- **自主研发**：多方安全计算、联邦学习、同态加密、可信计算等隐私计算技术
+
+隐私计算作为前沿技术，其开发难度可想而知，开源不易如果体验后觉得 PrimiHub 还不错，就点一个 Star✨ 吧！
+
+> GitHub 地址：[https://github.com/primihub/primihub](https://github.com/primihub/primihub)
+
+在国内外科技巨头纷纷布局隐私计算产业的当下，**花些时间学习一下「隐私计算」属实是波只赚不亏的技术投资**。虽然目前隐私计算受限于性能等因素还远没到普及的程度，但从各国对于隐私保护的重视程度，隐私数据安全合规的使用和流动注定是未来的趋势。相信待时机成熟之时，隐私计算会和现在的大模型一样，迎来属于自己的时代。
+
@@ -0,0 +1,14 @@
+目前透给公网的服务只有一台签名验签服务器。
+
+也有收到协同平台和密码平台透到公网的需求。主要是考虑到以下原因都没有做。
+
+1. 公司网络安全原因，网管不再开放端口，需要施总审批。
+
+2. 缺少应用防火墙，容易被攻击。
+
+3. 网络上行带宽较窄，页面载入缓慢，体验不佳。
+
+4. UKey 模式登录，客户手上没有 UKey 也用不了。
+
+5. 设备资源不足，无常备演示环境服务器/加密机资源。
+
@@ -0,0 +1,85 @@
+**1．祖冲之序列密码算法（GM/T 0001）**
+
+**GM/T 0001-2012《祖冲之序列密码算法》**
+
+本规范包含3个部分：算法描述、基于祖冲之算法的机密件算法、基于祖冲之算法的完整性算法。
+
+第1部分为算法描述，描述了祖冲之序列密码算法，可用于指导祖冲之算法相关产品的研制、检测和使用。本部分主要包括算法整体结构、线性反馈移位寄存器LFSR、比特重组BR、非线性函数F、密钥装入和算法运行内容，并在附录中给出了算法计算实例。
+
+第2部分为基于祖冲之算法的机密性算法，可适用于3GPP LTE通信中的加密和解密，可用于指导基于祖冲之算法的机密性算法的相关产品的研制、检测和使用。本部分主要包括算法输入与输出和算法工作流程内容，并在附录中给出了算法计算实例。
+
+第3部分为基于祖冲之算法的完整性算法，可适用于3GPP LTE通信中消息的完整性保护，可用于指导基于祖冲之算法的完整性算法的相关产品的研制、检测和使用。本部分主要包括算法输入与输出和算法工作流程内容，并在附录中给了算法计算实例。
+
+**2．SM4分组密码算法(GM/T 0002)**
+
+**GM/T 0002-2012 《SM4分组密码算法》**
+
+本规范规定了SM4分组密码算法（原SMS4）的算法结构和算法描述，并给出了运算示例，适用于密码应用中使用分组密码的需求。SM4密码算法是一个分组算法，分组长度为128比特，密钥长度为128比特。加密算法与密钥扩展算法都采用32轮非线性迭代结构，数据解密和数据加密的算法结构相同，只是轮密钥的使用顺序相反，解密轮密钥是加密轮密钥的逆序。
+
+本规范对轮函数F和算法进行了详细的介绍。轮函数F包括轮函数结构和合成置换T，算法描述包括加密算法、解密算法和密钥扩展算法，并在附录中给出了运算示例。
+
+**3．SM2椭圆曲线公钥密码算法（GM/T 0003）**
+
+**GM/T 0003-2012 《SM2椭圈曲线公钥密码算法》**
+
+本规范包括5个部分：总则、数字签名算法、密钥交换协议、公钥加密算法、参数定义。
+
+第1部分为总则，给出了SM2椭圆曲线公钥密码算法涉及的必要数学基础知识与相关密码技术，以帮助实现其他各部分所规定的密码机制，适用于基域为素域和二元扩域的椭圆曲线公钥密码算法。本部分主要包括域和椭圆曲线、数据类型及其转换、椭圆曲线系统参数及其验证、密钥对的生成、公钥的验证等内容，并在附录中给出了椭圆曲线的背景知识、数论算法、曲线示例和椭圆曲线方程参数的拟随机生成及验证。
+
+第2部分为数字签名算法，规定了SM2椭圆曲线公钥密码算法的数字签名算法，包括数字签名生成算法和验证算法，并给出了数字签名与验证示例及其相应的流程，适用于商用密码应用中的数字签名和验证，可满足多种密码应用中的身份认证和数据完整性、真实性的安全需求。本部分主要包括数字签名算法、数字签名的生成算法及流程、数字签名的验证算法及流程等内容，并在附录中给出了数字签名与验证的示例。
+
+第3部分为密钥交换协议，规定了SM2椭圆曲线公钥密码算法的密钥交换协议，并给出了密钥交换与验证示例及其相应的流程。适用于商用密码应用中的密钥交换，可满足通信双方经过两次或三次信息传递过程，计算获取一个由双方共同决定的共享密钥（会话密钥）。本部分主要包括参数与辅助参数、密钥交换协议及流程内容，并在附录中给出了密钥交换及验证示例。
+
+第4部分为公钥加密算法，规定了SM2椭网曲线公钥密码算法的公钥加密算法，并给出了消息加解密示例和相应的流程。适用于国家商用密码应用中的消息加解密，消息发送者可以利用接收者的公钥对消息进行加密，接收者用对应的私钥进行解密，获取消息。本部分主要包括算法参数与辅助函数、加密算法及流程、解密算法及流程等内容并在附录中给出了消息加解密示例。
+
+第5部分为参数定义，规定了SM2椭圆曲线公钥密码算法的曲线参数，并在附录中给出了数字签名签名验签、密钥交换与验证、消息加解密示例。
+
+**4．SM3密码杂凑算法（GM/T 0004）**
+
+**GM/T 0004-2012 《SM3密码杂凑算法》**
+
+该规范规定了SM3密码杂凑算法的计算方法和计算步骤，并给出了运算示
+
+例，适用于商用密码应用中的数字签名和验证、消息认证码的生成与验证以及随机数的生成，可满足多种密码应用的安全需求。同时，本规范还可为安全产品生产商提供产品和技术的标准定位以及标准化的参考，提高安全产品的可信性与互操作性。
+
+SM3算法可概述为：对长度为n(n<2^64)位的消息m，SM3杂凑算法经过填充和迭代压缩，生成杂凑值，杂凑值长度为256位。本规范从算法概述、迭代演练等方式对SM3算法进行描述，并通过具体示例进行剖析展示。
+
+**5．SM2密码算法使用规范（GM/T 0009）**
+
+**GM/T 0009-2012 《SM2密码算法使用规范》**
+
+本规范定义了 SM2密码算法的使用方法，以及密钥、加密与签名等数据格式，适用于SM2密码算法的使用，以及支持SM2密码算法的设备和系统的研发和检测。
+
+本规范介绍了SM2公钥和私钥的数学本质。SM2私钥是一个大于或等于1且小于n-1的整数（n为SM2算法的阶，其值参见GM/T 0003）．简记为k，长度为256位；SM2公钥是SM2曲线上的一个点，由横坐标和纵坐标两个分量来表示，记为(x，y)，简记为Q，每个分量的长度为256位。
+
+本规范介绍了8位字节串和位串之问的转换，包括位串到8位字节串的转换、8位字节串到位串的转换、整数到8位字节串的转换、8位字节串到整数的转换。
+
+本规范介绍了SM2算法的数据格式，包括密钥数据格式、加密数据格式、签名数据格式、密钥对保护数据格式。
+
+本规范还介绍了预处理和计算过程，包括生成密钥、加密、解密、签名、验签和密钥协商。
+
+**6．SM2密码算法加密签名消息语法规范(GM/T 0010)**
+
+**GM/T 0010-2012 (SM2密码算法加密签名消息语法规范)**
+
+本规范定义了使用SM2密码算法的加密签名消息语法，适用于使用SM2算法进行加密和签名操作时对操作结果的标准化封装。
+
+本规范对6类对象 data，signedData，envelopedData，encryptedData，
+
+keyAgreementInfo和SignedAndEnvelopedData的标识符进行了定义。
+
+
+
+|||
+|-|-|
+|对象标识符OID|对象标识符定义|
+|1.2.156.10197.6.1.4.2|SM2密码算法加密签名消息语法规范|
+|1.2.156.10197.6.1.4.2.1|数据类型data|
+|1.2.156.10197.6.1.4.2.2|签名数据类型signedData|
+|1.2.156.10197.6.1.4.2.3|数字信封数据类型envelopedData|
+|1.2.156.10197.6.1.4.2.4|签名及数字信封数据类型signedAndEnvelopedData|
+|1.2.156.10197.6.1.4.2.5|加密数据类型encryptedData|
+|1.2.156.10197.6.1.4.2.6|密钥协商类型keyAgreementInfo|
+
+1.2.156.10197.1.301 (sm4-cbc)
+1.2.156.10197.1.301.1
@@ -0,0 +1,34 @@
+RFC定义的oid如下：
+
+数据类型data 1 2 840 113549 1 7 1
+
+签名数据类型signedData 1 2 840 113549 1 7 2
+
+数字信封数据类型envelopedData 1 2 840 113549 1 7 3
+
+签名及数字信封数据类型signedAndEnvelopedData 1 2 840 113549 1 7 4
+
+摘要数据类型digestData 1 2 840 113549 1 7 5
+
+加密数据类型encryptedData 1 2 840 113549 1 7 6
+
+
+
+
+
+
+
+国密标准GM/T 0010定义的oid如下：
+
+数据类型data 1.2.156.10197.6.1.4.2.1
+
+签名数据类型signedData 1.2.156.10197.6.1.4.2.2
+
+数字信封数据类型envelopedData 1.2.156.10197.6.1.4.2.3
+
+签名及数字信封数据类型signedAndEnvelopedData 1.2.156.10197.6.1.4.2.4
+
+加密数据类型encryptedData 1.2.156.10197.6.1.4.2.5
+
+密钥协商类型keyAgreementInfo 1.2.156.10197.6.1.4.2.6
+
@@ -0,0 +1,2 @@
+
+
@@ -0,0 +1,212 @@
+[https://blog.csdn.net/m0_50180963/article/details/113061162](https://blog.csdn.net/m0_50180963/article/details/113061162)
+
+HTTPS 常用的密钥交换算法有两种，分别是 RSA 和 ECDHE 算法。
+
+其中，RSA 是比较传统的密钥交换算法，它不具备前向安全的性质，因此现在很少服务器使用的。而 ECDHE 算法具有前向安全，所以被广泛使用。
+
+我在上一篇已经介绍了 RSA 握手的过程，今天这一篇就「从理论再到实战抓包」介绍 **ECDHE 算法**。
+
+![475ad007571fec673a9712a7c865849d.png](7%20信安/标准/图解+ECDHE+密钥交换算法+118cb81b-7cb1-471e-9fc2-ccfd0897265d/475ad007571fec673a9712a7c865849d.png)
+
+---
+
+# 离散对数
+
+ECDHE 密钥协商算法是 DH 算法演进过来的，所以我们先从 DH 算法说起。
+
+DH 算法是非对称加密算法， 因此它可以用于密钥交换，该算法的核心数学思想是**离散对数**。
+
+是不是听到这个数学概念就怂了？不怕，这次不会说离散对数推到的过程，只简单提一下它的数学公式。
+
+离散对数是「离散 + 对数」的两个数学概念的组合，所以我们先来复习一遍对数。
+
+要说起对数，必然要说指数，因为它们是互为反函数，指数就是幂运算，对数是指数的逆运算。
+
+举个栗子，如果以 2 作为底数，那么指数和对数运算公式，如下图所示：
+
+![12b51d7318811cd137dfca72ae5923b4.png](7%20信安/标准/图解+ECDHE+密钥交换算法+118cb81b-7cb1-471e-9fc2-ccfd0897265d/12b51d7318811cd137dfca72ae5923b4.png)
+
+那么对于底数为 2 的时候， 32 的对数是 5，64 的对数是 6，计算过程如下：
+
+![0eebc01157e5458afb98b84162f89ee6.png](7%20信安/标准/图解+ECDHE+密钥交换算法+118cb81b-7cb1-471e-9fc2-ccfd0897265d/0eebc01157e5458afb98b84162f89ee6.png)
+
+对数运算的取值是可以连续的，而离散对数的取值是不能连续的，因此也以「离散」得名，
+
+离散对数是在对数运算的基础上加了「模运算」，也就说取余数，对应编程语言的操作符是「%」，也可以用 mod 表示。离散对数的概念如下图：
+
+![2cd0c0fbd0a759611b4abad5fe414922.png](7%20信安/标准/图解+ECDHE+密钥交换算法+118cb81b-7cb1-471e-9fc2-ccfd0897265d/2cd0c0fbd0a759611b4abad5fe414922.png)
+
+上图的，底数 a 和模数 p 是离散对数的公共参数，也就说是公开的，b 是真数，i 是对数。知道了对数，就可以用上面的公式计算出真数。但反过来，知道真数却很难推算出对数。
+
+**特别是当模数 p 是一个很大的质数，即使知道底数 a 和真数 b ，在现有的计算机的计算水平是几乎无法算出离散对数的，这就是 DH 算法的数学基础。**
+
+---
+
+# DH 算法
+
+认识了离散对数，我们来看看 DH 算法是如何密钥交换的。
+
+现假设小红和小明约定使用 DH 算法来交换密钥，那么基于离散对数，小红和小明需要先确定模数和底数作为算法的参数，这两个参数是公开的，用 P 和 G 来代称。
+
+然后小红和小明各自生成一个随机整数作为**私钥**，双方的[私钥](https://so.csdn.net/so/search?q=%E7%A7%81%E9%92%A5&spm=1001.2101.3001.7020)要各自严格保管，不能泄漏，小红的私钥用 a 代称，小明的私钥用 b 代称。
+
+现在小红和小明双方都有了 P 和 G 以及各自的私钥，于是就可以计算出**公钥**：
+
+- 小红的公钥记作 A，A = G ^ a ( mod P )；
+
+- 小明的公钥记作 B，B = G ^ b ( mod P )；
+
+A 和 B 也是公开的，因为根据离散对数的原理，从真数（A 和 B）反向计算对数 a 和 b 是非常困难的，至少在现有计算机的计算能力是无法破解的，如果量子计算机出来了，那就有可能被破解，当然如果量子计算机真的出来了，那么密钥协商算法就要做大的升级了。
+
+双方交换各自 DH 公钥后，小红手上共有 5 个数：P、G、a、A、B，小明手上也同样共有 5 个数：P、G、b、B、A。
+
+然后小红执行运算： B ^ a ( mod P )，其结果为 K，因为离散对数的幂运算有交换律，所以小明执行运算： A ^ b ( mod P )，得到的结果也是 K。
+
+![b5caa905be6878ae9583f5a1e1d4f3e7.png](7%20信安/标准/图解+ECDHE+密钥交换算法+118cb81b-7cb1-471e-9fc2-ccfd0897265d/b5caa905be6878ae9583f5a1e1d4f3e7.png)
+
+这个 K 就是小红和小明之间用的**对称加密密钥**，可以作为会话密钥使用。
+
+可以看到，整个密钥协商过程中，小红和小明公开了 4 个信息：P、G、A、B，其中 P、G 是算法的参数，A 和 B 是公钥，而 a、b 是双方各自保管的私钥，黑客无法获取这 2 个私钥，因此黑客只能从公开的 P、G、A、B 入手，计算出离散对数（私钥）。
+
+前面也多次强调， 根据离散对数的原理，如果 P 是一个大数，在现有的计算机的计算能力是很难破解出 私钥 a、b 的，破解不出私钥，也就无法计算出会话密钥，因此 DH 密钥交换是安全的。
+
+---
+
+# DHE 算法
+
+根据私钥生成的方式，DH 算法分为两种实现：
+
+- static DH 算法，这个是已经被废弃了；
+
+- DHE 算法，现在常用的；
+
+static DH 算法里有一方的私钥是静态的，也就说每次密钥协商的时候有一方的私钥都是一样的，一般是服务器方固定，即 a 不变，客户端的私钥则是随机生成的。
+
+于是，DH 交换密钥时就只有客户端的公钥是变化，而服务端公钥是不变的，那么随着时间延长，黑客就会截获海量的密钥协商过程的数据，因为密钥协商的过程有些数据是公开的，黑客就可以依据这些数据暴力破解出服务器的私钥，然后就可以计算出会话密钥了，于是之前截获的加密数据会被破解，所以 **static DH 算法不具备前向安全性**。
+
+既然固定一方的私钥有被破解的风险，那么干脆就让双方的私钥在每次密钥交换通信时，都是随机生成的、临时的，这个方式也就是 DHE 算法，E 全称是 ephemeral（临时性的）。
+
+所以，即使有个牛逼的黑客破解了某一次通信过程的私钥，其他通信过程的私钥仍然是安全的，因为**每个通信过程的私钥都是没有任何关系的，都是独立的，这样就保证了「前向安全」**。
+
+---
+
+# ECDHE 算法
+
+DHE 算法由于计算性能不佳，因为需要做大量的乘法，为了提升 DHE 算法的性能，所以就出现了现在广泛用于密钥交换算法 —— **ECDHE 算法**。
+
+ECDHE 算法是在 DHE 算法的基础上利用了 ECC 椭圆曲线特性，可以用更少的计算量计算出公钥，以及最终的会话密钥。
+
+小红和小明使用 ECDHE 密钥交换算法的过程：
+
+- 双方事先确定好使用哪种椭圆曲线，和曲线上的基点 G，这两个参数都是公开的；
+
+- 双方各自随机生成一个随机数作为**私钥d**，并与基点 G相乘得到**公钥Q**（Q = dG），此时小红的公私钥为 Q1 和 d1，小明的公私钥为 Q2 和 d2；
+
+- 双方交换各自的公钥，最后小红计算点（x1，y1） = d1Q2，小明计算点（x2，y2） = d2Q1，由于椭圆曲线上是可以满足乘法交换和结合律，所以 d1Q2 = d1d2G = d2d1G = d2Q1 ，因此**双方的 x 坐标是一样的，所以它是共享密钥，也就是会话密钥**。
+
+这个过程中，双方的私钥都是随机、临时生成的，都是不公开的，即使根据公开的信息（椭圆曲线、公钥、基点 G）也是很难计算出椭圆曲线上的离散对数（私钥）。
+
+---
+
+# ECDHE 握手过程
+
+知道了 ECDHE 算法基本原理后，我们就结合实际的情况来看看。
+
+我用 Wireshark 工具抓了用 ECDHE 密钥协商算法的 TSL 握手过程，可以看到是四次握手：
+
+![1388d63cad1194b30265d7d580c8bcbe.png](7%20信安/标准/图解+ECDHE+密钥交换算法+118cb81b-7cb1-471e-9fc2-ccfd0897265d/1388d63cad1194b30265d7d580c8bcbe.png)
+
+细心的小伙伴应该发现了，**使用了 ECDHE，在 TLS 第四次握手前，客户端就已经发送了加密的 HTTP 数据**，而对于 RSA 握手过程，必须要完成 TLS 四次握手，才能传输应用数据。
+
+所以，**ECDHE 相比 RSA 握手过程省去了一个消息往返的时间**，这个有点「抢跑」的意思，它被称为是「*TLS False Start*」，跟「*TCP Fast Open*」有点像，都是在还没连接完全建立前，就发送了应用数据，这样便提高了传输的效率。
+
+接下来，分析每一个 ECDHE 握手过程。
+
+# TLS 第一次握手
+
+客户端首先会发一个「**Client Hello**」消息，消息里面有客户端使用的 TLS 版本号、支持的密码套件列表，以及生成的**随机数（*Client Random*）**。
+
+![bb4702545feaa89e55d8cfc6b92f6257.png](7%20信安/标准/图解+ECDHE+密钥交换算法+118cb81b-7cb1-471e-9fc2-ccfd0897265d/bb4702545feaa89e55d8cfc6b92f6257.png)
+
+# TLS 第二次握手
+
+服务端收到客户端的「打招呼」，同样也要回礼，会返回「**Server Hello**」消息，消息面有服务器确认的 TLS 版本号，也给出了一个**随机数（*Server Random*）**，然后从客户端的密码套件列表选择了一个合适的密码套件。
+
+![a025211621416e7ad174fd54bb0fa3ca.png](7%20信安/标准/图解+ECDHE+密钥交换算法+118cb81b-7cb1-471e-9fc2-ccfd0897265d/a025211621416e7ad174fd54bb0fa3ca.png)
+
+不过，这次选择的密码套件就和 RSA 不一样了，我们来分析一下这次的密码套件的意思。
+
+「 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384」
+
+- 密钥协商算法使用 ECDHE；
+
+- 签名算法使用 RSA；
+
+- 握手后的通信使用 AES 对称算法，密钥长度 256 位，分组模式是 GCM；
+
+- 摘要算法使用 SHA384；
+
+接着，服务端为了证明自己的身份，发送「**Certificate**」消息，会把证书也发给客户端。
+
+![d1537dfb240125c2cf088cda12cb7f16.png](7%20信安/标准/图解+ECDHE+密钥交换算法+118cb81b-7cb1-471e-9fc2-ccfd0897265d/d1537dfb240125c2cf088cda12cb7f16.png)
+
+这一步就和 RSA 握手过程有很大到区别了，因为服务端选择了 ECDHE 密钥协商算法，所以会在发送完证书后，发送「**Server Key Exchange**」消息。
+
+![ac636d19c58867ecbfe341739f2212de.png](7%20信安/标准/图解+ECDHE+密钥交换算法+118cb81b-7cb1-471e-9fc2-ccfd0897265d/ac636d19c58867ecbfe341739f2212de.png)
+
+这个过程服务器做了三件事：
+
+- 选择了**名为 named_curve 的椭圆曲线**，选好了椭圆曲线相当于椭圆曲线基点 G 也定好了，这些都会公开给客户端；
+
+- 生成随机数作为服务端椭圆曲线的私钥，保留到本地；
+
+- 根据基点 G 和私钥计算出**服务端的椭圆曲线公钥**，这个会公开给客户端。
+
+为了保证这个椭圆曲线的公钥不被第三方篡改，服务端会用 RSA 签名算法给服务端的椭圆曲线公钥做个签名。
+
+随后，就是「**Server Hello Done**」消息，服务端跟客户端表明：“这些就是我提供的信息，打招呼完毕”。
+
+![f4be9207366b4c5260d2fccd4c749cf3.png](f4be9207366b4c5260d2fccd4c749cf3.png)
+
+至此，TLS 两次握手就已经完成了，目前客户端和服务端通过明文共享了这几个信息：**Client Random、Server Random 、使用的椭圆曲线、椭圆曲线基点 G、服务端椭圆曲线的公钥**，这几个信息很重要，是后续生成会话密钥的材料。
+
+# TLS 第三次握手
+
+客户端收到了服务端的证书后，自然要校验证书是否合法，如果证书合法，那么服务端到身份就是没问题的。校验证书到过程，会走证书链逐级验证，确认证书的真实性，再用证书的公钥验证签名，这样就能确认服务端的身份了，确认无误后，就可以继续往下走。
+
+客户端会生成一个随机数作为客户端椭圆曲线的私钥，然后再根据服务端前面给的信息，生成**客户端的椭圆曲线公钥**，然后用「**Client Key Exchange**」消息发给服务端。
+
+![c1bd87df595152b55b29e12befb6d689.png](7%20信安/标准/图解+ECDHE+密钥交换算法+118cb81b-7cb1-471e-9fc2-ccfd0897265d/c1bd87df595152b55b29e12befb6d689.png)
+
+至此，双方都有对方的椭圆曲线公钥、自己的椭圆曲线私钥、椭圆曲线基点 G。于是，双方都就计算出点（x，y），其中 x 坐标值双方都是一样的，前面说 ECDHE 算法时候，说 x 是会话密钥，**但实际应用中，x 还不是最终的会话密钥**。
+
+还记得 TLS 握手阶段，客户端和服务端都会生成了一个随机数传递给对方吗？
+
+**最终的会话密钥，就是用「客户端随机数 + 服务端随机数 + x（ECDHE 算法算出的共享密钥） 」三个材料生成的**。
+
+之所以这么麻烦，是因为 TLS 设计者不信任客户端或服务器「伪随机数」的可靠性，为了保证真正的完全随机，把三个不可靠的随机数混合起来，那么「随机」的程度就非常高了，足够让黑客计算出最终的会话密钥，安全性更高。
+
+算好会话密钥后，客户端会发一个「**Change Cipher Spec**」消息，告诉服务端后续改用对称算法加密通信。
+
+![380f119a8b73e5dbbed2c477eacec61b.png](380f119a8b73e5dbbed2c477eacec61b.png)
+
+接着，客户端会发「**Encrypted Handshake Message**」消息，把之前发送的数据做一个摘要，再用对称密钥加密一下，让服务端做个验证，验证下本次生成的对称密钥是否可以正常使用。
+
+![7e28bf39c00923ed3d5fe6f4a67bc796.png](7e28bf39c00923ed3d5fe6f4a67bc796.png)
+
+# TLS 第四次握手
+
+最后，服务端也会有一个同样的操作，发「**Change Cipher Spec**」和「**Encrypted Handshake Message**」消息，如果双方都验证加密和解密没问题，那么握手正式完成。于是，就可以正常收发加密的 HTTP 请求和响应了。
+
+---
+
+# 总结
+
+RSA 和 ECDHE 握手过程的区别：
+
+- RSA 密钥协商算法「不支持」前向保密，ECDHE 密钥协商算法「支持」前向保密；
+
+- 使用了 RSA 密钥协商算法，TLS 完成四次握手后，才能进行应用数据传输，而对于 ECDHE 算法，客户端可以不用等服务端的最后一次 TLS 握手，就可以提前发出加密的 HTTP 数据，节省了一个消息的往返时间；
+
+- 使用 ECDHE， 在 TLS 第 2 次握手中，会出现服务器端发出的「Server Key Exchange」消息，而 RSA 握手过程没有该消息；
+
@@ -0,0 +1,24 @@
+*AES*-*GCM* 是基于 AES-CTR
+
+[https://zhuanlan.zhihu.com/p/376692295](https://zhuanlan.zhihu.com/p/376692295)
+
+
+
+
+
+高可用计算公式
+
+可用性
+
+故障率
+
+
+
+项目遇阻
+
+
+
+
+
+
+
@@ -0,0 +1,2 @@
+
+
@@ -0,0 +1,4 @@
+GCM 是在 CTR 模式的基础上，增加了认证操作的分组模式。
+
+
+
@@ -0,0 +1,4 @@
+- 缺乏专业人员。人力缺少导致设计、开发、文档工作量压缩，以及质量下降。改进措施：安排对应的支持岗位，培训专业支持人员。
+
+- 测试不足。缺少人力和环境导致测试不足，现场调整耗时。改进措施：搭建对应的测试环境，以及自动化测试工具，提高人效。
+
@@ -0,0 +1,22 @@
+风险应对办法：规避、减轻、转嫁、接受
+
+
+
+测试方面需要 ： 功能测试、压力测试、安全测试和场景对比测试
+
+
+
+安全测试包括：身份认证安全、口令安全、访问权限安全、会话管理安全、通信安全、业务逻辑安全、输入数据安全、存储数据安全、提示信息安全、日志数据安全、算法安全、安全审计、配置安全、拒绝服务、源代码数据安全、架构安全、运行环境安全、安全卸载安全、组件安全、权限安全、第三方库安全（若涉及）等。
+
+
+
+场景对比测试：对比改造前后的使用体验、延迟变化，分析和评估对用户应用操作和实际体验的影响。
+
+
+
+上线方案需要有这些要素：测试方案、上线策略、部署方案、上线实施和回退方案
+
+
+
+
+
@@ -0,0 +1,34 @@
+RFC定义的oid如下：
+
+数据类型data 1 2 840 113549 1 7 1
+
+签名数据类型signedData 1 2 840 113549 1 7 2
+
+数字信封数据类型envelopedData 1 2 840 113549 1 7 3
+
+签名及数字信封数据类型signedAndEnvelopedData 1 2 840 113549 1 7 4
+
+摘要数据类型digestData 1 2 840 113549 1 7 5
+
+加密数据类型encryptedData 1 2 840 113549 1 7 6
+
+
+
+
+
+
+
+国密标准GM/T 0010定义的oid如下：
+
+数据类型data 1.2.156.10197.6.1.4.2.1
+
+签名数据类型signedData 1.2.156.10197.6.1.4.2.2
+
+数字信封数据类型envelopedData 1.2.156.10197.6.1.4.2.3
+
+签名及数字信封数据类型signedAndEnvelopedData 1.2.156.10197.6.1.4.2.4
+
+加密数据类型encryptedData 1.2.156.10197.6.1.4.2.5
+
+密钥协商类型keyAgreementInfo 1.2.156.10197.6.1.4.2.6
+
@@ -0,0 +1,30 @@
+### 流程
+
+```mermaid
+graph LR
+A(提交材料) 
+-->B[认证受理通过]
+-->F(认证通过)
+```
+
+### 提交材料
+- 用印
+	- [x] 认证委托材料 （章x1） （法人代表签字）
+	- [x] 认证委托材料一致性承诺 （章x1）
+	- [x] 生产一致性承诺书（章x1）
+- 在线提交材料记录
+
+![[Pasted image 20231218144946.png]]
+
+
+
+
+![[Pasted image 20231218145015.png]]
+
+![[Pasted image 20231218145111.png]]
+
+![[Pasted image 20231218151744.png]]
+
+![[Pasted image 20231218152754.png]]
+
+
@@ -0,0 +1,129 @@
+---
+title: "基于海光CPU内置安全处理器的可信计算解决方案 - 四川省密码行业协会"
+source: "https://www.schcia.org.cn/488/17068/746801"
+author:
+published:
+created: 2025-10-13
+description: "秘书处"
+tags:
+  - "clippings"
+---
+产品展示
+
+基于海光CPU内置安全处理器的可信计算解决方案
+
+2021-02-23 10:25:32
+
+**摘要：** 基于内置安全处理器和国密算法硬件加速模块,海光CPU实现了TPCM可信计算平台，能够支持可信计算3.0。TPCM作为可信计算底层硬件基础实现了可信计算的三个基本信任根，包括可信度量根、可信存储根和可信报告根。可信计算实际上是密码运算密集型技术。海光CPU的TPCM可信计算平台完全支持国密标准，支持SM2加解密、SM3杂凑、SM4加解密、秘钥协商及签名验签等算法。
+
+**关键词：** 可信计算、安全处理器、 TPCM、国密应用
+
+## 1\. 概述
+
+### 1.1 背景
+
+随着云计算，互联网金融，大数据技术的快速发展，计算机信息安全的重要性正日益为人们所重视。传统的安全防护机制主要是入侵检测、病毒查杀等基于 “封堵查杀”的“被动防御”，主要原理是通过提取病毒木马等恶意代码的特征数据建立特征数据库，然后利用特征数据库进行恶意软件的判定。特征数据库是恶意软件的“黑名单”。由于特征数据库是基于现有代码建立的，只对已知病毒木马有效，而对变异后或新出现的恶意软件无效。另一方面，病毒木马传播快、隐蔽性高，从生成、被发现、到提出安全修补方案期间，成千上万的系统可能已经受到感染，损失已经造成。这种安全防护上的迟滞性是传统安全机制的一个天生缺陷。，必须从源头上分析，以系统化的方式让计算机系统具有自我保护的免疫功能，才能从根本上解决计算机安全问题，扭转安全防护的被动局面。
+
+可信计算是一种与传统安全机制有着本质不同的安全防护机制，克服了传统安全机制故有的迟滞性缺陷，在系统安全保护上具有明显的优势。可信计算通过监视系统运行状况，自动识别自我和非我，从而对恶意程序及时做出响应，阻断其运行。
+
+### 1.2 目标
+
+可信计算是以密码为基础的技术，大量运用到了密码学中的加密解密、签名验签、秘钥交换、秘钥推导、散列等密码运算。可信计算也是一个体系，由底层的可信硬件及上层的可信软件构成。底层硬件是可信计算的基础和载体，是实现可信计算需要的信任根，上层的软件是可信的延伸和扩展，实现各种可信的功能和应用。
+
+海光 CPU内置了安全处理器，用于实现可信计算所需的底层硬件功能。海光可信计算方案实现如下设计目标：
+
+●实现所有的三个基本信任根：度量根，存储根，报告根；
+
+●满足可信计算3.0的要求，支持主动防御；
+
+●密码技术全部使用中国国密标准；
+
+●提供专用硬件模块为密码运算提供高效加速；
+
+●技术国产化，自主可控。
+
+## 2\. 需求分析
+
+### 2.1 现状分析
+
+传统的可信计算方案通常使用单独的安全芯片为可信硬件基础。安全芯片放置在主板上，与 CPU通过总线连接。传统方案增加了额外硬件成本，同时加大了主板硬件设计的复杂度，对主板上电时序和固件设计提出了更高要求。
+
+### 2.2 需求分析
+
+目前常见的可信计算方案国际上有基于 TPM的，国内有基于TCM、TPCM的。TPM/TCM方案较为类似，都是实现可信调用库供上层软件使用，属于被动服务模式。由于出现时间较早，得到了较广应用，但形式单一，某些重要的可信功能并未实现，如可信度量根。TPCM是面向中国可信计算3.0的技术方案，弥补了传统TPM/TCM的不足，增加了更多主动防御和控制功能，是未来可信计算的技术趋势。海光CPU内置专用安全硬件，安全操作与运行环境无缝衔接，可以更加高效地实现可信计算系统。
+
+  
+
+## 3\. 方案架构
+
+### 3.1 技术架构
+
+方案硬件上由 x86主CPU、芯片内置的安全处理器及国密硬件引擎组成。软件由TPCM模块、TPCM驱动、可信软件基和可信应用组成，如图1所示。
+
+![https://scmmhyxh.saas.xiebanyun.com/uploads/20220308/8a7ec536b9d5a504be7690e6188dae95.jpg](https://scmmhyxh.saas.xiebanyun.com/uploads/20220308/8a7ec536b9d5a504be7690e6188dae95.jpg "file_upload")
+
+图 1. 基于海光CPU的可信计算系统架构
+
+安全处理器实现可信根及 TPCM的相关标准功能。国密硬件引擎CCP为安全处理器上密码运算提供加速，实现高效国密运算。x86主CPU上运行上层可信软件，并通过专用的硬件接口与安全处理器进行通信。TPCM模块实现了存储、报告、度量、控制等基础可信功能，运行在安全处理器内部，外部无法直接访问或篡改，具有极高的安全性，因此是整个可信架构可信的基础。TPCM驱动运行于x86主CPU上，向上提供统一的TPCM命令访问接口，屏蔽具体的底层硬件接口信息。可信软件基实现相关的可信功能模块，包括静态度量，动态度量，可信报告，可信连接等，通常位于操作系统内核层。可信应用通常位于用户层，提供具体的可信功能，如可信管理平台等。
+
+### 3.2 部署说明
+
+目前硬件部分已经完全集成在海光 CPU内部，不需要特殊部署。实际应用系统，只要安装配套的驱动程序和应用程序函数库即可。
+
+  
+
+### 3.3 主要功能
+
+#### 3.3.1 可信度量
+
+度量在原理上就是提取目标的特征值，特征值具有唯一性，因而通过特征值能够准确判断目标的状态信息。方案中度量通过计算目标 Hash值实现，Hash使用SM3国密算法。通过比较目标Hash计算值与预期值可以判断目标是否发生篡改。
+
+![https://scmmhyxh.saas.xiebanyun.com/uploads/20220308/fa5ebc94f601592e83494c9f86da7a7e.jpg](https://scmmhyxh.saas.xiebanyun.com/uploads/20220308/fa5ebc94f601592e83494c9f86da7a7e.jpg "file_upload")
+
+图 2. 可信度量流程
+
+度量分为启动度量和运行时动态度量。如图 2所示，方案在系统启动时进行启动度量，在系统启动的各个阶段对下一级目标进行度量并验证，只有验证通过才会加载执行，这样一级验证一级建立系统启动的信任链。信任链的源头决定整条信任链的可靠性，海光安全处理器内固化的初始代码是信任链的源头，初始代码一旦生成无法修改，保证了源头的绝对安全。除了启动度量，方案在系统运行时还可以对设定的目标进行持续的动态度量，在检测到异常时进行告警，实现对外部病毒、恶意代码等的主动防御，保证系统的运行时安全。
+
+#### 3.3.2 可信存储
+
+可信存储确保存储数据的安全，数据未授权不可被访问，更不可被篡改。海光安全处理器内部为可信存储提供了易失存储和非易失存储。易失存储具有访问快速特点，但掉电即丢失，用来存储临时需要保存的数据。非易失存储掉电不丢失，用来保存长期数据。安全处理器内部可信存储的空间大小有限，当要存储的数据较大时，可以将数据进行加密后存在外部存储设备上，而将加密的密钥存在安全处理器内部，如图 3所示，进而逻辑上扩展了可信存储的范围。加密使用国密算法，加密的根密钥就是可信存储的存储信任根。
+
+![https://scmmhyxh.saas.xiebanyun.com/uploads/20220308/ccdd532650c73abde0df876d2e1e2b9e.jpg](https://scmmhyxh.saas.xiebanyun.com/uploads/20220308/ccdd532650c73abde0df876d2e1e2b9e.jpg "file_upload")
+
+图 3. 可信存储图
+
+#### 3.3.3 可信报告
+
+安全处理器内部收集了大量系统的运行时信息，比如度量信息，审计信息等，准确的获取这些信息对系统健康状态的判定非常关键。在对外提供这些信息时，为了防止中间对信息的恶意篡改和攻击，必须对信息进行保护。通过对信息签名实现对信息的保护，签名使用 SM2国密算法，经过签名后的信息形成了可信报告，可信报告可通过网络提供给远程的可信管理中心。管理中心首先验证报告签名确认报告的真实性，然后通过报告内容可以获知报告的相关信息，进而为相关判定决策提供可靠依据。
+
+### 3.4 技术指标
+
+可信计算的实现需要大量的密码运算，安全处理器内提供了专用的密码运算引擎 CCP，为各类型密码运算提供硬件加速。基于CCP的性能指标如下：
+
+![https://scmmhyxh.saas.xiebanyun.com/uploads/20220308/96f92f60d6093152cff2d2a502030ad9.jpg](https://scmmhyxh.saas.xiebanyun.com/uploads/20220308/96f92f60d6093152cff2d2a502030ad9.jpg "file_upload")
+
+### 3.5 关键技术
+
+#### 3.5.1 密码技术
+
+可信计算是密码运算密集型技术，综合用到了对称、非对称、 Hash等密码算法，对称密码用来进行加解密及计算消息验证码HMAC，非对称密码用来进行签名验签及共享秘钥生成等，Hash用来度量及签名等。所有密码运算使用国密标准，而且海光CPU同时内置了国密硬件引擎CCP，实现了简洁高效的密码运算。
+
+#### 3.5.2 CPU内置安全处理器的芯片架构
+
+海光 CPU内置了专用的安全处理器，安全处理器具有下述特点：a)拥有自己独立的资源，外部不可访问；b)系统管理者角色，拥有最高系统优先级，可以访问所有的系统资源；c)系统上电时先于x86核心启动，对系统进行可信验证，完成后运行x86核心。安全处理器的这些特点使得在CPU内部实现各种安全应用成为可能，并克服传统实现的某些不足，具备独特优势。
+
+## 4\. 方案特色
+
+利用 CPU内置安全处理器对可信计算做了相关支持，相比传统方案具有如下优势：
+
+●密码运算全面支持国密标准，且提供硬件加速，密码运算更高效；
+
+●无需主板硬件支持，通用性强，且无额外硬件成本；
+
+●安全处理器具有高系统权限，可以对系统进行全面控制，实现可信计算3.0要求的主动防御目标；
+
+●功能内置于CPU，有效抵抗外部物理攻击。
+
+## 5\. 适用领域
+
+可信计算有着日益广泛的应用，尤其是等保 2.0标准的推出使得可信计算成为信息系统保护的一个强需求。本方案支持可信计算3.0，满足等保2.0对可信计算的最高需求，可以应用在有信息系统安全保护需求的各领域，如金融、政企办公、云服务平台等。
@@ -0,0 +1 @@
+https://zhuanlan.zhihu.com/p/12427808438
@@ -0,0 +1,3 @@
+国密老师在《安全性自评估》中批注：
+
+分组密码、非对称密码算法和技术、消息鉴别码、杂凑函数、实体鉴别、密钥管理、随机比特生成器。
@@ -0,0 +1,5 @@
+算法正确性
+软件固件完整性
+认证与授权
+数据传输安全，存储安全
+安全审计
@@ -0,0 +1 @@
+混合软件模块：软件运行环境所包含的计算平台和操作系统，在定义的混合软件模块边界之外。
@@ -0,0 +1,135 @@
+## **一、国家基本法中对数据加密的要求**
+
+首先，我们来看由全国人民代表大会常务委员会发布的基本法，这些法律构成了整个数据安全法律体系的基础框架。
+
+**第一部分：基本法**
+
+**《网络安全法》****（2017.6.1实施）**
+
+**【相关条款】**第二十一条  网络运营者应当按照网络安全等级保护制度的要求，履行下列安全保护义务。采取数据分类、重要数据备份和**加密**等措施。
+
+**【要点】**明确了数据分类、备份、加密，以及其他“等”措施。
+
+**《数据安全法》（2021.9.1实施）**
+
+**【相关条款】**第二十七条  开展数据处理活动…，**采取相应的技术措施和其他必要措施**，保障数据安全。利用互联网等信息网络开展数据处理活动，应当在**网络安全等级保护制度的基础上**，履行上述数据安全保护义务。
+
+**【要点】**该条明确等保要求是基础义务，等保中对数据加密有明确要求。
+
+**《密码法》（2020.1.1实施）**
+
+**【相关条款】**第二十七条　法律、行政法规和国家有关规定要求**使用商用密码进行保护的关键信息基础设施，其运营者应当使用商用密码进行保护**，自行或者委托商用密码检测机构开展商用密码应用安全性评估。
+
+**【要点】**该条明确要求使用商用密码保护关基设施。
+
+**《个人信息保护法》（2021.11.1实施）**
+
+**【相关条款】**第五十一条　个人信息处理者应当根据个人信息的处理目的……防止未经授权的访问以及个人信息泄露、篡改、丢失；采取相应的**加密**、去标识化等安全技术措施。
+
+**【要点】**该条明确加密、去标识化，其他技术在“等”里面。
+
+在上述四个基本法中，除了《数据安全法》以外，其他三个基本法中都明确指出了对加密的技术要求。特别是在《个人信息保护法》中，甚至将加密的要求放在了第一位。在《数据安全法》中，明确要求在网络安全等级保护制度的基础上，采取相应的技术措施和其他必要措施。这是一个相对笼统的要求，但是从后文中可以看到，等级保护又明确了采用加密技术保护数据的要求。所以，在上述基本法中，全部都明确了对数据加密的保护要求。
+
+## **二、国家级行政法中对数据加密的要求**
+
+接下来，我们将关注由国务院颁布的两个基本条例。
+
+**第二部分：国家法规**
+
+**《关键信息基础设施安全保护条例》（2021.9.1实施）**
+
+**【相关条款】**第六条  运营者……在网络安全等级保护的基础上，采取技术保护措施和其他必要措施，应对网络安全事件，防范网络攻击和违法犯罪活动，保障关键信息基础设施安全稳定运行，维护数据的完整性、**保密性**和可用性。**【要点】**该条明确等保要求是基础义务，并明确了对数据保密性的要求。
+
+**《网络数据安全管理条例》（2025.1.1起实施）**
+
+**【相关条款】**第九条　网络数据处理者应当依照法律、行政法规的规定和国家标准的强制性要求……采取**加密**、备份、访问控制、安全认证等技术措施和其他必要措施，保护网络数据免遭篡改、破坏、泄露或者非法获取、非法利用，处置网络数据安全事件。
+
+**【要点】**明确了数据分类、备份、加密，以及其他“等”措施。
+
+在上述两个基本法中，《关键信息基础设施安全保护条例》没有直接明确技术措施，但是明确了在等保基础上，维护数据的保密性，这其实就是指数据的加密保护。而在《网络数据安全管理条例》中，十分明确地指出了加密的要求，而且是放在了第一位，可见其重要性。
+
+## **三、国家级标准中对数据加密的要求**
+
+接下来，我们将查看国家标准中对企业及组织的数据加密要求。
+
+**第三部分：国家标准**
+
+**《GB/T 25070-2019 信息安全技术 网络安全等级保护安全设计技术要求》（2019.12.1实施）**
+
+**【发布机构】**全国信息安全标准化技术委员会
+
+**【相关条款】**对于第三级（8.3.1.1）、第四级（9.3.1.1）系统安全保护，要求……应**采用密码等技术**支持的完整性校验机制，检验存储和处理的用户数据的完整性，以发现其完整性是否被破坏，且在其受到破坏时能对重要数据进行恢复；用户数据保密性保护采用密码等技术支持的保密性保护机制，对在安全计算环境中的用户数据进行**保密性**保护；应提供重要业务**数据加密**服务，加密密钥由租户自行管理；应提供加密服务，保证虚拟机在迁移过程中重要数据的**保密性**。**【要点】**该标准明确了第三级、第四级系统采用加密保障保密性和完整性。
+
+**《GB/T 41479-2022 信息安全技术网络数据处理安全要求》（2022.11.1实施）**
+
+**【发布机构】**国家市场监督管理总局、中国国家标准化管理委员会**【相关条款】****4.3风险防控** 开展数据处理活动应加强风险监测，发现数据安全缺陷、漏洞等风险时，应采取**加密**、脱敏、备份、访问控制、审计等技术或者其他必要措施，加强数据安全防护，保护数据免受泄露、窃取、篡改、损毁、不正当使用等；**5.3存储**  存储重要数据和个人信息等敏感网络数据，应采用**加密**、安全存储、访问控制、安全审计等安全措施；**5.6传输**  传输重要数据和敏感个人信息时，应采用**加密**、脱敏等安全措施。**【要点】**该标准在网络数据的风险防控、存储、传输等环节，均明确做出加密、脱敏、访问控制、审计的安全技术要求，并且将加密放在第一顺位。
+
+**《GB/T 35273-2020 信息安全技术 个人信息安全规范》（2020.10.1实施）**
+
+**【发布机构】**全国网络安全标准化技术委员会**【相关条款】**6.3 传输和存储个人敏感信息时，应采用**加密**等安全措施。**【要点】**该标准在个人信息传输和存储方面，做出了加密处理的安全规定。
+
+**《GB/T 37988-2019 信息安全技术 数据安全能力成熟度模型》（2020.3.1实施）**
+
+**【发布机构】**全国网络安全标准化技术委员会
+
+**【相关条款】**第8节 **数据存储安全** 8.2.2.3等级3 应明确数据逻辑存储管理安全规范和配置规则，明确各类数据存储系统的账号权限管理、访问控制、日志管理、**加密**管理、版本升级等方面的要求。
+
+**【要点】**数据存储环节，从第三等级开始对数据加密管理作出要求。在其他环节也有数据加密的要求，限于篇幅不赘述。
+
+在上述四个国标，全部针对不同重要等级的数据，在数据生产、流转、存储的不同环节做出了加密要求。
+
+## **四、行业规章中对数据加密的要求**
+
+最后，我们将审视行业规章与管理办法中对于数据加密的要求。鉴于行业种类繁多且各自规章复杂，本文将仅选取工业和信息化、教育、金融及卫生这四个行业作为示例，进行概括性分析。
+
+**第四部分：行业规章**
+
+**《工业和信息化领域数据安全管理办法（试）》（2022.12.8实施）**
+
+**【发布机构】**工信部**【相关条款】**第十五条  工业和信息化领域数据处理者……存储重要数据和核心数据的，应当采用校验技术、**密码**技术等措施进行安全存储，并实施数据容灾备份和存储介质安全管理，定期开展数据恢复测试；第十七条  ……传输重要数据和核心数据的，应当采取校验技术、**密码**技术、安全传输通道或者安全传输协议等措施。
+
+**【要点】**对工业和信息化领域的数据存储和传输做出明确的加密要求。
+
+**《关于加强教育系统数据安全工作》的通知（2021.3.15）**
+
+**【发布机构】**教育部等七部门
+
+**【相关条款】**第二章（三）8.健全个人信息保护制度 …存储传输个人信息应采取**加密**措施，公开个人信息应采取去标识化处理。
+
+**【要点】**除了本文件，教育部《关于加强新时代教育管理信息化工作的通知》《关于推进教育新型基础设施建设构建高质量教育支撑体系的指导意见》等政策文件均对密码安全技术作出要求，其规定与本文件类似。
+
+**《银行保险机构数据安全管理办法（征）》（2024.3.22）**
+
+**【发布机构】**国家金融监督管理总局
+
+**【相关条款】**第二十八条  银行保险机构利用互联网等信息网络开展数据处理活动时，要落实网络安全等级保护、关键基础设施安全保护、**密码保护**等制度要求；第四十四条    敏感级及以上数据传输应当采取安全的传输方式，保障数据完整性、**保密性**、可用性；第四十七条  应当开展数据安全的技术基础设施建设，支持用户身份管理、**数据匿名化**、行为监测、日志审计、**数据虚拟化**等功能的组件化、服务化。
+
+**【要点】**对银行保险机构开展数据处理活动时的数据保密性、匿名性作出要求。数据匿名化、数据虚拟化也是数据加密的处理方式之一。
+
+**《中国人民银行业务领域数据安全管理办法（征）》（2023.7.24）**
+
+**【发布机构】**中国人民银行
+
+**【相关条款】**第十九条  涉及第三层级以上数据项导出使用的风险防范措施，原则上应当优先采取**加密**、数字水印或者脱敏处理等安全保护措施；第三十三条  应当优先采用**商用密码技术**对信息系统中第三层级以上数据项实施**加密存储**，结构化数据项在对数据库文件整体实施加密基础上鼓励进一步采用**更细粒度的加密方式**，非结构化数据项可仅对拆分的**第三层级以上结构化数据项单独实施加密**；第三十六条  第三层级以上数据项传输至其他数据处理者、传输至不同数据中心或者传输至运营商网络时，应当优先使用商用密码技术保障**机密性**，并根据业务需要使用商用密码技术加强**完整性**和抗抵赖性保障。
+
+**【要点】**对银行的第三层级以上数据，多处做出使用商用密码技术及加密技术的要求。
+
+**《医疗卫生机构网络安全管理办法》（2022.08实施）**
+
+**【发布机构】**国家卫健委
+
+**【相关条款】**第十五条  各医疗卫生机构应按照《密码法》等有关法律法规和密码应用相关标准规范，在网络建设过程中同步规划、同步建设、同步运行**密码保护**措施，使用符合相关要求的**密码产品和服务**。第二十二条  采取数据脱敏、**数据加密**、**链路加密**等防控措施，防止数据收集过程中数据被泄露；在数据分类分级的基础上，进一步明确不同安全级别数据的**加密传输**要求；选择合适的数据存储架构和介质在境内存储，并采取备份、**加密**等措施加强数据的存储安全；应采取安全措施存储和传输人脸识别数据，包括但不限于**加密****存储和传输**人脸识别数据，采用物理或逻辑隔离方式分别存储人脸识别和个人身份信息等。
+
+**【要点】**对密码产品、数据脱敏、数据加密、链路加密、传输加密、存储加密均做出明确要求。
+
+**综上所述，无论是在国家级法律法规及标准层面，还是在行业级规范与管理办法层面，对于数据加密均提出了明确且严格的要求。**
+
+在本文所列举的十项国家级法律法规及标准中，有九项明确规定了加密要求，包括：《网络安全法》《密码法》《个人信息保护法》《关键信息基础设施安全保护条例》《网络数据安全管理条例》《网络安全等级保护安全设计技术要求》《网络数据处理安全要求》《 个人信息安全规范》《数据安全能力成熟度模型》，唯一例外的是，《数据安全法》是通过引用等级保护要求来间接规定加密需求。直接规定加密的比例达到90%，间接规定为10%，合计覆盖率达到100%。
+
+在行业级要求方面，本文列出的涉及工业和信息化、金融、教育以及医疗行业的五项行业规章中，全部明确了加密的具体要求，占比同样达到了100%。
+
+## **结语**
+
+加密的要求主要体现在数据存储与传输两个环节。从所有数据安全技术要求来看，对加密的规定也许是最直接且最为严格的。
+
+这些合规要求不仅为新型生产力的高质量发展提供了坚实的法治基础，同时也为数据处理者的数据安全保障工作明确了方向。
@@ -0,0 +1,2 @@
+
+**分组密码、流密码、非对称密码算法和技术、**消息鉴别码**、杂凑函数、实体鉴别、**密钥管理**、随机比特生成器
@@ -0,0 +1,7 @@
+分组密码
+非对称密钥
+消息鉴别码
+杂凑函数
+实体鉴别
+密钥建立
+随机数生成器
@@ -0,0 +1,28 @@
+
+## 可信功能模块
+TPM2.0模块（Trusted Platform Module，国际标准）
+TCM2.0模块（Trusted Crypto Module，中国传统标准）
+TPCM模块（Trusted Platform Control Module，中国新兴标准）
+TDM模块（Trusted Dynamic Measuring, 海光私有）
+TSB模块（Trusted Secure Boot，海光私有）
+
+TKM密钥管理功能
+国密硬件引擎CCP
+可信计算是密码运算密集型技术，海光CPU内置了国密硬件引擎CCP对密码运算提供硬件加速，支持常用的密码算法，包括对称，非对称，Hash等。对称密码用来进行加解密及计算消息验证码HMAC，非对称密码用来进行签名验签及共享秘钥生成等，Hash用来度量及签名等。
+
+可信存储示意图
+
+![](https://c86.sourcefind.cn/pic/2/assets/tc/tc_whitebook-3.png)
+
+
+
+
+
+### 3.2.外部密钥派发到TKM设备场景
+
+**场景说明：**
+
+用户在使用中有将自己密钥明文派发到TKM设备内部密钥槽位的需求，派发后密钥掉电不丢失，这里对该应用场景进行示例说明，基本过程如下图所示，首先通过TKM接口在TKM内部生成一对非对称密钥对作为父密钥对，接着用户准备好将要派发的密钥明文，调用TKM接口导出父密钥对公钥，用户使用该公钥对将要派发的密钥明文进行加密得到密钥密文，调用TKM导入接口导入密钥密文并指定使用父密钥对的私钥解密装载，装载成功后该密钥被装入TKM设备密钥槽位并返回对应密钥索引信息，用户可以通过该索引来完成需要的基于TKM设备的密码运算
+
+![](https://c86.sourcefind.cn/pic/2/assets/tkm/tkm-3.png)
+![[Pasted image 20260104162700.png]]
@@ -0,0 +1,192 @@
+|（hag与固件build_id为1877及以上版本支持）
+
+用户在使用TKM设备中，有将一台设备所有内部密钥备份恢复到另一台设备的需求，这里共提供三种场景供用户参考。
+
+#### 3.10.1 备份恢复场景一：同一CPU备份与恢复
+
+**场景说明：**
+
+该场景通过使用CPU内唯一机密信息派生密钥，由该密钥对内部密钥进行加密及完整性保护，从而支持将设备内所有内部密钥备份，且仅支持在该设备内恢复，其他设备由于CPU内唯一机密信息不同，派生出来的密钥也将不同，因此将无法通过该密钥镜像进行恢复，如下图所示为一个基本的过程。这里在密钥恢复成功后做了一个简单的测试来验证密钥被成功恢复，即指定机器原密钥加密一段数据，使用机器恢复后的密钥解密，通过对比明文与解密后的明文是否一致即可进一步验证密钥备份恢复的正确性。
+
+  ![[Image.jpg]]
+
+**操作过程说明：**
+
+（1）在机器中生成待备份密钥，这里以类型为sm4索引为666号密钥为例，然后使用该密钥对一段数据明文进行加密；
+
+```
+$ sudo hag tkm intl_key_gen -type sm4 -idx 666 -auth intl.auth
+$ sudo hag tkm sm4 -handle 0x200029a -auth intl.auth -iv iv.data -in data64.plain -out enc_data.bin -e -m ecb -p pkcs7
+```
+
+命令正确执行的结果如下图：
+
+![[Image 1.jpg]]
+
+（2）调用密钥备份接口对上一步生成的sm4密钥进行备份，备份成功后，将上一步生成的sm4密钥销毁；
+
+```
+$ sudo hag tkm key_backup -auth sys.auth -scheme same_cpu -outfile key_same_cpu.bin
+$ sudo hag tkm key_destroy -handle 0x200029a -auth intl.auth
+```
+
+命令正确执行的结果如下图：
+
+![[Image 2.jpg]]
+
+（3）调用密钥恢复接口对密钥进行恢复，密钥恢复成功后，使用被恢复的sm4密钥解密备份前的数据密文，得到解密明文；将解密明文与数据明文对比，若一致表示恢复正常，否则恢复密钥异常；
+
+```
+$ sudo hag tkm key_restore -auth sys.auth -scheme same_cpu -infile key_same_cpu.bin
+$ sudo hag tkm sm4 -handle 0x200029a -auth intl.auth -iv iv.data -in enc_data.bin -out dec_data.bin -d -m ecb -p pkcs7
+$ sudo cmp -b data64.plain dec_data.bin && echo $?
+```
+
+命令正确执行的结果如下图：
+
+![[Image 3.jpg]]
+
+（4）清理测试环境。
+
+```
+$ sudo rm -rf enc_data.bin dec_data.bin key_same_cpu.bin
+$ sudo hag tkm key_destroy -handle 0x200029a -auth intl.auth
+```
+
+命令正确执行的结果如下图：
+
+![[Image 4.jpg]]
+
+#### 3.10.2 备份恢复场景二：同一代CPU备份与恢复
+
+**场景说明：**
+
+该场景通过使用同一代CPU相同的密钥，由该密钥对内部密钥进行加密及完整性保护，从而支持将设备S内所有内部密钥备份，且在同一代的CPU的D设备内恢复，如下图所示为一个基本的过程。这里在密钥备份恢复成功后做了一个简单的测试来验证密钥被成功在另一台设备恢复，即指定机器S原密钥加密一段数据，使用机器D恢复后的密钥解密，通过对比明文与解密后的明文是否一致即可进一步验证密钥恢复的正确性。
+
+![[Image 5.jpg]] 
+
+**操作过程说明：**
+
+（1）在机器S中生成待备份密钥，这里以类型为sm4索引为666号密钥为例，然后使用该密钥对一段数据明文进行加密，加密成功后，调用备份接口对机器S密钥进行备份，并将加密数据密文、备份密钥文件传递给机器D用于恢复验证；
+
+```
+$ sudo hag tkm intl_key_gen -type sm4 -idx 666 -auth intl.auth
+$ sudo hag tkm sm4 -handle 0x200029a -auth intl.auth -iv iv.data -in data64.plain -out enc_data.bin -e -m ecb -p pkcs7
+$ sudo hag tkm key_backup -auth sys.auth -scheme same_gen -outfile key_same_gen.bin
+```
+
+命令正确执行的结果如下图：
+
+![[Image 6.jpg]]
+
+（2）机器D使用从机器S获取的备份密钥文件调用恢复接口进行恢复，并使用恢复后的密钥解密从机器S收到的数据密文，得到解密明文；将解密明文与数据明文对比，若一致表示恢复正常，否则恢复密钥异常；
+
+```
+$ sudo hag tkm key_restore -auth sys.auth -scheme same_gen -infile key_same_gen.bin
+$ sudo hag tkm sm4 -handle 0x200029a -auth intl.auth -iv iv.data -in enc_data.bin -out dec_data.bin -d -m ecb -p pkcs7
+$ sudo cmp -b data64.plain dec_data.bin && echo $?
+```
+
+命令正确执行的结果如下图：
+
+![[Image 7.jpg]]
+
+（3）机器S与机器D清理测试环境。
+
+机器S清理：
+
+```
+$ sudo rm -rf enc_data.bin key_same_gen.bin
+$ sudo hag tkm key_destroy -handle 0x200029a -auth intl.auth
+```
+
+命令正确执行的结果如下图：
+
+![[Image 8.jpg]]
+
+机器D清理：
+
+```
+$ sudo rm -rf dec_data.bin enc_data.bin key_same_gen.bin
+$ sudo hag tkm key_destroy -handle 0x200029a -auth intl.auth
+```
+
+命令正确执行的结果如下图：
+
+![[Image 9.jpg]]
+
+#### 3.10.3 备份恢复场景三：设备证书方式备份与恢复
+
+**场景说明：**
+
+该场景通过使用TKM设备证书，由恢复机器D将自己证书链提供给机器S，机器S首先对其进行证书链验证，验证通过后使用其TKM设备证书中的公钥在设备内通过密钥协商方式生成密钥，并将协商共享数据导出供后续机器D使用，之后使用该生成密钥对内部密钥进行加密及完整性保护，从而支持将设备S内所有内部密钥备份；在机器D恢复时，设备将会首先使用自己的设备私钥以及S传递的共享数据计算出协商密钥，之后该协商密钥对备份的密钥文件进行解密恢复，如下图所示为一个基本的过程。这里在密钥备份恢复成功后做了一个简单的测试来验证密钥被成功在另一台设备恢复，即指定机器S原密钥加密一段数据，使用机器D恢复后的密钥解密，通过对比明文与解密后的明文是否一致即可进一步验证密钥恢复的正确性。
+
+![[Image 10.jpg]]
+
+**操作过程说明：**
+
+（1）机器D首先获取自己的证书链文件，并将自身证书链文件提供给机器S；
+
+```
+$ sudo hag tkm cert_chain_get -cert_type sign -outfile certchain.bin
+```
+
+命令正确执行的结果如下图：
+
+![[Image 11.jpg]]
+
+（2）在机器S中生成待备份密钥，这里以类型为sm4索引为666号密钥为例，然后使用该密钥对一段数据明文进行加密，加密成功后，调用备份接口对机器S密钥进行备份，并将加密数据密文、备份密钥文件、共享数据文件传递给机器D用于恢复验证；
+
+```
+$ sudo hag tkm intl_key_gen -type sm4 -idx 666 -auth intl.auth
+$ sudo hag tkm sm4 -handle 0x200029a -auth intl.auth -iv iv.data -in data64.plain -out enc_data.bin -e -m ecb -p pkcs7
+$ sudo hag tkm key_backup -auth sys.auth -scheme dev_cert -outfile key_dev_cert.bin -cert certchain.bin -sharedfile shared_data.bin
+```
+
+命令正确执行的结果如下图：
+
+![[Image 12.jpg]]
+
+（3）机器D使用从机器S获取的备份密钥文件、共享数据文件调用恢复接口进行密钥恢复，并使用恢复后的密钥解密从机器S收到的数据密文，得到解密明文；将解密明文与数据明文对比，若一致表示恢复正常，否则恢复密钥异常；
+
+```
+$ sudo hag tkm key_restore -auth sys.auth -scheme dev_cert -infile key_dev_cert.bin -sharedfile shared_data.bin
+$ sudo hag tkm sm4 -handle 0x200029a -auth intl.auth -iv iv.data -in enc_data.bin -out dec_data.bin -d -m ecb -p pkcs7
+$ sudo cmp -b data64.plain dec_data.bin && echo $?
+```
+
+命令正确执行的结果如下图：
+
+![[Image 13.jpg]]
+
+（4）机器S与机器D清理测试环境
+
+机器S清理：
+
+```
+$ sudo rm -rf enc_data.bin shared_data.bin key_dev_cert.bin
+$ sudo hag tkm key_destroy -handle 0x200029a -auth intl.auth
+```
+
+命令正确执行的结果如下图：
+
+![[Image 14.jpg]]
+
+机器D清理：
+
+```
+$ sudo rm -rf key_dev_cert.bin shared_data.bin dec_data.bin enc_data.bin
+$ sudo hag tkm key_destroy -handle 0x200029a -auth intl.auth
+```
+
+命令正确执行的结果如下图：
+
+![[Image 15.jpg]]
+
+### 3.11.环境清理
+
+清理公共部分初始化的数据
+
+```
+$ sudo rm -rf intl.auth intl2.auth apk.auth iv.data data32.plain data64.plain sys.auth
+```
@@ -0,0 +1,13 @@
+# NSA 在 RSA 加密算法中安置后门是怎么一回事，有何影响？
+
+https://www.zhihu.com/question/22343037
+
+
+据悉，RSA存有缺陷公式的软件叫做Bsafe，而该缺陷公式的名字为Dual Elliptic Curve，它由NSA开发而出。
+
+BSafe是很多企业级用户采购安全软件，此举将让NSA通过随机数生成算法Bsafe的后门程序轻易破解各种加密数据。
+
+
+
+其实RSA并非p和q足够大就安全了，比如p和q过于接近时可以使用费马分解法，p-1 或者 p+1 是光滑数的时候可以用 Pollard’s p-1 method ... 等等还有许多各式各样的攻击
+
@@ -0,0 +1,103 @@
+
+
+ **1.      发展数据安全是必然趋势**
+
+2022年6月，在中央全面深化改革委员会第二十六次会议上，习近平总书记强调，“数据基础制度建设事关国家发展和安全大局，要维护国家数据安全，保护个人信息和商业秘密，促进数据高效流通使用、赋能实体经济，统筹推进数据产权、流通交易、收益分配、安全治理，加快构建数据基础制度体系”。指出要建立数据产权制度，推进公共数据、企业数据、个人数据分类分级确权授权使用，建立数据资源持有权、数据加工使用权、数据产品经营权等分置的产权运行机制，健全数据要素权益保护制度。
+
+同时，国家层面持续加强数据安全战略指引、顶层设计和政策发力，数据安全重视程度持续上升，将数据安全和个人信息保护提升到了国家战略高度，大力推动加强数据安全保护，维护公民、组织的数据合法权益。海泰方圆认为，发挥数据的基础资源作用和创新引擎作用，推进数据资源开放和开发利用是时代的必然趋势。
+
+# **2.      展望数据安全的发展需求**
+
+随着各行业的信息化水平快速发展，数据作为核心资产的价值也越发凸显，为了保障政企单位信息化的发展成果和实现数据驱动业务的数字化治理，数据资产需要通过合理的处理手段保证其安全，由于应用互联互通更广泛、数据融合和共享程度更高、网络接入方式更多样化，政企单位普遍面临如下需求：
+
+1)   **加强整体统筹规划**。依据数据安全相关法律法规、标准规范等国家和行业合规要求，结合数据安全现状，规划、建设数据安全能力体系的数据安全治理总体框架，解决碎片化、被动式的安全建设思路带来“数据孤岛”问题。
+
+2)   **细化数据安全策略设置**。需要实现安全保护和高效利用的兼顾，从数据价值、数据类型和重要程度多个维度对组织数据资产进行分类分级，并根据影响程度采取不同的管控措施。
+
+3)   **提高安全治理自动化水平**。需要针对重要数据资产建立常态化的安全运营机制，通过自动化的监测技术手段，管控数据流动风险。
+
+4)   **整合多种数据安全保护手段**。在数据全周期中采用有效的数据安全保护技术，集中管理数据加密、数据脱敏、数据库审计等安全工具，实现数据安全联防联控。
+
+**鉴于以上需求，海泰方圆融合多年的密码技术积累和政企****数据****服务经验，创新推出了数据安全****治理****“立体式”****框架****。**
+
+# **3.      海泰方圆数据安全治理“立体式”框架**
+
+数据安全的内涵不仅局限于安全技术层面，还需要围绕数据全生命周期的安全，涉及全流程制度制定、体系化技术实现等一系列工作集合。根据数据安全的实际需求和当前发展状况，目前已经有很多数据安全的模型体系。海泰方圆数据安全立体式框架参考DGI框架、IBM框架，并结合DSMM模型，将零散的数据需求容纳集中，从数据分类分级维度，数据生命周期维度和数据安全技术维度对数据进行安全治理。数据立体式框架覆盖“数据全生命周期”的采集、传输、存储、处理、交换、销毁六个环节，并围绕各个周期数据安全的脆弱性，根据面临的各种风险制定针对性的解决方案。实现以数据驱动发展，提升数据资产价值，同时为“让数据使用更安全”奠定数据治理基础。
+
+![](https://www.haitaichina.com/upload/20231007/f22dae6872b4472a8512ae09b6c6a3ac.png)
+
+## 3.1.    数据分类分级维度
+
+数据资产保护的核心在于数据分类分级。以数据分类分级为基础，对数据进行等级划分，从而为组织数据的汇聚、开放和共享安全策略制定提供支撑的过程。
+
+![图片3](https://www.haitaichina.com/upload/20231007/ebfaae380b6040db83121abba779fc67.png)
+
+**参照《网络安全标准实践指南－网络数据分类分级指引》，海泰方圆提出数据分类分级治理思路：**
+
+数据分类是数据分类分级保护的前提。数据分类按照一定的原则和方法对数据进行区分和归类，主要目的是便于数据管理和使用。数据分类是数据保护工作中的一个关键部分，是建立统一、准确、完善的数据架构的基础。
+
+在完成数据分类后，数据处理者应当遵循数据分级的基本原则，制定个性化的数据分级保护策略。数据分级指在数据分类的基础上，采用规范、明确的方法区分数据的重要性和敏感度差异，将数据从非敏感到非常敏感分为五个级别，从而为组织数据的开放和共享安全策略制定提供支撑的过程。
+
+## 3.2.    数据生命周期维度
+
+围绕着数据采集、传输、存储、处理、交换、销毁全生命周期进行全面建设，以提高全方位数据安全治理能力。
+
+![](https://www.haitaichina.com/upload/20231007/a9c8456a3a1449e78648e07f98ab6b25.png)
+
+(1)    数据采集安全
+
+针对不同安全级别的数据，采取不同的安全保护，防止敏感信息被损毁、误用和非授权访问，保障敏感信息的保密性、完整性和可用性。必要时应采取加密技术保证采集过程中的数据不被泄露。相关技术包括身份认证、访问控制、数据分类分级、数据脱敏等。
+
+(2)    数据传输安全
+
+数据传输安全是指为防止传输过程中的数据泄漏而采取的防护措施。数据传输安全防护包括数据机密性、完整性和真实性保护，传输数据机密性保护用于保证数据传输时不被非法获取，传输数据完整性保护用于保护数据传输时不被非法篡改，传输数据真实性保护用于保护传输数据来源的真实可靠。通过IPSec/SSL VPN综合安全网关将密码运算过程封装在其内部完成，为应用程序的安全远程接入服务，企业各分支机构局域网之间的端对端数据安全传输、安全访问，提供数据真实性、完整性保护等安全保障。
+
+(3)    数据存储安全
+
+数据存储特别是敏感信息存储的安全在数据生命周期中占有很重要的位置，数据创建以后如果没有进行安全的存储，则极易引发泄露和丢失。数据保存应确保在安全的环境中，在需要的情况下还应该加密存储，同时还需要防止存储的敏感数据被篡改。相关技术方法包括数据加密和数字签名以及数据存储备份等。
+
+(4)    数据处理安全
+
+数据只有经过分析处理，才能将其中有价值的知识挖掘出来，同时，需要在保护隐私前提下对数据进行分析处理，限制对大数据中敏感知识的挖掘。处理包括数据脱敏等防泄漏技术方法。
+
+数据脱敏处理的执行范畴依据国家和本行业数据安全法规的规定，包括针对敏感信息、个人信息、客户数据等在数据生命周期相关环节中的脱敏要求和去标识化要求。执行点包括但不限于对数据在处理、使用、访问、分享时的窃取、滥用风险防护，和对开发、测试、运维、分析等非生产环境或外包环境中的敏感、隐私数据保护。
+
+(5)    数据交换安全
+
+数据是国家重要的基础性战略资源，然而，数据滥用等问题，严重阻碍了数据共享使用的发展。一方面，在数据使用环节，数据的查询、访问过程中，不严格的权限访问将导致数据泄漏；另一方面，在数据共享开放环节，数据资源跨部门、跨域共享使用，不可避免地导致数据被各使用方存储使用，其中任何一个使用方措施不当，都可能导致数据泄漏。如何保证数据的使用安全？这方面方法主要集中在安全访问控制、隐私保护等技术方面。
+
+访问控制是数据安全的一个基本组成部分，它规定了哪些人可以访问和使用数据资源。通过身份验证和授权，访问控制策略可以确保用户的真实身份，并且拥有访问数据的相应权限。
+
+隐私保护技术包括安全多方计算、同态加密、差分隐私、机密计算等技术，通过隐私计算技术可实现数据的“可用不可见”，保证数据在使用的同时不泄漏隐私信息。
+
+(6)    数据销毁安全
+
+数据的安全销毁也是数据安全的一个重要环节。数据销毁应保证数据无法还原，并且具备安全审计能力，应提供数据销毁过程的安全审计功能，审计覆盖到各系统每个用户，对数据销毁过程中的重要用户行为和重要安全事件保留审计日志并进行审计。数据库审计系统通过对数据库操作、访问用户，及外部应用用户的审计，来帮助用户事后生成合规报告、事故追根溯源，同时通过大数据搜索技术提供高效查询审计报告，定位事件原因，以便日后查询、分析、过滤，实现加强内外部数据库网络行为的监控与审计，提高数据资产安全。
+
+## 3.3.    数据安全技术维度
+
+数据安全治理“立体式”框架以数据为中心，融合多种安全技术，构建全方位的数据安全技术体系。通过N种场景中每一个具体、明确的数据安全技术点，对数据安全进行监管并满足合规需求。完善的数据安全技术点能够为数据安全提供可行性保障，企业在技术工具的布局与应用方面加强数据安全技术规划，防护布局由多个“点”形成多个维度，进一步构成“立体式”架构。
+
+密码技术是网络安全的基础和核心，是解决网络与信息安全问题最有效、最可靠、最经济的手段。**海泰方圆**能够提供全品类的密码软硬件产品，能够提供统一的、完整的、可扩展的密码服务，实现对数据的真实性、机密性、完整性保护和对操作行为的抗抵赖。在数据安全领域，密码技术用于满足数据全生命周期的存储、应用、共享流通等各个环节的安全需求，并兼顾数据安全性与可用性的平衡。
+
+**(1)**   **数据****全周期安全管控平台通过****NLP****技术为企业提供安全支撑**
+
+数据资产梳理和分类分级是数据安全治理的基础环节。**海泰方圆数据全周期安全管控平台**聚焦于数据的细颗粒度安全保护，全面掌握全域敏感数据资产分类、分级及分布情况，利用NLP技术有效监控敏感数据流转路径和动态流向，通过集中化数据安全管控策略管理，实现数据分布、流转、访问过程中的态势呈现和风险识别。
+
+**(2)**   **隐私计算服务系统利用同态加密技术实现数据“可用不可见”**
+
+使用同态加密技术，用户对密文进行运算后再解密得到的结果与直接对明文进行运算得到的结果一致，能够避免第三方在运算过程中需要解密密文而导致的用户敏感信息泄露，是解决多方安全计算问题的重要手段。**海泰方圆隐私计算服务系统**基于同态加密技术，提供了基础数学运算能力和复杂场景的多方联合计算能力，确保处理的过程中数据全程保持加密状态，实现数据“可用不可见”，适用于解决多组织联合数据运算和分析情况下的数据安全问题。
+
+**(3)**   **数据脱敏系统基于保留格式加密技术保护企业敏感数据**
+
+保留格式加密是一种特殊的对称密码算法，其特征表现为加密后的密文与明文具有相同的格式，密文与明文处于相同的消息空间。**海泰方圆****数据脱敏系统**利用保留格式加密技术，能够在保留原有数据的有效信息特征的情况下，通过对部分数据进行遮蔽、替换、混淆等方法，对数据中敏感信息进行数据的变形，实现敏感隐私数据的可靠保护。
+
+**(4)**   **数据库加密系统采用数据透明加密技术满足等保合规要求**
+
+数据透明加密技术是指对用户来说无需更改现有的应用系统和操作习惯。当用户通过应用程序访问数据库时，得到的是明文数据，而未授权的用户通过非法手段访问数据库得到的都是密文数据。**海泰数据库加密系统**为数据库数据提供加密存储、访问控制增强、应用访问安全、三权分立等功能。系统提供主动的数据安全防御机制，防止明文存储引起的数据泄密、突破边界防护的外部黑客攻击和内部高权限用户的数据窃取行为，同时防止绕开合法应用系统直接访问数据库的外部攻击和窃取，从根本上解决数据库数据的存储安全问题。
+
+**通过构建数据安全治理****立体式****框架，逐步有序地打通了数据堵点，实现了数据的汇聚、共享、开放，构成全面的、立体的数据安全环境。**
+
+**结束语：**
+
+海泰方圆紧跟国家战略和行业发展趋势，基于多年的密码能力，在保障数据安全的前提下，持续打造并不断沉淀安全产品和服务能力，为用户提供数全周期安全管控、数据安全态势感知、数据加密、数据脱敏、数据库审计、国密浏览器等全方位数据安全保护服务。
--- a/Show More
+++ b/Show More
				`@@ -0,0 +1,4 @@`
				`GCM 是在 CTR 模式的基础上，增加了认证操作的分组模式。`
				`@@ -0,0 +1 @@`
				`混合软件模块：软件运行环境所包含的计算平台和操作系统，在定义的混合软件模块边界之外。`
				`@@ -0,0 +1,2 @@`

				`分组密码、流密码、非对称密码算法和技术、消息鉴别码、杂凑函数、实体鉴别、密钥管理**、随机比特生成器`