伦纳德·阿德尔曼与 RSA：互联网如何学会信任

为什么 RSA 对日常互联网信任很重要

当人们说他们“信任”一个网站或在线服务时，通常指三个实际层面的东西：

• 隐私： 在互联网上传输时，陌生人无法读取你的消息、密码或支付信息。
• 身份： 你确实在和你的银行（或那家商店）交互，而不是冒充者。
• 完整性： 你收到的内容没有被悄悄篡改——无论是登录页面、银行转账请求，还是软件更新。

RSA 因为帮助在互联网规模上实现这些承诺而出名。

RSA 帮助启用的日常系统

即便你从未听过这个名字，你也感受过 RSA 的影响。它与以下方面密切相关：

• HTTPS 保护了浏览器与网站之间的许多连接（浏览器中“挂锁”概念）。
• 网上银行 从“也许别在网上做”变成了数百万人依赖的服务。
• 签名软件 和更新可以证明它们来自真实的发布者并且在传输过程中未被篡改。

共同点是：在没有事先认识（或预先共享秘密）的情况下，实现对服务器和软件供应商的信任。

本指南的阅读期望

本文将解释要点：不涉及高深数学，也不需要计算机科学背景。我们关注日常层面的“为什么可以工作”。

关键思路：两把钥匙，两种角色

RSA 推广了一种强大的方法：不用一把共享的秘密，而是使用一把可以公开共享的公钥和一把必须保密的私钥。这种分离既能保护隐私，又能在从未见面的情况下证明身份。

伦纳德·阿德尔曼在 RSA 突破中的角色

伦纳德·阿德尔曼是 RSA 的“A”，与 Ron Rivest 和 Adi Shamir 一同署名。尽管 Rivest 和 Shamir 常被归功于核心构造，阿德尔曼的贡献也至关重要：他帮助将该系统塑造为不仅聪明，而且令人信服的东西——成为研究者可以分析、测试并信任的算法。

阿德尔曼为团队带来了什么

阿德尔曼的重要角色之一是对这一想法进行压力测试。在密码学中，一个方案的价值不在于它听起来合理，而在于它能否经受仔细的攻击和审查。阿德尔曼参与了验证工作，帮助细化假设，并推动早期框架以说明为何 RSA 难以破解。

同样重要的是，他帮助把“这可能行”翻译成“这是一个其他人可以评估的加密系统”。这种清晰性——让设计足够可理解以便更广泛的研究社区检查——对被采纳至关重要。

RSA 在密码学历史中的位置

在 RSA 出现之前，安全通信通常依赖双方已经共享一个秘密密钥。这种方法在封闭群体中可行，但当陌生人需要安全通信（例如购物者与网站首次交互）时就无法扩展。

RSA 改变了这个故事，推广了实用的公钥密码系统：你可以公布一把供他人使用的公钥，同时保留另一把私钥。

持久影响

RSA 的影响不仅限于一个算法。它使两项互联网必需品在规模上变得可行：

• 加密，以便在传输中保护数据；
• 数字签名，以便验证软件和消息的真实性。

这些思想支撑了 HTTPS、网上银行和签名软件更新成为常态而非罕见例外。

RSA 解决的核心问题：无需共享秘密的安全通信

在 RSA 出现之前，安全通信大多意味着共享秘密加密：双方事先必须拥有相同的秘密密钥。对于小群体，这种方法可行，但当面向数百万用户的公共服务时，很快就不适用了。

为什么共享秘密不能扩展

若每个客户都需要一个独特的秘密密钥来与银行通信，银行必须生成、交付、存储、轮换并保护海量密钥。最难的并非数学问题，而是协调问题。

如何安全地把密钥交付给每个人？邮寄既慢又有风险；电话传递可能被拦截或社会工程攻击；通过互联网发送又违背了要保护的目标——因为这正是你想要保障的通道。

两个陌生人的安全对话

想象两个从未见过面的陌生人——比如你和一家网店——想要安全地发送付款。使用共享秘密加密，你们需要一个双方都已知的私密密钥。但你们并没有。

RSA 的突破在于，使得无需预共享秘密也能进行安全通信。你可以公布一把公钥，任何人都可用它来保护发给你的消息；而你保留的私钥只有你自己能用来解密。

为什么“直接加密”还不够

即便你可以加密消息，你仍需要知道你把它加给谁。否则攻击者可以冒充银行或商店，引诱你使用他们的密钥，从而悄悄读取或篡改所有内容。

这就是为什么安全的互联网通信需要两项属性：

• 保密性： 外部人员无法读取数据。
• 真实性： 你可以验证正在通信的一方是谁（以及消息未被篡改）。

RSA 帮助使这两项在规模上成为可能，为在线信任的工作方式奠定基础。

公钥密码学基础（无行话）

