Whitfield Diffie 的公钥突破：为网页与身份打开的大门

公钥密码学为什么改变了日常安全

每次你登录银行、在网上购物或发送私密消息时，你都依赖一个简单的想法：你可以在别人可以监听的网络上共享信息，同时把重要部分保密。

现在这听起来理所当然，但过去这是个实际的问题。如果两个人想使用加密，他们首先必须约定一个共享的秘密密钥。安全地传递这个密钥常常需要可信的信使、预先约定的会面或受保护的公司网络——这些方式都无法扩展到互联网上成千上万的陌生人。

公钥密码学改变了规则。它引入了一种可以公开发布一个密钥（公钥）并同时保留另一个密钥私密（私钥）的方法。有了这种分工，你可以在不事先共享秘密的情况下开始建立安全关系。Whitfield Diffie 在把这一突破公之于众并解释其重要性方面起到了关键作用。

本指南你将学到什么

我们会把核心概念和你实际使用的东西联系起来：

• 网页（HTTPS/TLS）： 浏览器如何与一个从未访问过的网站安全通信。\
• 安全消息： 端到端加密为何以密钥交换作为第一步。\
• 数字身份： 如何用密钥和签名把“证明你是谁”从密码扩展开来。

会有多技术化？

你会得到通俗解释，并有足够的数学直觉来理解为什么这些技巧有效——但不会变成教科书。目标是让公钥密码学不再像魔法，而更像安静地保护日常生活的实用工具。

在 Diffie 之前：用通俗话说的密钥共享问题

在公钥密码学出现之前，安全通信主要意味着对称加密：双方使用相同的秘密密钥来锁定和解锁消息。

对称加密的简单类比

把它想象成一个挂锁和一把共享钥匙。如果你我都有相同钥匙的复制品，我可以锁上一个箱子寄给你，你就能打开。只要我们事先都有那把钥匙，锁和开都是简单的。

密钥分发问题

问题显而易见：我们首先如何安全地共享那把钥匙？ 如果我通过电子邮件发送，可能会被拦截；短信也一样。把它放进密封信封邮寄可行，但不适合大规模、频繁的情况——慢、昂贵、且不总是可靠。

这造成了一个“先有鸡还是先有蛋”的难题：

• 要安全通信，我们需要共享秘密密钥。\
• 要安全地共享该密钥，我们已经需要一个安全通道。

在互联网规模下为什么更糟

当只有少数人且可以提前交换密钥时，对称加密运作良好。但在开放的互联网环境中，它很快失效。

想象一个网站需要与数百万个访客建立私密连接。如果只用对称密钥，网站需要为每个访客准备不同的秘密密钥，并且要有安全的方式分发每一个密钥。密钥数量以及管理它们（创建、存储、轮换、撤销）的后勤工作会成为重大负担。

对称密码仍然很适合的场景

这并不意味着对称加密“糟糕”。它在其擅长的领域表现出色：对大数据量的快速高效加密（比如 HTTPS 中的大部分流量）。Diffie 出现前的挑战不是速度——而是缺少一个实用的方法，能让陌生人在不提前共享秘密的前提下达成一致。

Whitfield Diffie 与公钥/私钥的核心思想

在 1970 年代初期，安全通信主要依赖共享秘密。两个人如果想使用加密，必须拥有相同的秘密密钥，并找到安全的方式交换它。这个假设在小范围、受控环境中可行，但无法扩展到需要与陌生人安全通信的世界。

人物与时代

Whitfield Diffie 是一位对隐私和当时密码学实际局限感兴趣的年轻研究员。他与斯坦福的 Martin Hellman 建立了联系，他们的工作受益于学术界对计算机安全和网络日益增长的关注——这些领域正从孤立系统向互联走去。

这不是孤立天才的故事，而是恰当的想法遇上恰当的环境：研究者交换观点、做思想试验、质疑长期以来被普遍接受的“显而易见”的限制。

核心洞见：把密钥分成两类角色

Diffie 和 Hellman 的突破在于意识到加密可以使用两把相关但不同角色的密钥而不是一把共享秘密：

