第2章数据加密基础

数据加密基础：对称加密与非对称加密、哈希算法与数字签名、国密算法（SM2/SM3/SM4）介绍

各位同学好，我是老张。今天咱们聊聊数据加密的基础。说实话，在金融云这个领域，加密不是「要不要做」的问题，而是「怎么做才合规、才安全」的问题。我见过太多项目因为加密选型不当，最后被监管点名整改的案例。

这一章，我会把对称加密、非对称加密、哈希算法、数字签名，还有咱们国家的国密算法，掰开揉碎了讲清楚。你想想看，这些概念如果搞混了，后面做密钥管理方案时，很容易踩坑。

核心观点：没有一种加密算法是万能的。对称加密快，但密钥分发难；非对称加密解决了密钥分发问题，但慢；哈希算法不可逆，适合做完整性校验。国密算法则是我们金融行业的「合规刚需」。

一、对称加密：又快又简单，但有个致命弱点

对称加密，说白了就是「一把钥匙开一把锁」。加密和解密用的是同一个密钥。你想想看，就像你家大门钥匙，自己开门进去，别人拿这把钥匙也能开门。

常见的对称加密算法有：

AES（Advanced Encryption Standard）：国际主流，密钥长度128/192/256位。我个人习惯用AES-256-GCM模式，因为自带认证标签，能防篡改。
SM4：国密标准，分组长度128位，密钥长度128位。金融行业做数据存储加密时，SM4是首选。
DES/3DES：老古董了，别用了。我记得2018年有个项目还在用DES，被安全审计直接打回。

我的经验：对称加密适合做「大量数据的加密」。比如数据库表里的身份证号、手机号，用SM4加密后存储，性能损耗可以控制在5%以内。但要注意——密钥不能硬编码在代码里！我曾经见过一个项目，密钥直接写在配置文件里，明文存储...嗯，那场面，惨不忍睹。

对称加密的工作模式也很关键。ECB模式不安全，同样的明文块会生成同样的密文块，容易泄露模式信息。我建议用GCM或CTR模式，它们引入了初始向量（IV），每次加密结果都不一样。

// 对称加密示例（伪代码）
// 使用 SM4-GCM 模式加密数据
function encryptData(plaintext, key) {
    iv = generateRandomIV(12 bytes);  // 每次随机生成
    ciphertext = SM4_GCM_Encrypt(plaintext, key, iv);
    return iv + ciphertext;  // IV 需要和密文一起存储
}

二、非对称加密：解决了密钥分发，但慢

非对称加密，也叫公钥加密。它有一对密钥：公钥公开，私钥保密。公钥加密的数据，只有私钥能解开。反过来，私钥签名的数据，公钥可以验证。

这解决了对称加密最大的痛点——密钥分发。你想想看，如果两个人要通信，对称加密需要提前把密钥传给对方，这个过程很容易被截获。而非对称加密，你只需要把公钥公开，别人用公钥加密数据发给你，只有你的私钥能解开。

常见的非对称加密算法：

RSA：经典算法，密钥长度2048位起步。但RSA有个问题，密钥越长性能越差。1024位的RSA已经被破解了，别用了。
SM2：国密椭圆曲线算法。相比RSA，SM2在同等安全强度下密钥更短、性能更好。256位的SM2相当于3072位的RSA。
ECC（椭圆曲线加密）：SM2就是基于ECC的。我个人更推荐ECC系列，因为它在移动端和IoT设备上表现更好。

避坑指南：非对称加密不适合加密大块数据。我曾经有个同事，直接用RSA加密一个10MB的文件，结果加密花了3分钟，解密又花了3分钟...正确的做法是「混合加密」：用非对称加密传输对称密钥，再用对称密钥加密实际数据。这是TLS协议的核心思想。

三、哈希算法与数字签名：完整性校验的基石

哈希算法，也叫散列函数。它能把任意长度的数据，映射成一个固定长度的摘要。哈希算法有几个特点：

不可逆：从摘要反推原始数据，理论上不可能。
抗碰撞：很难找到两个不同的输入，产生相同的摘要。
雪崩效应：输入改一个比特，摘要完全变样。

常见的哈希算法：

SHA-256：输出256位摘要，目前最常用。比特币用的就是它。
SM3：国密哈希算法，输出256位。和SHA-256安全性相当，但算法细节不同。
MD5：128位输出，已经被破解了。别用了，真的。