公钥密码学是一个简单但影响巨大的想法：你可以在不先达成共享秘密的情况下为某人上锁。这个核心转变正是 RSA 帮助使之成为可行的。

公钥 vs 私钥（通俗说法）

把公钥想象为一把你愿意发给任何人的锁。人们可以用它来保护发给你的信息——或者（在签名系统中）用它来检查某样东西确实来自你。

私钥是你必须守口如瓶的那把钥匙。它能打开用你公钥上锁的东西，也能让你创建只有你能生成的签名。

公钥与私钥共同组成一个密钥对。它们在数学上相关，但不可互换。公开公钥是安全的，因为知道公钥并不会实用地推导出私钥。

两项主要工作：加密和数字签名

加密关乎隐私。若有人用你的公钥加密消息，只有你的私钥能解密。

数字签名关乎信任与完整性。若你用私钥对某物签名，任何有你公钥的人都可以验证两件事：

• 它确实由私钥持有者签署；
• 签署后未被篡改。

为什么它能行（不用方程）

安全性并非魔法——它依赖于一些难解的数学问题，这些问题在一个方向上容易计算，但反向在现有计算机条件下极其困难。这种“单向”性质使得公开公钥安全，而私钥仍然强大。

高层次的 RSA 运行方式

RSA 建立在一个简单的不对称性上：做“正向”数学运算很容易，但要反向解开这些运算几乎不可能——除非你有一个特殊的秘密。

单向带陷门的想法

把 RSA 想像成一种数学上的挂锁。任何人都可以用公钥上锁消息，但只有持有私钥的人才能解锁。

这之所以可能，是因为两把钥匙之间有精心设计的关联。它们是一同生成的，虽然有关联，但仅凭公钥在现实中无法推导出私钥。

为什么分解（因式分解）重要

在高层上，RSA 依赖于将大素数相乘很容易，但要把得到的巨大数分解回原始素数在实际密钥尺寸下极其困难。

对小数字而言，分解很快；但在真实 RSA 密钥（数千比特）中，已知的最佳方法仍需不切实际的大量时间和算力。这种“难以逆转”的特性阻止攻击者重构私钥。

基本流程

1. 生成密钥： 你的设备创建一对匹配的公钥和私钥。
2. 发布公钥： 它可以公开分享——放在网站上、证书中或应用里。
3. 保护私钥： 必须保持秘密；一旦泄露，锁就被破坏。

人们常忽视的一个实际细节

RSA 通常不用来直接加密大文件或长消息。相反，它常用于保护小秘密——最常见的是随机生成的会话密钥。然后使用该会话密钥用更快的对称加密来加密实际数据，因为对称加密更适合大流量。

加密 vs 数字签名：两种不同的任务

RSA 因为能做两项相关但不同的工作而著名：加密和数字签名。把它们混淆是常见的困惑来源。

三个目标：保密性、完整性、真实性

• 保密性： “只有目标人能读取它。”例如：你向网站发送银行账号，不希望别人看到。
• 完整性： “传输过程中未被更改。”例如：攻击者不应把“转账 $10” 改为“转账 $10,000”。
• 真实性： “确实来自其声称的发送者。”例如：你想确认一封邮件或软件更新确实来自银行或受信供应商。

加密主要针对保密性；数字签名主要针对完整性 + 真实性。

用于加密的 RSA：保护消息（或更常见的，保护一个密钥）

在 RSA 加密中，某人用你的公钥把内容上锁，只有你的私钥能解锁。

在实践中，RSA 常用于保护小秘密，比如随机生成的会话密钥，然后用该会话密钥高效地加密主体数据。

用于签名的 RSA：证明谁创建了某物并且它未被改变

在 RSA 签名中，方向颠倒：发送方用私钥创建签名，任何拥有公钥的人都可以验证：

• 这确实来自私钥持有者（真实性）；
• 自签名后未被更改（完整性）。

签名在现实生活中的重要性

数字签名出现在日常“批准”时刻：

• 批准交易： 银行可以对消息签名，这样你的应用就能信任接收到的指令。
• 下载： 签名安装包帮助电脑验证它来自真实发布者。
• 更新： 签名更新可防止攻击者在传输过程中替换为恶意版本。

加密保护秘密；签名保护信任。

RSA 与 HTTPS：当你看到挂锁时发生了什么

浏览器中的挂锁是一个快捷表达：你与该网站的连接已被加密并（通常）经过认证。这意味着网络上的其他人（例如同一公共 Wi‑Fi 的旁观者）无法读取或悄悄修改浏览器和网站之间的通信。

它不意味着网站在各方面都“安全”。挂锁无法告诉你商家是否诚实、下载是否含恶意软件，或你是否输入了正确的域名。它也不能保证网站把数据接收到服务器后会如何保护。