• 一个可以公开分享的公钥。\
• 一把必须由拥有者保密的私钥。

它强大的地方不仅在于两把密钥的存在，而在于它们承担不同的功能。公钥用于安全分发，私钥用于控制与独占。

从秘密交换到公开密钥系统

这重塑了密钥共享问题。与其安排秘密会面或可信信使去交换一把秘密钥匙，不如广泛发布公钥，同时保持安全。

这个转变——从“我们必须先共享秘密”到“我们可以用公开信息安全地开始对话”——是后来支持安全网页浏览、加密消息和现代数字身份系统的概念基础。

Diffie–Hellman 密钥交换：在公开环境下达成秘密

Diffie–Hellman（DH）是一种巧妙的方法，允许两个人在所有消息都可见的情况下创建相同的共享秘密。然后这个共享秘密可以被用作常规对称密钥来加密会话。

核心想法（无需深奥数学）

把 DH 想象成按某种方式混合配料，向前混合很容易，但“逆向分离”却极其困难。配方使用：

• 一组人人可知的公共参数（像是可复用的“配方风格”）\
• 每一方私下随机选择的私有值（他们的秘密配料）

步骤演示

1. 公共设置： Alice 和 Bob 同意一组公共参数。这些不是秘密，可以被多人复用。\
2. 私有选择： Alice 生成一个新的随机私有值，Bob 也生成自己的私有值。\
3. 公有共享： Alice 用她的私有值和公共参数计算出一个公有“交换值”，并把它发给 Bob；Bob 同样做并把他的公有值发给 Alice。\
4. 双方得到相同的秘密： Alice 用 Bob 的公有值和她的私有值计算共享秘密；Bob 用 Alice 的公有值和他的私有值计算，结果是同一个共享秘密。

攻击者能看到什么（以及为什么仍然安全）

窃听者可以看到公共参数和双方交换的公有值。但仅凭这些公有信息，几乎不可能恢复任一私有值或计算出共享秘密。使用恰当的参数，逆向过程需要不切实际的计算资源。

实务要点

• 参数： 真实系统使用经过标准化和审查的 DH 群（或现代的椭圆曲线版本 ECDH）以避免弱设置。\
• 新鲜性： 每次会话使用新的临时私有值可提供前向保密——即使长期密钥泄露，过去的通信仍能保持安全。\
• 随机性： 私有值必须真正不可预测；随机性弱会破坏整个交换的安全。

DH 本身不对消息加密——它产生了让快速、日常加密成为可能的共享密钥。

数学直觉：向前容易、向后困难

公钥密码学之所以有效，是因为某些数学运算具有“非对称性”：做起来很容易，但若没有特定的秘密就极难逆运算。

单向函数与“困难问题”

一个有用的心理模型是“单向函数”。想象一个机器能把输入快速转换成输出，任何人都能运行这个机器，但仅凭输出要找回原始输入在实际中几乎不可能。

在密码学中，我们不依赖机器本身的保密性，而依赖于逆向需要解决一个被认为极其耗费计算资源的困难问题。

“困难”真正的含义

“困难”并不意味着永远不可能，而是指：

• 可行的：你可以用今天的计算资源在合理时间内完成（秒、分钟、小时）。\
• 不可行的：成本极高，使得尝试无利可图（需要多年到百万年计算时间、巨大的能源和硬件）。

因此安全基于假设（数学家与密码学家对这些问题的信念）和现实实践（密钥长度、可靠实现与最新标准）。

可选插页：用通俗语言理解模运算

许多公钥数学发生在“模”某个数的环境下——把它想成时钟。

在 12 小时制时钟上，若现在是 10 点再加 5 小时，你不是得到 15，而是回绕到 3。那种回绕行为就是模运算。

对大数进行重复的“回绕”操作会产生看似混乱的输出。向前运算（做算术）很快，向后推（找回起始值）在没有秘密捷径（比如私钥）的情况下可能非常缓慢。

这种“向前易、向后难”的差距是密钥交换与数字签名背后的动力。

这如何使 HTTPS 成为可能：TLS 利用公钥做什么

