2025年5月04日·1 分钟
DJB 与基于构造的安全：从 qmail 到 Curve25519
从实践角度审视丹尼尔·J·伯恩斯坦的“基于构造的安全”思想——从 qmail 到 Curve25519——以及“简单、可验证的加密”在实际中的含义。
从实践角度审视丹尼尔·J·伯恩斯坦的“基于构造的安全”思想——从 qmail 到 Curve25519——以及“简单、可验证的加密”在实际中的含义。
基于构造的安全是指以这样的方式构建系统：常见错误难以发生，而且不可避免的错误造成的损害被限制住。与依赖冗长的检查单（“记得校验 X、清理 Y、配置 Z……”）不同，你设计软件使得最安全的路径同时也是最容易的路径。
把它想象成儿童防护包装：它并不假设每个人都会完全小心；它假设人会疲惫、忙碌、有时会出错。良好的设计减少了对开发者、运维和用户“完美行为”的依赖。
安全问题常常藏在复杂性里：过多的特性、过多的选项、组件之间过多的交互。每一个额外的旋钮都可能产生新的失效模式——系统意外崩溃或被误用的新途径。
简单性在两个实际方面有助益：
这并不是为了极端极简而极简。关键是把行为集合保持在足够小的范围内，使你能够真正理解它、测试它，并推理当出问题时会发生什么。
本文用丹尼尔·J·伯恩斯坦的工作作为一组具体例子来说明基于构造的安全：qmail 如何旨在减少失效模式，恒定时间思维如何避免看不见的泄露，以及 Curve25519/X25519 与 NaCl 如何推动更难被误用的加密。
本文不会做的事：提供完整的密码学史、证明算法的安全性，或声称有一个对每个产品都适用的“最佳”库。也不会假装良好的原语能解决一切——真实系统仍会因为密钥处理、集成错误和运维缺口而失败。
目标很简单：展示能让安全结果更可能发生的设计模式，即便你不是密码学专家。
丹尼尔·J·伯恩斯坦（常简称为“DJB”）是位数学家与计算机科学家，他的工作在实用安全工程中频繁出现：邮件系统（qmail）、密码学原语和协议（尤其是 Curve25519/X25519），以及把加密打包用于现实世界的库（NaCl）。
人们引用 DJB 并不是因为他写了唯一正确的安全方法，而是因为他的项目展示了一套一致的工程直觉，这些直觉能减少出错的方式数量。
一个反复出现的主题是更小、更紧的接口。如果一个系统暴露更少的入口点和更少的配置选项，就更容易审查、更容易测试，也更难被误用。
另一个主题是明确的假设。安全失败常来自未说出口的期望——关于随机性、时序行为、错误处理或密钥存储方式等。DJB 的写作和实现倾向于把威胁模型具体化：保护了什么、防谁，以及在什么条件下。
最后，还有一种倾向是更安全的默认值和无趣的正确性。这一传统中的许多设计试图消除会导致微妙错误的锋利边缘：模糊的参数、可选模式和泄露信息的性能捷径。
本文不是个人生平，也不是关于人设的争论。它是从工程角度出发：观察 qmail、恒定时间思维、Curve25519/X25519 和 NaCl 中能看到的模式，以及这些模式如何映射为在生产环境中更易验证且不那么脆弱的系统。
qmail 的目标是解决一个不那么光鲜的问题：可靠投递邮件，同时把邮件服务器当作高价值目标来对待。邮件系统长期暴露在互联网上、每天接受敌意输入、并处理敏感数据（消息、凭证、路由规则）。历史上，一个单一的单体邮件守护进程中的漏洞可能导致系统被完全攻破——或者消息静默丢失直到为时已晚。
qmail 的一个核心思想是把“邮件投递”拆成做一件事的小程序：接收、排队、本地投递、远程投递等。每个部分都有狭窄的接口和有限的职责。
这种分离之所以重要，因为失败会变得局部化：
这就是实用形式的基于构造的安全：把系统设计成使“一次错误”不太可能变成“全面崩溃”。
qmail 还体现了一些可迁移到其他领域的习惯：
结论不是“使用 qmail”，而是你常常能通过围绕更少失效模式重新设计获得重大安全收益——在写更多代码或增加更多旋钮之前。
“攻击面”是系统所有可以被戳、被试探或被诱导做错误事情的位置的总和。一个有用的类比是房子：每扇门、窗、车库遥控器、备用钥匙和投递口都是潜在入侵点。你可以安装更好的锁，但通过减少入入口点本身也能更安全。
软件也是如此。你打开的每个端口、接受的每种文件格式、暴露的管理端点、添加的配置旋钮以及支持的插件钩子都会增加系统出错的方式数量。
“紧接口”是一个做得更少、接受更少变体、拒绝模糊输入的 API。它常让人觉得受限——但更容易保证安全，因为审计的代码路径更少，意外交互也更少。
考虑两种设计：
第二种设计减少了攻击者能操纵的内容，也减少了团队意外配置错误的空间。
选项会让测试变多。如果你支持 10 个开关，你并不是只有 10 种行为——而是有这些选项的组合。许多安全漏洞存在于这些缝隙中：“这个标志会禁用一个检查”，“这个模式跳过验证”，“这个遗留设置绕过速率限制”。紧接口把“选择你自己的冒险”安全变成一条光线充足的路径。
用下面清单来发现悄然增长的攻击面：
当你无法缩小接口时，就把它设为严格：尽早校验、拒绝未知字段，并把“高级功能”放在单独、明确作用域的端点后面。
“恒定时间”行为意味着计算所需时间（大致）不随秘密值（如私钥、随机数或中间位）变化。目标不是让它更快，而是让它“无趣”：如果攻击者无法把运行时间与秘密相关联，他们就更难通过观察提取秘密。
时序泄露重要，因为攻击者并不总是需要破解数学。如果他们能多次运行相同的操作（或在共享硬件上观察它运行），微小差异——微秒、纳秒，甚至缓存效应——都可能揭示累积成密钥恢复的模式。
即便是“普通”代码也可能随数据而行为不同：
if (secret_bit) { ... } 会改变控制流并通常改变运行时间。你不需要读汇编就能从审计中获得价值：
if 语句、数组索引、基于秘密终止的循环和“快路径/慢路径”逻辑。恒定时间思维更多是关于纪律：把代码设计成让秘密无法左右时序。
椭圆曲线密钥交换是两台设备即使只在网络上发送“公有”消息也能生成相同共享密钥的一种方式。每一方生成一个私有值（保密）和相应的公有值（可发送）。交换公有值后，双方结合自己的私有值与对方的公有值得到相同的共享密钥。窃听者只能看到公有值，却无法切实重建共享密钥，双方随后可以从该共享密钥派生对称加密密钥以进行私密通信。
Curve25519 是底层曲线；X25519 是建立在其之上的标准化、“做这件明确的事”的密钥交换函数。它们受到欢迎很大程度上是因为基于构造的安全：更少的陷阱、更少的参数选择，以及更少能导致误配置的不安全设置。
它们在多种硬件上都很快，这对处理大量连接的服务器和尽量省电的手机都很重要。设计也鼓励实现更容易做到恒定时间（从而有助于抵抗时序攻击），这降低了通过测量微小性能差异来提取秘密的风险。
X25519 给你的是密钥协商：帮助两方就对称加密派生共享密钥。
它不会单独提供认证。如果只运行 X25519 而不验证对端（例如通过证书、签名或预共享密钥），你仍可能被诱导与错误的对方建立安全通道。换言之：X25519 能防止窃听，但不能单独阻止冒充。
NaCl（Networking and Cryptography library）围绕一个简单目标构建：让应用开发者更难意外组装出不安全的加密。与其提供一大桌子的算法、模式、填充规则和配置旋钮，NaCl 推动你使用一小组已经以安全方式连接好的高层操作。
NaCl 的 API 以你想做什么来命名，而不是你想拼接哪种原语。
crypto_box（“box”）：公钥认证加密。你提供私钥、接收方公钥、nonce 和消息，得到既隐藏消息又证明来源的密文。crypto_secretbox（“secretbox”）：共享密钥认证加密。同样的想法，但用单一共享密钥。关键好处是你不会单独选择“加密模式”和“消息认证算法”然后指望自己组合正确。NaCl 的默认值强制采用现代且抗误用的组合（先加密再认证或其他正确组合），因此常见失误——比如忘记完整性校验——不太可能发生。
如果你需要与遗留协议兼容、特定格式或监管要求算法，NaCl 的严格性可能让你觉得受限。你在“我可以调整每个参数”与“我可以在不做密码学专家的情况下发布安全东西”之间做权衡。
对许多产品来说，这正是重点：约束设计空间，使错误少得多。如果你确实需要定制，可以退到更低级的原语，但那意味着你重新回到有锋利边缘的状态。
“默认安全”意味着当你不做任何配置时，得到的是最安全且合理的选项。如果开发者安装一个库、复制一个快速示例或使用框架默认值，结果应该难以误用且不易被意外削弱。
默认设置很重要，因为大多数真实系统就是用默认运行的。团队节奏很快、文档常被掠过、配置自然增长。如果默认是“灵活的”，那通常会转化为“容易配置错误”。
加密失败常常不是由“数学错了”引起的，而是因为有人选择了危险设置，因为它可用、熟悉或容易。常见的默认陷阱包括：
优先选择让安全路径成为最容易路径的栈：审查过的原语、保守参数、不会让你做脆弱决定的 API。如果一个库让你在十种算法、五种模式和多种编码之间选择，你就是在通过配置来做安全工程。
当可能时，选择那些：
基于构造的安全部分就是拒绝把每个决定都变成一个下拉框。
“可验证”在大多数产品团队里并不意味着“形式化证明”。它意味着你可以快速、可重复地建立信心，并且更少机会误解代码在做什么。
当一个代码库具有以下特征时，它就更可验证：
每个分支、模式和可选特性都会乘增审查者必须推理的内容。更简单的接口缩小了可能状态的集合，从而提高了审查质量：
保持无趣且可重复：
这种组合不能取代专家审查，但它能抬高底线：更少惊讶、更快检测、更容易推理的代码。
即便你选择了广受好评的原语如 X25519 或像 NaCl 风格的简洁 API，系统仍会在凌乱的部分崩溃：集成、编码和运维。大多数真实事件并不是“数学错了”，而是“数学被错误使用”。
密钥处理错误很常见：在需要临时密钥的地方重用长期密钥、把密钥放入版本控制、或混淆“公钥”和“私钥”的字节序列因为它们看起来都只是数组。
nonce 误用是屡犯者。许多认证加密方案要求每个密钥下的 nonce 唯一。复用 nonce（常见于计数器重置、多进程竞争或“随机够用”的假设）会破坏机密性或完整性。
编码和解析问题造成静默失败：base64 与 hex 混淆、丢失前导零、不一致字节序或接受多种编码但比较方式不同。这些 bug 可能把“已验证签名”变成“验证了别的东西”。
错误处理在两端都可能危险：返回过于详细的错误帮助攻击者，或忽视验证失败继续执行。
秘密会通过日志、崩溃报告、分析和“调试”端点泄露。密钥也会出现在备份、虚拟机镜像和被过度共享的环境变量中。同时，依赖更新（或缺乏更新）可能让你停留在一个有漏洞的实现上，即便设计本身是合理的。
基于构造的安全是把软件设计成“最安全的做法同时也是最简单的做法”。与其让人们记住一长串检查项，不如约束系统，使常见错误难以发生，且不可避免的错误造成的影响有限（更小的“爆炸半径”）。
复杂性会产生隐藏的相互作用和难以测试、易于配置错误的边界情况。
从实用角度看，简化带来的好处包括：
“紧接口”就是做得更少、接受更少变体的接口。它避免歧义输入，并减少会导致“通过配置实现安全”的可选模式。
实用方法包括：
qmail 将邮件处理拆分为多个小程序（接收、排队、本地投递、远程投递等），每个程序职责单一且接口狭窄。这带来的好处包括：
恒定时间行为旨在使运行时间（以及经常的内存访问模式）不依赖于秘密值。这很重要，因为攻击者有时可以通过测量时间、缓存效应或“快路径/慢路径”的差异在多次试验中推断出秘密。
这关乎防止“看不见的泄露”，而不仅仅是选择强数学算法。
先识别哪些是秘密（私钥、共享密钥、MAC 密钥、认证标签），然后寻找秘密影响控制流或内存访问的地方。
搜索的危险信号包括：
if 分支还要确认你所依赖的加密库明确宣称对相关操作是恒定时间的。
X25519 是基于 Curve25519 的规范化密钥协商函数。它被认为更难被误用，因为参数更少、性能好，并且设计有利于实现恒定时间，从而减少通过测量性能差异提取秘密的风险。
前提是你仍然要正确处理认证和密钥管理。
不是。X25519 提供的是密钥协商（共享密钥），并不会证明对端的身份。
要防止冒充，需配合认证机制，例如：
没有认证，你仍可能“安全地”与错误的一方通信。
NaCl 通过提供高层、已经安全组合好的操作来减少开发者犯错的机会，而不是暴露一长串算法和模式。
常见构建块包括：
crypto_box：公钥认证加密（你 + 对方公钥 + 随机数 + 消息 → 密文）crypto_secretbox：共享密钥认证加密实际好处是避免常见的组合错误（例如加密而未校验完整性）。
即便使用了良好的原语，集成和运维层面的问题仍会导致失败。常见险情包括：
缓解措施：