日志系统中的密码学应用场景：签名、加密、哈希
讲国密替换，得先搞清楚一个问题：密码学到底在日志系统里干什么活？
说白了，日志就是个记录本。你记下了谁、什么时间、干了什么。但如果这个记录本可以被随便改，那它还有啥用？我见过不少团队，一开始只把日志当调试工具，直到出了安全事故，才发现日志本身的保护才是命门。
在我做过的几个金融级日志系统里，密码学主要干三件事：签名、加密、哈希。下面我一个个拆开讲。
1. 签名场景：谁说日志不用验真伪？
很多人觉得日志就是写文件，不需要签名。真是这样吗？
你想想看：如果攻击者渗透了服务器，他能不能改掉 audit.log 里的内容？把“root 执行了 rm -rf /”改成“guest 执行了 ls”？
这就是日志签名要解决的问题。我们用私钥对每条日志或日志块进行签名，验证的时候用公钥。任何篡改，签名校验都会失败。
我之前在一个银行项目中，他们的合规审计日志要求逐条签名。每条日志生成时，后端服务立即用 SM2 私钥签一个值，附在日志后面。嗯，这里要注意——签名不是免费的。SM2 签名长度大约 70 字节，如果日志量一天几亿条，存储和网络开销都不可忽视。
2. 加密场景：日志里的敏感数据怎么藏？
这一点做安全的人特别敏感。日志里经常包含：用户手机号、身份证号、交易金额、甚至信用卡尾号。
这些数据如果明文写进日志，一旦日志泄露就是大规模数据泄露事件。我参与过一个电商项目，就是因为日志里不小心打了用户手机号，被监管罚了几十万。
加密有两种思路：
- 字段级加密：只加密敏感字段，其他保持可读。日志系统仍然可以检索非敏感字段。
- 整日志加密：整条日志加密存储。安全性最高，但检索基本废了。
国密替换下，原来用 AES-256 的地方要换成 SM4。SM4 也是对称加密，分组长度 128 位，密钥长度 128 位。算法换了，密钥管理和加密接口都得改。
| 算法 | 类型 | 密钥长度 | 兼容性影响 |
|---|---|---|---|
| AES-256 | 对称加密 | 256 位 | 由其他密码库实现，替换为 SM4 需改算法标识 |
| SM4 | 对称加密 | 128 位 | 国密标准，需确认日志收集器是否支持 |
| RSA | 非对称加密/签名 | 2048+ 位 | 替换为 SM2，签名长度和计算开销差异大 |
| SM2 | 非对称加密/签名 | 256 位（基于椭圆曲线） | 签名长度约 70 字节，远小于 RSA |
3. 哈希场景：日志完整性校验的基石
哈希是签名和加密的基础。但日志系统里，哈希有一个更直接的应用：日志指纹。
举个例子：我需要审计过去一周的所有日志。逐条解密验签太慢了。怎么办？
我可以每天半夜对前一天的日志文件算一个 SM3 哈希值，然后把这个哈希值签个名存起来。第二天审计时，只要比对这个哈希，就知道日志有没有被改过。
SM3 替换 SHA-256 时，兼容性问题相对小。因为它们都是 256 位的哈希值，长度一样。但算法标识不同，解析日志的代码必须识别新的标识字符串。比如原来写 "sha256:" 的地方要改成 "sm3:"。
知识体系总览
下面这张图把日志系统中密码学的三个核心应用场景串起来了。你可以看到：身份认证与完整性校验靠签名（SM2）打底，机密性保护靠加密（SM4），数据指纹验证靠哈希（SM3）。三者各司其职，替换时要逐层检查兼容性。
到底要改哪些地方？
每次做国密替换，团队最头疼的就是“到底要碰多少代码”。我把日志系统里涉及的改动点列一下，你可以对照检查自己的项目。
- 日志生成端：签名/加密/哈希的算法调用库要换。原来用 OpenSSL 的 EVP_sha256，现在要换成 GMSSL 或其他国密库的 sm3。
- 日志传输端：如果用了加密通道（如 TLS），证书和密钥交换算法也要支持国密套件。
- 日志存储端：存储格式里要记录算法标识，不然以后解析时不知道用的是 SM2 还是 RSA。
- 日志消费端：解析、校验、审计的工具都要更新密码库。