当你在浏览器看到挂锁时，通常是在使用 HTTPS：这是你设备与网站之间的加密连接。如果每个浏览器都必须与每个服务器预先共享秘密密钥，网页就无法扩展到数十亿的安全连接。

公钥密码学解决了“第一次接触”问题：它让你的浏览器能与一个从未见过的服务器安全地建立共享密钥。

TLS 的简单步骤（握手发生了什么）

现代 TLS 握手是一个快速协商，建立隐私与信任：

1. Hello 与选项： 浏览器连接并声明它支持哪些加密版本与算法。\
2. 服务器证明身份（通常）： 服务器发送包含其公钥的证书，浏览器检查该证书是否能链回到受信任的颁发者。\
3. 公开的密钥协商： 使用带认证的密钥协商（如 (EC)DHE），双方创建共享密钥。窃听者可以看到交换但无法计算相同的秘密。\
4. 派生会话密钥： 共享秘密被转换为短期密钥用于加密与完整性保护。\
5. 开始加密流量： 从此之后，连接受到保护。

为什么先用公钥，然后切换到对称加密

公钥运算较慢，设计用于协商和认证，而非大体量数据。TLS 建立会话密钥后，会切换到快速的对称加密（如 AES 或 ChaCha20）来保护实际传输的内容。

如果你想要 HTTP 与 HTTPS 的通俗区别，请参见 /blog/https-vs-http。

数字签名：证明是谁发的（以及内容未被篡改）

数字签名是用于让消息可“证明”的公钥工具。当某人用他们的私钥对文件或消息签名时，任何人都可以用对应的公钥来验证该签名。

一个有效签名证明两件事：

• 真实性： 它由持有该私钥的人创建（即预期的发送方）。\
• 完整性： 自签名以来内容未被修改。

加密与签名：隐私与证明

这两者常被混淆：

• 加密关注隐私，把内容隐藏起来，只有预期接收者能读。\
• 签名关注证明，它不一定隐藏任何东西；而是附上一个篡改可察的印记，以便日后验证。

两者可以单独使用。比如一次公开公告可以被签名（让人们信任它），但不加密（因为它需要被所有人阅读）。

你日常能看到签名的地方

数字签名出现在你可能每天使用的场景：

• 软件更新： 设备检查更新是否由厂商签名且在传输途中未被修改。\
• 合同与 PDF： 签名可以证明是谁批准了文档以及签署版本就是商定内容。\
• 邮件签名（S/MIME 或 PGP）： 收件人可以验证邮件确实来自你且在传输中未被编辑。

在不共享秘密的情况下建立信任

签名的关键优势是验证不需要共享秘密。签名者一直保管私钥，而公钥可以广泛分发。这种私钥用于签名、公开用于验证的分离，使得陌生人可以在不先约定密码或秘密密钥的情况下在大规模上验证消息。

证书与 PKI：把密钥变成受信任的身份

公钥密码学解决了“我们如何共享秘密”的问题，但留下了另一个问题：**这把公钥到底是谁的？**单独的公钥只是一个长数字。你需要一种可靠的方法把这个密钥附着到真实世界身份上，比如“我的银行”或“这家公司 的邮件服务器”。

证书是什么（以及为什么存在）

数字证书是一份签名文件，意思是：“这个公钥属于这个身份。”它包含站点或组织名称（和其他信息）、公钥以及到期时间。重要部分是签名：受信任方对证书签名，设备可以检查签名以确认证书未被篡改。

证书颁发机构与信任链

这个受信任的方通常是一个证书颁发机构（CA）。你的浏览器和操作系统预装了一份受信任 CA 根列表。当你访问网站时，网站会出示其证书和中间证书，形成一条信任链回到设备已经信任的根 CA。

一个可感知的例子：银行网站的“锁”图标

当你输入银行的网址并看到锁图标时，浏览器已经检查：

• 证书是否与当前访问的站点名称匹配\
• 证书是否有效且未过期\
• 证书链是否可以追溯到受信任的 CA\
• 服务器能否证明其控制与证书公钥匹配的私钥

如果这些检查都通过，TLS 就能安全使用该公钥进行认证并帮助建立加密连接。

需要注意的限制与失败情况

