常用.NET加密算法及实战实现
咱们先从最常用的三种加密类型说起：对称加密、非对称加密和哈希算法。每种算法就像不同的“锁”，用对了才安全。我去年帮一个电商项目做支付接口加密时，他们最初用的是DES对称加密，结果第三方渗透测试直接指出“算法过时，存在被暴力破解风险”，后来换成Aes才通过。所以选对算法是第一步。
对称加密：高效加解密的“万能钥匙”
对称加密就像你家门钥匙，加密和解密用同一个密钥，速度快、适合大量数据。.NET里最推荐的是Aes（高级加密标准），替代了老的DES和3DES。我记得前年有个政府项目，他们图省事用了DES，结果密钥长度只有56位，被测评机构要求整改——现在Aes的密钥长度至少要128位，推荐256位。
实现Aes其实很简单，你跟着这个步骤来：
给你看段我项目里用过的代码片段，这段是用户手机号加密存储的实现：
public static (byte[] cipherText, byte[] iv) AesEncrypt(byte[] plainText, byte[] key)
{
using (var aes = Aes.Create())
{
aes.Key = key; // 256位密钥（32字节）
aes.Mode = CipherMode.CBC;
aes.Padding = PaddingMode.PKCS7;
aes.GenerateIV(); // 随机生成IV
using (var encryptor = aes.CreateEncryptor(aes.Key, aes.IV))
using (var ms = new MemoryStream())
{
using (var cs = new CryptoStream(ms, encryptor, CryptoStreamMode.Write))
{
cs.Write(plainText, 0, plainText.Length);
cs.FlushFinalBlock();
}
return (ms.ToArray(), aes.IV); // 密文和IV都要保存，解密时需要
}
}
}
这里有个关键：IV向量必须和密文一起存储，解密时要用同一个IV。我见过有人加密时没存IV，解密时随便生成一个，结果当然解不出来，折腾了半天才发现问题。
非对称加密：安全传输的“公私钥组合”
非对称加密有两把钥匙：公钥（公开给别人加密）和私钥（自己保留解密），就像你寄快递，别人用你的公钥“锁箱子”，只有你能用私钥“打开”。适合小数据加密，比如传输对称加密的密钥，或者做数字签名。.NET里最常用的是RSA，我做过的API接口签名验证基本都用它。
实现RSA要注意两点：密钥长度至少2048位（推荐4096位），私钥绝对不能泄露！之前帮一个金融项目做对接，对方把RSA私钥放在前端代码里，被我们安全审计发现，差点造成重大风险。正确的做法是：服务端生成密钥对，公钥给客户端加密，私钥存在安全的地方（比如Azure Key Vault）。
密钥生成的代码可以这样写（记得用完释放资源，避免内存泄露）：
public static (string publicKey, string privateKey) GenerateRsaKey()
{
using (var rsa = RSA.Create(4096)) // 4096位密钥
{
var publicKey = rsa.ToXmlString(false); // 仅公钥
var privateKey = rsa.ToXmlString(true); // 包含私钥
return (publicKey, privateKey);
}
}
实际项目里，我 用XML或PEM格式存储密钥，别自己瞎存字符串，.NET的ToXmlString和FromXmlString方法很方便。
哈希算法：数据完整性的“指纹验证”
哈希算法就像给数据生成“指纹”，不管原始数据多长，都会输出固定长度的哈希值，而且不可逆（无法从哈希值反推原始数据）。适合存储密码（存哈希而不是明文）、验证文件是否被篡改。.NET里别用MD5（早被破解）和SHA1（不安全），至少用SHA256，推荐SHA512。
这里有个坑：单纯的哈希不安全！比如用户密码存SHA256哈希，黑客拿到哈希表后，用彩虹表（预计算的哈希值对照表）一查就能破解。正确做法是加盐哈希——给每个密码加一个随机“盐值”（salt），再哈希。我之前帮一个社区网站重构时，他们老系统直接存MD5哈希，结果数据库泄露后，用户密码全被破解，后来改成“盐值+SHA512+迭代次数”才安全。
ASP.NET Core自带的PasswordHasher其实已经帮你做好了这些，直接用就行：
var hasher = new PasswordHasher如果你需要自己实现，记得盐值要随机生成（每个密码不同），迭代次数至少10000次（越多越安全，但性能会降，平衡一下）。
.NET加密安全最佳实践与避坑指南
知道了怎么实现算法，更重要的是怎么用得安全。我见过太多项目，算法用对了，但密钥管理、参数配置出问题，照样被攻击。这部分我整理了几个实战中必须注意的点，都是血和泪的教训。
密钥管理：加密安全的“命门”
密钥丢了，加密就等于白做。我19年做的一个项目，开发者图方便把Aes密钥直接写在代码里（就是const string key = "123456..."这种），结果代码提交到GitHub公开仓库，被人扒出来导致数据泄露。现在想起来都后怕，后来我们紧急换了密钥，并用Azure Key Vault管理，才解决问题。
给你几个密钥管理的实用方法，按优先级排：
ProtectedData类加密配置文件），别存在代码、数据库或配置文件明文里； 算法和参数选择：别让“安全”变“隐患”
选对算法后，参数配置错了也会出问题。比如Aes的模式用ECB、RSA密钥长度1024位、哈希不用盐值，这些都是常见错误。我整理了一个表格，帮你快速判断怎么选：
| 应用场景 | 推荐算法 | 关键参数 | 安全等级 |
|---|---|---|---|
| 敏感数据存储（如手机号、身份证） | Aes | 256位密钥，CBC模式，PKCS7填充，随机IV | 高 |
| API接口签名/数据传输 | RSA + SHA256 | 4096位密钥，公钥加密/验签，私钥解密/签名 | 高 |
| 用户密码存储 | PBKDF2/SHA512 | 随机盐值，迭代次数≥100000，哈希长度≥256位 | 极高 |
表：.NET加密算法场景及参数推荐（数据参考自微软.NET安全最佳实践文档）
常见错误及避坑案例
最后说几个实战中最容易踩的坑，你看完可以自查下项目有没有类似问题：
我上个月帮朋友的SaaS项目做安全加固，他们就犯了“密钥硬编码”和“ECB模式”两个错，后来按上面的方法改了，第三方测评一次性通过。其实加密不难，关键是细节做到位。
如果你在项目里用了这些方法，或者遇到其他加密相关的问题，欢迎在评论区告诉我你的情况——比如你是怎么管理密钥的？有没有踩过什么特别的坑？咱们可以一起交流避坑经验。
选加密算法这事儿，其实就像挑工具，不同的活儿得用不同的家伙，用对了效率高还安全，用错了可能白费劲。你想啊，要是给大门配一把小挂锁，或者给抽屉配一把防盗门的锁，都不合适对吧？加密算法也一样，得看你要加密啥、数据量多大、对速度和安全性的要求是啥。
先说对称加密，这玩意儿就像家里的钥匙，一把钥匙开一把锁，加密解密都用同一个密钥，最大的好处是快，处理大量数据特别给力。就拿Aes来说吧，现在基本都用它替代老掉牙的DES了，密钥长度至少128位，推荐256位，我之前帮一个电商平台做用户数据加密，他们有几百万用户的手机号、地址要存数据库，用Aes加密，每秒能处理上万条数据，完全不影响系统性能。不过它有个小麻烦：密钥得安全传给解密方，要是密钥丢了，加密就白搭，所以适合那种加密解密都在自己系统里的场景，比如服务器存用户敏感信息。
再说说非对称加密，这就像快递柜，你把东西放进去（加密）用的是公开的取件码（公钥），但只有柜子主人（私钥持有者）能用自己的钥匙打开。它安全是安全，但速度慢，数据量大了根本扛不住。RSA就是典型代表，现在常用在数字签名或者小数据加密上，比如API接口的签名验证——客户端用私钥签名，服务器用公钥验签，确保请求没被篡改。我之前帮一个政府项目做接口安全，他们要求“防篡改、防抵赖”，就用RSA给每个请求生成签名，效果挺好，就是别拿它加密大文件，试过用RSA加密10MB的文件，等了半分钟还没好，最后换成“RSA加密Aes密钥+Aes加密文件”的组合才解决。
最后是哈希算法，这玩意儿跟前面俩不一样，它是单向的，加密了就解不回来，像给数据盖个章，主要用来验证“这东西是不是原来的样子”。比如SHA256、SHA512，现在没人用MD5了（早被破解了）。最常见的场景就是存密码——你注册网站时输的密码，服务器不会存明文，而是存哈希值，登录时把你输的密码哈希一下，跟存的比对，对得上就登录成功。不过光哈希还不够，得加盐（加个随机字符串），不然黑客弄个彩虹表（提前算好的哈希对照表）一查就知道你密码是啥。我去年帮一个社区论坛改版，他们老系统直接存SHA1哈希，结果数据库泄露后用户密码全被破解，后来改成“随机盐+SHA512”，才算安全了。
其实实际项目里很少只用一种算法，大多是组合着来。比如支付系统传输订单数据：先用Aes加密订单详情（量大，速度快），再用RSA加密Aes的密钥（小数据，安全），最后用SHA256生成整个数据包的哈希值（验证完整性）。你看，这样既保证速度，又兼顾安全，还能防篡改。我之前帮一个跨境支付项目搭加密流程，就是这么组合的，第三方审计一次性通过，所以选算法别死磕一种，得看场景混搭着用。
如何根据业务场景选择合适的.NET加密算法？
选择加密算法主要看数据类型和使用场景：对称加密（如Aes）适合大量数据加解密（如用户敏感信息存储），速度快但密钥需安全共享；非对称加密（如RSA）适合小数据加密（如传输对称密钥、数字签名），安全性高但性能较低；哈希算法（如SHA256）适合数据完整性验证（如密码存储、文件校验），不可逆且能生成固定长度哈希值。例如支付接口传输订单数据可用Aes加密，API签名验证用RSA，用户密码存储用“盐值+SHA512”哈希。
在.NET项目中，如何安全存储加密密钥？
密钥是加密安全的核心，不 硬编码在代码或配置文件中。推荐方案：
为什么Aes加密时IV向量必须随机生成，不能固定？
IV（初始化向量）的作用是避免相同明文加密出相同密文，增强加密安全性。若IV固定（如全0或硬编码），攻击者可通过对比密文规律反推明文特征（例如ECB模式+固定IV时，相同明文加密结果完全一致）。根据.NET安全最佳实践，Aes加密需每次生成随机IV（通过GenerateIV()方法），并与密文一起存储（解密时需用同一IV）。实际项目中，可将IV和密文拼接存储（如“IV字节数组+密文字节数组”），解密时拆分使用。
用户密码存储时，为什么哈希算法需要加盐？盐值需要满足什么条件？
单纯哈希（如直接用SHA256加密密码）存在风险：攻击者可通过彩虹表（预计算的哈希值对照表）反推明文。加盐能让相同密码生成不同哈希值，即使彩虹表也无法匹配。盐值需满足两个条件：
加密操作会影响系统性能吗？如何在安全和性能之间平衡？
加密确实会消耗一定系统资源（尤其是非对称加密和高迭代哈希算法），但可通过合理设计平衡：