简化的 TLS 握手（浏览器实际执行的流程）

当你访问 HTTPS 站点时，浏览器和服务器会进行一个名为 TLS 握手 的设置对话：

• 服务器发送证书。 证书包含站点的公钥和其声称的域名。
• 浏览器检查身份。 它验证证书是否针对该域名有效、未过期并由受信任的证书颁发机构签名。
• 双方生成会话密钥。 浏览器确认正在与正确的对方通信后，双方同意用于本次会话的临时对称密钥。

RSA 的角色

历史上，RSA 常被用于交换会话密钥（浏览器用服务器的 RSA 公钥加密一个秘密）。在许多现代 TLS 配置中，RSA 主要用于通过签名进行认证（证明服务器控制着对应的私钥），而密钥协商则由其他方法完成。

为什么你的数据不是用 RSA 加密的

RSA 非常适合建立信任和保护设置阶段的小数据，但相比对称加密它较慢。因此握手完成后，HTTPS 会切换到快速的对称算法来传输实际的页面、登录信息和银行交易。

RSA 支持下的 HTTPS 如何让网上银行变得可行

网上银行承诺简单明了：你应该能够登录、查看余额并转账，而无需担心别人窃取你的凭证或悄悄修改你提交的内容。

银行对网页需要做的事情

一次银行会话必须同时保护三样东西：

• 登录信息： 你的密码（以及其他秘密）在传输中不得被窃取；
• 交易： 金额和目标账户必须按你发送的准确到达；
• 个人数据： 账户详情、地址和消息不应被网络旁观者读取。

没有 HTTPS，同一 Wi‑Fi 的其他人、被攻破的路由器或恶意网络运营者都可能窃听或篡改流量。

HTTPS 如何让其足够可信赖

HTTPS（通过 TLS）保护连接，使浏览器与银行之间的数据传输加密且带有完整性校验。实际效果包括：

• 攻击者无法读取你的流量（不易通过截获获取密码）；
• 攻击者无法静默篡改请求（无法在传输中将“$50”改为“$5,000”）。

RSA 在这方面的历史角色至关重要，因为它帮助解决了“首次接触”问题：在不安全网络上建立安全会话。

为什么身份与加密同等重要

若你把数据加密给错误的对象，加密本身也无济于事。网上银行只有在浏览器能确认它正在与真实银行通信时才起作用，而不是与冒充者或中间人对话。

额外层（有帮助但不能替代）

银行仍然使用多因素认证（MFA）、设备检测和欺诈监测。这些措施在凭证被盗时减少损失——但它们不能替代 HTTPS。它们是建立在已私密且抗篡改连接之上的补充防线。

安全的软件分发：为什么签名更新很重要

软件更新既是一个信任问题，也是一个技术问题。即便应用本身写得很小心，攻击者仍然可以针对分发环节——用修改过的安装包替换合法包，或在发布者与用户之间的路径中插入被篡改的更新。如果没有可靠的方法来认证你下载的内容，“有可用更新”可能成为一个容易的入口点。

简单攻击：替换安装包

如果更新仅由下载链接保护，那么攻陷镜像站点、劫持网络连接或引导用户访问仿冒页面的攻击者可以提供一个同名的不同文件。用户可能会正常安装，而损害往往是“静默”的：恶意软件随更新安装、后门被加入、或安全设置被削弱。

代码签名：证明谁构建了它（以及它未被更改）

代码签名使用公钥密码学（在许多系统中包括 RSA）为安装包或更新附加数字签名。

发布者用私钥对软件签名。你的设备或操作系统用发布者的公钥（通常通过证书链提供）验证签名——哪怕改动一个字节，验证就会失败。这把信任从“我从哪里下载的？”转向“我能否验证是谁创建了它以及它是否完整？”。

在现代应用交付流水线中，这些理念超越了安装包，扩展到 API 调用、构建产物和部署发布。例如，平台如 Koder.ai（一个用聊天界面发布 Web、后端和移动应用的 vibe-编码平台）仍然依赖相同的基础：传输中的 HTTPS/TLS、为自定义域名做谨慎的证书处理，以及在推送更改时使用快照和恢复点之类的实用回滚工作流以降低风险。

这对普通用户意味着什么

签名更新减少了未被注意到的篡改机会。用户在有异常时会看到更明确的警告，自动更新系统可以在运行前拒绝被篡改的文件。这并不保证软件本身没有漏洞，但在抵御冒充和供应链干预方面非常有效。

要更深入了解签名、证书和验证如何协作，请参见 /blog/code-signing-basics。

证书与 PKI：公钥如何变得可信

如果 RSA 给了你一把公钥，自然会问：这把公钥属于谁？