PKI 并非完美。CA 可能出错或被攻破，导致错误签发（为错误实体签发证书）。证书会过期，这有助于安全但若未及时续期会阻断访问。撤销（告知全网某证书不再可信）在互联网规模上也很棘手，浏览器并不总是一致地强制执行撤销检查。

安全消息传递：端到端加密的核心是密钥交换

端到端加密（E2EE）消息的目标很简单：只有会话中的参与者能读消息。应用提供者、运营商或网络监听者都不能读。

“安全消息”期望实现的目标

现代聊天应用通常在平衡三个目标：

• 机密性： 外人无法读取消息。\
• 真实性与完整性： 你能确定消息确实来自你的联系人且在传输中未被篡改。\
• 前向保密： 如果某个密钥后来被盗，过去的消息仍保持受保护。

为什么密钥交换是第一步

加密需要密钥。但两个从未见过面的人不应必须事先共享秘密——否 则又回到原始的密钥共享问题。

公钥密码学解决了初始建立的问题。在许多 E2EE 系统中，客户端使用基于公钥的交换（沿用 Diffie–Hellman 的思路）在不受信任的网络上建立共享秘密。那些秘密随后被用于快速对称加密来保护实际消息流量。

用通俗话说的前向保密

前向保密意味着应用不依赖于一个长期密钥维持所有历史，而是不断刷新密钥——通常按会话甚至按消息刷新——这样就算某个密钥被破解，也无法解密整段历史。

这就是为什么“现在偷走设备，明天解密多年聊天记录”在实现了前向保密的系统里变得更加困难。

用户体验上仍存在的摩擦

即便密码学很强，现实仍然带来摩擦：

• 密钥验证： 安全号码/二维码有效，但很多用户跳过这些步骤。\
• 备份： 加密备份很复杂——为了方便的备份可能会削弱 E2EE（如果密钥处理不当）。\
• 新设备与重置： 换手机、恢复账户或新增设备会触发重新密钥化并弹出令人困惑的“安全码已更改”提示。

从底层看，安全消息的故事主要是密钥交换与密钥管理的故事——因为正是它们把“加密”变成“即使网络不可信也私密”。

数字身份：从密码到基于密钥的登录

数字身份是你在使用服务时“你是谁”的线上版本：你的账户、登录方式，以及证明这确实是你（而不是猜到或偷到密码的人）的信号。多年来，大多数系统把密码当作证明——简单、熟悉，但也容易被钓鱼、重用、泄露或暴力破解。

公钥密码学提供了另一种方法：你不再证明你知道一个共享秘密（密码），而证明你控制一个私钥。服务可以保存你的公钥，而私钥则由你保管。

无密码登录的通俗解释

在基于密钥的登录中，服务发送一个质询（随机数据）。你的设备用私钥对其签名。服务用你的公钥验证签名。无需密码通过网络传输，也没有可被攻击者从登录表单中重复利用的凭证。

这个想法支撑了现代“无密码”体验：

• 通行证（FIDO2/WebAuthn）： 你的手机或笔记本保存私钥，通常受生物识别或 PIN 保护。你通过批准提示完成认证，设备对质询签名。\
• 基于设备的密钥： 安全硬件（如 TPM 或 Secure Enclave）可以生成并保护私钥，使其不能像文本密码那样被复制出来。

超越人类登录：API 身份

公钥身份也适用于机器。例如，API 客户端可以用私钥对请求签名，服务器用公钥验证——这对服务间认证很有用，因为共享 API 密钥难以轮换且易泄露。

如果你想更深入了解真实世界的部署与用户体验，请参见 /blog/passwordless-authentication。

可能出错的地方：实现、密钥与人为因素

公钥密码学很强大，但并非魔法。许多现实失败并不是数学被攻破，而是系统周边出现问题。

常见风险（容易破坏安全的“乏味”环节）

随机性弱会悄然毁掉一切。如果设备在早期引导、虚拟机或受限物联网硬件上生成可预测的随机数，攻击者可能重构出秘密。

实现缺陷也是常见原因：使用过时的算法、跳过证书验证、接受弱参数或错误处理不当。即便是临时的“关掉 TLS 校验以便调试”的捷径，也常常被带入生产环境。

