第1章 概述：隐私增强SDK与国密算法简介

各位好，我是你们这趟课的老司机。先聊点实在的——隐私增强SDK和国密算法，这两个东西凑在一起，说白了就是给数据穿上“防弹衣”的同时，还得保证这衣服是“中国造”的。

1.1 从一次实战说起

我记得去年帮一家金融科技公司做数据合规改造。他们产品里集成了常规的AES-256加密，但监管要求必须用国密。一换才发现，坑比想象的多：SM4的密钥封装跟AES GCM不一样，SM2签名的性能在低端设备上直接掉了80%。嗯，这就是为什么我会花30章来讲这套适配指南。

我个人的习惯是，每次对接新加密库前，先画一张全景图。你想想看，隐私增强SDK（如差分隐私、联邦学习、同态加密）本身已经够复杂了，再叠一层国密算法，中间的接口、参数、性能权衡，稍不留神就踩雷。

1.2 隐私增强SDK到底做什么

隐私增强SDK（Privacy-Enhancing SDK）是一套工具集，帮助应用在不泄露原始数据的前提下完成计算。常见场景包括：

• 差分隐私： 往统计结果里加噪声，防止个体信息被反向推断。
• 联邦学习： 模型在客户端训练，只上传梯度更新。
• 安全多方计算（MPC）： 多个参与方联合计算，彼此看不到原始输入。
• 同态加密： 直接在密文上做运算，结果解密后与明文计算结果一致。

这些技术都有一个共性——它们依赖底层密码库做密钥交换、签名、哈希、对称加密。以前大家默认用OpenSSL里的AES、ECDSA、SHA-256，换成国密后，SM2替代ECDSA，SM3替代SHA-256，SM4替代AES，SM9替代部分基于身份的加密场景。

1.3 国密算法：不只是替换

国密（GM/T 系列）目前主流的有四个：

你可能会问：“直接换不就完了，有什么可适配的？” 我在做第一个项目时也这么想，结果被SM2的签名格式坑了——SM2签名输出的是r||s两个大整数，DER编码方式跟ECDSA不一样。如果SDK内部硬编码了解析逻辑，你就得从头改。

1.4 适配框架概览

下面这张图是我多年踩坑后总结出的适配结构。它把隐私增强SDK与国密算法的关系分成四层，每一层都有明确的职责和接口契约。

1.5 适配中的常见误区

根据我服务过的十几个项目，下面这几条坑最常见：

1. 直接改算法标识： 以为把“AES-GCM”替换成“SM4-GCM”就行。实际上SM4的GCM模式参数（如Nonce长度、Tag长度）可能不同，需要查国标GM/T 0002。
2. 忽略密钥派生： 隐私增强SDK里很多协议会用到KDF，国密有自己的一套（如SM2密钥交换中的KDF）。我见过有团队直接拿HMAC-SHA256做派生，结果不符合国密合规。
3. 性能不做预热： SM2签名在Java上首次调用时，GMSSL库可能会做预计算（如预生成随机数对），如果没预热，第一笔交易延迟会很高。

1.6 为什么你需要这门课

说实话，市面上讲隐私增强SDK的不少，讲国密的也有，但把两者结合起来的系统材料几乎是空白。我写这30章的目标很明确：

• 帮你在项目启动前就识别出80%的适配问题。
• 给出即插即用的代码模板（C++/Java/Go/Python都会覆盖）。
• 分享我在金融、医疗、政务场景里实际的性能调优数据。

好了，第一章先聊到这儿。我先把概念骨架搭好，后面每一章都会围绕一个具体的适配痛点深入展开。记住这张架构图，它是我们整个课程的地图。