证书就是互联网的答案。证书是一个小的、被签名的数据文件，把公钥和一个身份（如网站名 example.com、一个组织或软件发布者）关联起来。把它想象成公钥的身份证：它说明“这把钥匙属于这个名称”，并包含诸如证书所有者、公钥本身和有效期等信息。

证书颁发机构：信任的连接者，而非魔法

证书之所以重要，是因为它们由“其他人”签名。这个“其他人”通常是证书颁发机构（CA）。

CA 是一个第三方，负责检查某些证明（从基本的域名控制到更深入的业务验证不等），然后签发证书。你的浏览器或操作系统内置了一份受信任 CA 列表。当你通过 HTTPS 访问站点时，设备用该列表来决定是否接受证书的声明。

这个系统并不完美：CA 可能出错，攻击者也可能试图欺骗或攻破它们。但它在全球范围内创建了一个可行的信任链。

过期与吊销：事情变化时会怎样

证书是有过期时间的，这是有意为之。短生命期可以限制密钥被窃取时的损害，并鼓励定期维护。

证书也可以在到期前被吊销。吊销用于声明“停止信任此证书”，例如当私钥可能泄露或证书被错误颁发时。设备可以检查吊销状态（严格性与可靠性各异），这也是密钥管理仍然重要的原因之一。

实用密钥管理建议

保持私钥私密：将其存放在安全密钥存储中，限制访问，避免不必要地在系统间复制。

在发生事件、计划升级或策略要求时轮换密钥。并跟踪到期日，避免续期成为最后一分钟的紧急事务。

关于 RSA 的局限、风险与常见误解

RSA 是一个基础性的思想，但不是万能盾。大多数实际破坏并非因为有人“破解了 RSA”——而是发生在围绕 RSA 的系统出现失误时。

常见的失败模式（实际发生的错误）

一些常见模式反复出现：

• 弱密钥： 使用位长过短或已过时的 RSA 设置会降低攻击成本。
• 密钥存储不当： 私钥放在被攻破的服务器、备份中或提交到代码仓库会被窃取，而不需要任何密码学层面的突破。
• 钓鱼和终端被攻破： 如果攻击者诱导人们批准登录或在设备上安装恶意软件，加密无法挽救；
• 错误签发证书： 若 CA 误发证书，用户可能在看到“有效”HTTPS 的同时被引导到攻击者一方。

为什么密钥长度和随机性很重要

RSA 的安全性依赖于生成足够大且真正不可预测的密钥。良好的随机性必不可少：如果在密钥生成中使用了弱随机源，攻击者有时能重现或缩小可能的密钥范围。同样，密钥长度也很重要，因为计算能力和数学技术的进步会逐步缩小小密钥的安全边际。

RSA 并非“太慢”，但被选择性使用

RSA 运算比现代替代算法要重，因此许多协议选择谨慎使用 RSA——通常用于认证或交换临时秘密，然后切换到更快的对称加密来处理大量数据。

最大的误解："只有 RSA 就能保证安全"

安全最好采用纵深防御：保护私钥（最好用硬件）、监控证书签发、及时打补丁、使用抗钓鱼的认证方式，并为安全的密钥轮换设计流程。RSA 是链条上的一个工具——不是全部。

当今的 RSA：它仍适用的场景与常用替代品

RSA 仍是互联网中广泛支持的密码工具。即使某些服务不再“偏好”RSA，它通常仍保留兼容性，因为它无处不在：老旧设备、长期运行的企业系统以及多年建立的证书基础设施。

为什么系统会逐步超越 RSA

密码学会演进，原因与其他安全技术类似：

• 速度与效率： RSA 运算相对较慢且需要较大密钥。新方法在相同安全性下通常用更小的密钥、更快的握手。
• 新威胁与安全边际： 随着研究进展，社区会重新评估哪些最安全且易于正确实现。
• 为现代用例设计得更好： Web 现在需要快速连接、移动性能和大规模服务——推动标准朝更适合这些约束的算法演进。

常见的并用或替代方案

在 TLS 和现代应用中常见的替代方案有：

• ECDSA 与 Ed25519（用于数字签名，通常比 RSA 更快且密钥更小）；
• ECDH（用于密钥交换，同样是许多 HTTPS 连接不再依赖 RSA 来完成主要“设定秘密”步骤的原因）。

直白地说：RSA 可以同时做加密与签名，但较新的系统常把工作分开——用一种方法优化签名，另一种方法优化会话密钥的建立。

那么……RSA 已经过时了吗？

不是。RSA 仍被广泛支持，并在许多情况下仍是有效选择，尤其是在兼容性很重要或已有证书与密钥管理实践围绕它建立的场景中。最“好”的选项取决于设备支持、性能需求、合规要求以及密钥如何存储和轮换等因素。

如果你想看到这些选择在真实 HTTPS 连接中如何呈现，下一步可读：/blog/ssl-tls-explained。