钓鱼与社会工程能完全绕过密码学。如果用户被骗去批准登录、泄露恢复码或安装恶意软件，强大的密钥也无济于事。

密钥管理：私钥是王冠上的宝石

私钥必须以难以被复制的方式存储（理想状态放在安全硬件中），并在静态时加密保护。团队还需要为备份、轮换和撤销制定计划——因为密钥会丢失、设备会被盗、人员会离职。

可用性与安全（不把用户当作替罪羊）

如果安全流程令人困惑，人们会想办法绕过它：分享账户、重用设备、忽略警告或把恢复码存放在不安全的地方。良好的安全设计应减少“决策点”，并使安全行为成为最简单的选项。

给产品团队的实用建议

• 使用经过审查的库与默认配置；避免自写加密代码。\
• 强制使用现代 TLS 设置并正确验证证书。\
• 用可靠的 CSPRNG 生成密钥；添加健康检查与监控。\
• 把私钥存放在操作系统钥匙库或 HSM 中；限制导出。\
• 设计安全的恢复机制：恢复应安全、限速且可审计。\
• 为密钥泄露规划轮换与应急响应。\
• 把钓鱼视为核心威胁：增加设备绑定、逐步验证与清晰的用户提示。

这与现代开发流程的交汇（包括 Koder.ai）

如果你在快速构建与发布软件，最大风险常常不是密码学本身，而是不同环境间配置不一致。像 Koder.ai 这样的工具（从聊天界面生成网页、服务与移动应用的 vibe-coding 平台）能加速交付，但公钥的基本规则依旧适用：

• 当你在自定义域名下部署应用时，确保端到端 TLS 正确配置并自动续期证书。\
• 把私钥与签名密钥当作生产密钥管理：不要放进源码控制，收窄访问权限，优先使用托管的密钥存储。\
• 有意识地使用快照与回滚：它们便于快速恢复，但要确保密钥轮换和证书状态在回滚中不会不同步。\
• 导出源码时保持相同标准：现代 TLS 默认、安全严格的证书校验，不要留下“调试时关闭”的暂时绕过。

简言之：更快的构建并不改变规则——Diffie 的思想仍是用户第一次连接时获取信任的基石。

持久影响与公钥密码学的下一步

Diffie 的突破不仅仅增加了一个新工具——它改变了安全的默认假设：从“我们必须先见面”到“我们可以在开放网络上安全地开始对话”。这一转变使数十亿设备与陌生人能够快速创建秘密、证明身份并在互联网规模上建立信任。

现代继承者：相同思想，更高效率

原始的 Diffie–Hellman 仍是基础，但大多数现代系统使用改进版本。

椭圆曲线 Diffie–Hellman（ECDH）保持了“在公开环境中达成共享秘密”的目标，同时使用更短的密钥与更快的运算。RSA 在 Diffie 之后不久发展起来，并在早期的网页安全中因可用于加密和签名而闻名；今天它被更谨慎地使用，而椭圆曲线签名和 ECDH 更为常见。

几乎每个现实部署都是混合方案：公钥方法处理握手（认证与密钥协商），然后快速的对称加密保护大部分数据。这种模式让 HTTPS 即能安全又能高效。

后量子时代：准备而非恐慌

未来量子计算可能削弱今天广泛使用的公钥技术（尤其基于因数分解和离散对数的问题）。实用的方向是“增加新选项并安全迁移”，而不是立刻全部替换。许多系统正在测试后量子的密钥交换与签名，同时保持混合设计，以便在不把所有赌注压在单一算法上的情况下获得新保护。

不变的要点

即使算法变化，核心问题仍然相同：在可能从未见面的各方之间快速、全球性地交换秘密与信任，并尽量减少用户摩擦。

要点回顾： 公钥密码学使得安全的第一次接触成为可能；混合方案让其在规模上可用；下一阶段是谨慎演进。

下一篇阅读： /blog/diffie-hellman-explained, /blog/tls-https-basics, /blog/pki-certificates, /blog/post-quantum-crypto-primer