加密、加签、摘要算法对比
在日常开发和设计中，总是会涉及到加AES、RSA、SHA256等术语，但是对这些算法的不同以及联系不是很清楚，概念上含糊不清，因为经历过几次相关的开发，本次将加密、加签、摘要算法等概念进行梳理和对比，加强自己对这些概念的理解。
概念对比
| 技术 | 核心特点 | 常见算法 | 典型应用场景 |
| 对称加密 | 加密和解密使用相同密钥，速度快，但密钥分发困难 | AES, DES, 3DES, ChaCha20 | 大量数据加密（如文件加密、HTTPS会话加密） |
| 非对称加密 | 使用公钥（公开）和私钥（保密），速度慢，解决密钥分发问题 | RSA, ECC, ElGamal | 密钥交换、数字签名、身份认证 |
| 摘要算法 | 单向哈希函数，生成固定长度唯一指纹，不可逆 | SHA-256, MD5 (不推荐), SM3 | 数据完整性校验、密码存储（加盐）、数字签名第一步 |
| 加签 | 用私钥对摘要加密，生成数字签名，证明身份和数据的不可否认性 | RSA + SHA-256, ECDSA | 软件发布、合同签署、区块链交易 |
| 验签 | 用公钥解密签名得到摘要，与原文摘要对比，验证签名真实性 | 同上 | 验证文件来源、交易合法性 |
技术结合使用场景
HTTPS（TLS/SSL）
密钥交换：非对称加密（如RSA或ECDHE）协商对称密钥
数据传输：对称加密（如AES）加密通信内容
完整性校验：摘要算法（如果SHA-256）确保数据未被篡改
身份认证：服务器用私钥加签证书，客户端用CA公钥验签
数字签名（如PDF/代码签名）
发送方：
用摘要算法（SHA-256）生成文件哈希
用私钥加密哈希，生成签名
接受方：
用公钥解密签名得到哈希1
计算文件哈希2，对比哈希1和哈希2
加密+签名组合（安全通信）
场景：既要保密又要验证身份（如加密邮件）
步骤：
用对称加密（AES）加密原文
用接受方公钥（非对称）加密对称密钥
用发送方私钥对加密后的数据加签
接收方先通过发送方的公钥验签，在用自己的私钥加密对称密钥，最后通过对称密钥解密数据
密码存储
安全的做法：
用户密码+随机盐 --> 摘要算法（如Argon2、PBKDF2） --> 存储哈希值
避免使用MD5等弱哈希
关键区别总结
| 维度 | 对称加密 | 非对称加密 | 摘要算法 | 签名/验签 |
| 密钥 | 同一密钥 | 公钥+私钥 公钥加密，私钥解密 | 无密钥 | 私钥签名，公钥验签 |
| 速度 | 快（适合大数据） | 慢（适合小数据） | 极快 | 慢（依赖非对称加密） |
| 安全性问题 | 密钥分发难 | 需保护私钥 | 抗碰撞性要求 | 私钥泄露导致身份伪造 |
| 是否可逆 | 可逆 | 可逆 | 不可逆 | 签名可验但不可逆 |
理解这些概念的区别主要注意以下两点：
一是对SHA-256等摘要算法有明确概念，这部分算法不属于加密算法，是摘要算法。
二是对于RSA这类非对称加密算法，公钥加密、私钥解密；私钥加签，公钥验签。
注意事项
密钥管理：
非对称加密的密钥必须严格保密，对称加密需安全渠道分发密钥。
算法选择：
避免MD5/SHA-1（已不安全），推荐SHA-256或SHA-3摘要算法
非对称加密优先选择ECC（比RSA更高效）
性能权衡：
实际应用中常结合对称和非对称加密（如HTTPS）
实战使用
如果现在有一个需求，一个用户支付场景，用户在客户端输入密码后，后端如何安全存储，如何验证？
如何保存密码？
- 用户输入密码，明文或者加密或者摘要算法将其通过HTTPS传输给后端
- 后端生成一个随机盐值，与用户密码拼接
- 使用强哈希算法（如PBKDF2、bcrypt、Argon2）对【密码+盐值】进行多次迭代计算，生成不可逆的哈希值
- 将哈希值、盐值、算法类型、迭代次数等存入数据库，明文密码不存储
如何验证密码？
- 用户输入密码，根据统一的规则将明文或初步处理后的密码传输到服务端
- 查询用户密码相关数据，哈希值、颜值、算法类型、迭代次数等
- 根据传入的密码再次通过相同的计算步骤计算出新的哈希值，用此哈希值和数据库中的哈希值做对比，一致的验证通过