数字签名是哈希算法和非对称加密的结合。流程是这样的：

发送方对数据做哈希，得到摘要。
发送方用私钥对摘要加密，生成签名。
接收方用公钥解密签名，得到摘要A。
接收方对收到的数据做哈希，得到摘要B。
比较A和B，如果一致，说明数据没被篡改，且确实是发送方签的。

为什么需要数字签名？哈希只能保证数据完整性，但不能证明是谁发的。数字签名提供了「防抵赖性」——发送方不能否认自己签过名。这在金融交易中至关重要。比如银行转账指令，必须用数字签名确保是客户本人发起的。

四、国密算法：SM2/SM3/SM4 详解

国密算法是国家密码管理局发布的商用密码标准。在金融行业，国密是合规刚需。等保三级、金融行业监管要求，都明确规定了必须使用国密算法。

算法	类型	密钥长度	典型应用场景
SM2	非对称加密 / 数字签名	256位	密钥交换、数字证书、身份认证
SM3	哈希算法	256位摘要	完整性校验、数字签名中的哈希环节
SM4	对称加密	128位	数据存储加密、通信加密

SM2：基于椭圆曲线密码学。相比RSA，SM2的优势很明显：

密钥更短：256位SM2 ≈ 3072位RSA
计算更快：签名速度是RSA的3-5倍
安全性更高：椭圆曲线离散对数问题比大整数分解更难

SM3：输出256位哈希值。它的结构和SHA-256类似，但做了改进。SM3的抗碰撞性经过严格验证，目前没有发现有效攻击。

SM4：分组密码，分组长度128位，密钥长度128位。它的设计借鉴了AES的一些思想，但轮函数和密钥扩展算法完全不同。SM4在软件实现上性能不错，硬件实现也很成熟。

我的建议：在做金融云方案时，尽量做到「双算法支持」。比如同时支持SM4和AES，SM2和RSA。因为有些第三方系统可能还没完成国密改造，需要兼容。但长期来看，国密是趋势。我记得2021年帮某银行做密钥管理系统时，他们要求所有新建系统必须纯国密，老系统三年内完成迁移。

// 国密算法使用示例（伪代码）
// SM2 签名与验签
function signData(data, privateKey) {
    hash = SM3(data);  // 先哈希
    signature = SM2_Sign(hash, privateKey);
    return signature;
}

function verifySignature(data, signature, publicKey) {
    hash = SM3(data);
    isValid = SM2_Verify(hash, signature, publicKey);
    return isValid;
}

// SM4 加密
function encryptWithSM4(plaintext, key) {
    iv = generateRandomIV(16 bytes);
    ciphertext = SM4_CBC_Encrypt(plaintext, key, iv);
    return iv + ciphertext;
}

五、混合加密：实际项目中的最佳实践

在实际的金融云项目中，我们不会只用一种加密算法。而是采用「混合加密」方案：

用SM2（非对称）加密传输SM4的密钥。
用SM4（对称）加密实际业务数据。
用SM3（哈希）做数据完整性校验。
用SM2（签名）做身份认证和防抵赖。

这样做的好处很明显：既利用了对称加密的高性能，又利用了非对称加密的密钥分发优势，还通过哈希和签名保证了完整性和真实性。

注意：密钥的生命周期管理比加密算法本身更重要。密钥怎么生成？怎么存储？怎么轮换？怎么销毁？这些环节如果出问题，再强的加密算法也没用。我曾经见过一个项目，SM4密钥用了一年都没轮换，而且密钥存储的HSM（硬件安全模块）密码是默认的...嗯，那项目后来被监管罚了。

好了，这一章的内容就到这里。数据加密基础是密钥管理方案的「地基」，地基打不牢，后面盖什么楼都危险。下一章我们会深入密钥的生命周期管理，到时候会用到今天讲的所有概念。

公众号:蓝海资料掘金营，微信deep3321

📚 课程目录

数据加密基础：对称加密与非对称加密、哈希算法与数字签名、国密算法（SM2/SM3/SM4）介绍

一、对称加密：又快又简单，但有个致命弱点

二、非对称加密：解决了密钥分发，但慢

三、哈希算法与数字签名：完整性校验的基石

四、国密算法：SM2/SM3/SM4 详解

五、混合加密：实际项目中的最佳实践