📚 课程目录第3章密码学基础

第3章密码学基础：非对称加密与哈希

做渗透测试这么多年，有个事儿我一直记着。有次拿到一个系统的备份文件，想着分析一下用户数据。结果发现密码字段存的是明文。说实话，我当时都愣住了。这都什么年代了，还在用明文存密码？后来我帮他们改造成了加盐哈希，才算是把洞补上了。

你看，密码学这东西，说难不难，说简单也不简单。但我发现很多人其实没搞明白几个核心概念。比如哈希和加密有什么区别？RSA和ECC用哪个好？SHA-1还能不能用？

这一章，咱们就把这些事掰扯清楚。

对称加密就像你用一把钥匙锁门，也用同一把钥匙开门。但问题来了——你怎么把这把钥匙安全地交给对方？

非对称加密就是为了解决这个传输问题。它用一对密钥：公钥公开，私钥自己留着。公钥加密的数据只能用私钥解密，反过来私钥签名的数据可以用公钥验证。

我建议你把这个关系记牢了：公钥加密，私钥解密；私钥签名，公钥验证。搞反了，整个系统就废了。

测试小技巧：验证一个非对称加密实现是否正常，最简单的办法就是加密一段固定字符串，再用对应的私钥解密，看结果是否一致。反过来，用私钥签名，公钥验签也一样。

RSA应该是大家最熟悉的非对称加密算法了。它基于大整数分解的数学难题——两个大质数相乘容易，但反过来分解就很难。

我记得最早做渗透测试时，见过一个系统还在用512位的RSA密钥。我用一台普通笔记本，跑了个开源工具，不到一上午就分解了。你能想象那个场景吗？整个系统的安全依托瞬间崩塌。

所以现在行业公认：至少2048位，推荐4096位。1024位已经可以被中等资源攻击者破解了。

避坑提醒：我曾经在一个政府项目中看到，他们虽然用了2048位的RSA，但随机数生成器出了问题。每次重启服务器，生成的密钥对都一样。说白了，再长的密钥，随机性不行也白搭。测试时一定要检查随机源。

ECC（椭圆曲线密码学）这玩意儿，说白了就是用椭圆曲线上的点群运算来实现加密。它最大的优势就是密钥短，性能高。

举个具体的对比：256位的ECC可以提供和3072位RSA相当的安全性。这在移动设备、IoT等资源受限的场景下，优势太明显了。

我在做车联网项目的渗透测试时，就遇到过他们用ECC签名的场景。车载芯片算力有限，如果用RSA做签名，一次操作就要几百毫秒，用户体验极差。换成ECC后，几十毫秒就搞定了。

哈希是个容易被误解的概念。很多人管它叫"哈希加密"，这是错的。哈希是单向的，不可逆的。你无法从哈希值反推出原文。

哈希的三大特性必须记住：

你想想看，如果一个哈希实现出了问题，比如MD5已经被找到快速碰撞的方法，那用它来做数字签名或者密码存储，后果有多严重？

SHA系列是当前最主流的哈希算法。但版本之间差别不小。

  核心建议：新系统优先选择SHA-256。它既有足够的安全边际，性能消耗也在可接受范围内。SHa-1已经不建议使用了，我在一个老旧系统的升级检查中就发现他们还用SHA-1做完整性校验，马上给他们开了高危工单。

安全边际这个概念，我估计很多人理解得片面。你以为只有密钥长度才叫安全边际？

举个例子，你用了4096位的RSA，但你的私钥文件权限是777，任何用户都能读。这不等于把家里的钥匙放在大门口吗？

真正的安全边际，应该从这几个维度衡量：

我个人习惯在渗透测试中，专门拿一个清单去检查这些维度。只要有一条不合格，这个系统的安全边际就是虚的。

警惕"迷信"算法：有些开发者觉得用了AES-256就万事大吉了。我曾经碰到一个项目，他们的确用了AES-256加密，但IV用的是全零向量。结果是什么？同样的明文会加密成同样的密文。这不就把AES降级成电子密码本模式了吗？安全边际从来都不是单一算法的事。

下面这张图把非对称加密和哈希的核心关系梳理出来了。我建议你多看几遍，把流程刻在脑子里。

我每次做安全评估，都会把这张图翻出来对一遍。看看每个环节有没有疏漏。你也试试？

第3章 密码学基础：非对称加密与哈希