红杉PGP 1.0发布:幼苗是幼树

2020-12-17 05:42:13

版本1.0。它在这里。经过三年半的发展,我们很高兴地宣布红杉1.0版的发布!

该发行版包括低级的条板框sequoia-openpgp,以及一个程序,用于验证针对称为sqv的软件分发系统的分离签名。

我们将通过至少一年的安全更新来支持该API。在9个月内,我们将宣布是否会继续履行此承诺。两个主要标准将是我们的财务状况(请捐赠或赞助一两个开发人员),以及用户数。

实际上,大约在一年前,我们几乎发布了1.0版。我们为1.0版计划的所有功能都已实现,我们具有良好的测试覆盖率,甚至还有几个用户。但是,我们决定等待。我们之所以决定等待,并不是因为我们想到了另一个功能,或者是因为我们意识到了一个重大的错误,而是因为我们决定花一些时间来改进文档。

我们的目标是确保每个模块都有一个有用的介绍,所有公共方法都具有有用的描述,适当时与标准的链接以及有意义的示例。将任务划分为五个人,我们认为这会延迟发布时间,一个月,也许两个。最终,花了将近一年的时间,我们不得不将雄心壮大。不过,我们对结果感到非常满意。

首先,文档要好得多。当然很难量化其质量。但是,我们可以提取一些数字。当我们开始编写文档时,在发布0.14版本后不久,Sequoia库的注释行就超过11000行,其中包括53个文档测试,而37 kSLOC包括12 kSLOC单元测试。 1.0版包含34,000行注释(增加190%),包括464个文档测试(增加780%),以及44 kSLOC(增加21%或7.5 kSLOC),包括8k SLOC的附加单元测试。

其次,在记录我们的公共API和编写示例的过程中,我们发现了许多小的烦恼,一些不一致之处以及多个错误。我们借此机会修复了它们。

最后,随着API更改率的降低,更多的项目愿意尝试使用Sequoia。他们提供了其他有用的反馈,我们对其进行了整合。

总而言之,我们认为在1.0版中,我们不仅选中了正确的复选框,而且还拥有值得骄傲的高质量API和实现。

红杉成立于3.5年前,由Justus Winter,Kai Michaelis andme和Neal Walfield共同创立。在从事红杉之前,我们三个人曾在GnuPG的g10code上一起工作过。 p≡p基金会的员工不仅使用新的体系结构和编程语言来创建新的OpenPGP实现,而且还从整体上改善了围绕隐私保护工具的生态系统。

红杉图书馆是朝着这个方向迈出的第一步。但这不是我们的目标。实际上,在过去三年中,我们已经帮助了其他OpenPGPimplementation。我们已经报告了已发现的错误(尤其是我们的OpenPGP互操作性测试套件),甚至为其他OpenPGP实施提供了一些修复程序。

而且,我们已经投资了工具。我们开发了Hagrid,这是一种新的验证OpenPGP密钥服务器,它为keys.openpgp.org提供动力,现在由Vincent Breitmoser维护。我们帮助了由Heiko Schaefer编写的工具OpenPGP CA,它为活动家,律师和新闻记者等团体创建了联合CA,也为那些不想用金钱激励来信任集中式基础架构的公司创建了联合CA。 OpenPGP大大简化了简单的OpenPGP用户的密钥发现和身份验证。我们开发了Koverto(一种SMTP代理),可轻松对不支持OpenPGP的服务(如大多数CMS)发送的邮件进行签名和加密。我们开发了一个名为sq-keyring-linter(Debian)的工具,以帮助用户更新其OpenPGP证书,以便最终摆脱SHA-1。

我们的想法很大。我们不仅考虑一般的邮件加密或什至加密,而且考虑完整性和认证。而且,我们正在特别考虑PKI。如果用户无法轻松找到合适的通讯伙伴证书,则加密和数字签名毫无价值,甚至可能很危险。

在设计红杉时,我们采取了图书馆优先的方法。尽管我们有一个尚未发布的命令行工具sq,但我们希望该库始终提供更丰富,更具表现力的界面。我们同意在流程分离中有其价值,但我们希望避免安全地炮轰另一个程序带来的危险复杂性。

sequoia-openpgp板条箱(Rust的库术语)是一种低级,无策略的OpenPGP实施。我们的目标是实施所有RFC 4880,并提供可用于访问和修改几乎所有内容的API,但默认情况下同时安全。

我们将低级理解为不仅意味着提供getters和setters的API,而且意味着提供接口以解析和序列化这些字段并可以按标准和用户所需的方式组合它们的API。例如,Cert数据结构封装了一个OpenPGP证书(通常称为OpenPGP密钥)。它规范化了结构,并使其易于查询其属性。但是,这样做的方式使得用户仍然可以自行检查和修改低级位,而无需重新实现其余功能。另一个示例是DecryptionHelper,它可以轻松解析和解密OpenPGP消息。

我们默认情况下如何使API安全的一个示例是,很难意外导出密钥材料。在Sequoia中,您必须明确[选择导出以进行导出]。同样,在更新签名时,创建时间,哈希算法和发行者也会自动更新。这通常是用户想要的,但是很容易忘记,并且在忘记时很难调试。至关重要的是,在不需要这种行为时很容易选择退出。

在开发红杉时,我们花了很多时间思考极端和极端情况。例如,OpenPGP支持公证(签名之上的签名),但是据我们所知,尚无OpenPGP实现支持它们。无论如何,我们都实现了对它的支持,并改善了普通案例的人体工程学。

细节在于细节。在开发红杉时,我们注意了。以下是一些值得注意的细节:

自2005年以来,SHA-1就被破坏了。2011年,NIST弃用了它。最初,我们决定拒绝使用SHA-1的任何签名。但是,我们最近被迫重新评估该决定:22%的Debian开发人员使用依赖SHA-1的证书,而63%的Arch开发人员也使用依赖SHA-1的证书。甚至Fedora发行密钥也使用SHA-1。

我们决定不能简单地重新启用SHA-1。经过深思熟虑,我们选择在与SHA-1类似的碰撞攻击更难的情况下允许使用。我们还使用SHA-1的一种变体SHA1CD(SHA-1Collision Detection),该变体可以检测并抵消针对SHA-1的已知攻击,其中GitHub就是其中之一。而且,我们还决定在2023年初(即两年多一点)开始默认拒绝SHA-1。希望这将给Debian开发人员和其他人足够的时间来修复或替换其证书。

创建签名时,会包含盐。这使得攻击者更难预测用户将签名的数据。而且,它会阻止攻击者在同一消息上需要多个签名的攻击。

与OpenSSH相似,我们在内存中加密密钥材料。这使旁通道攻击受挫。

红杉支持填充消息以混淆加密消息的长度。我们包括对padmé方案的支持,但可以插入其他方案。

为了允许用户在仍使用高级功能的情况下控制策略,红杉使用策略对象。策略对象将传递给检查某项内容有效性的任何方法。例如,当一种方法需要确定是否应使用绑定签名时,它会调用策略对象的签名回调。我们的经验表明,这种方法大大简化了以高度灵活的方式处理这一跨领域问题的方法。

策略对象也可以嵌入其他对象中。例如,ValidCert封装了Cert和策略对象。这确保了该策略的应用是一致的,并且难以忘记应用。

在红杉(Sequoia)中,在进行任何非平凡的解析时,我们更喜欢使用形式语法,而不是即席解析。例如,在验证OpenPGP证书和OpenPGPMessages的结构时,我们使用解析器生成器LALRPOP生成解析器。

红杉实现了流API。如果不小心,可能会导致消费者处理未经身份验证的数据,这些数据已被EFAIL利用。为了减轻这种类型的故障,DecryptionHelper保留数据的最后O(1)字节,并且仅在可以验证消息的情况下才释放它。这使攻击者更难控制释放的内容。对于短消息,由于整个消息都已缓冲,因此不会释放任何内容。

我们已尝试确保可能在旁信道敏感上下文中使用的数据结构使用恒定时间比较。

在可能的情况下,我们使用设备驱动程序样式的API,以便直接添加新的后端。对于实例,我们的Signer和Decryptor特性使实现替代的签名和解密后端变得容易。除了内存中的实现之外,我们已经有了使用由gpg代理管理的秘密材料的实现。

我们努力提供有用的错误消息。例如,在寻找有效的自签名时,这尤其困难:如果所有自签名都被忽略(由于无效),那么应该显示什么?在这种情况下,我们记得为什么签名被拒绝,然后显示这些错误消息之一。这不太混乱。以下输出说明了此想法:

$ sq inspect md5.pgponly-md5-pub.pgp:OpenPGP证书。指纹:526F D3F8 4EC7 DA9D E565 1B06 C4C9 7B7F A453 52C3无效:2020-12-16T14:18:21Z无绑定签名公钥算法:RSA(加密或签名)公钥大小:2048位创建时间:2020- 11-05 09:16:25 UTC用户ID:MD5全能< [email protected]>无效:策略拒绝非撤销签名(PositiveCertification),需要第二次镜像前抵抗,因为:自2004-02-01T00:00:00Z以来,MD5被认为不安全

最后,我们对前向兼容性进行了很多思考。 OpenPGP标准通过使用可扩展的类型和版本对此进行了规定。我们会小心翼翼地保留我们不了解的内容,并尽可能尊重这些数据包。

红杉提供了一个底层API。因此,我们不提供公共或私人密钥存储。但是,我们确实计划开发它们(实际上,我们已经有原型)。但是,它们将单独发布。特别是,我们不认为单一设计普遍适用。例如,服务器应用程序可能不在乎与其他应用程序共享密钥,并且可能拥有自己的数据库。

红杉实现了RFC 4880的大部分内容。但是,它仍然缺少一些功能。特别是,我们尚不支持明文签名。Cert数据结构尚不支持证书吊销。而且,我们仍然需要实现用于限制信任签名范围的OpenPGP正则表达式。我们将在不久的将来增加对这些功能的支持。

红杉未实现其使用的加密原语,而是依赖于库。默认情况下,红杉使用Nettle。但是,在Windows上也可以使用Windows CNG,它的优点是它已经是用户受信任的计算库的一部分。其结果是,红杉仅限于图书馆所支持的内容,而既不支持Elgamal密钥,也不支持Brainpool密钥。 (对于Windows上的25519键,我们使用ed25519-dalek和关联的包装箱。)

我们还决定不支持AEAD,因为其针对OpenPGP的规范仍是草案,并且尚未达成共识。

我们已经开始研究原型,因此我们相信我们的低级API就足够了。私钥存储的一个值得注意的目标是使用类似设备驱动程序的框架,以便可以使用不同的后端。这样做的主要动机是处理智能卡。但是,它也可以用于透明地访问远程密钥和gpg的代理,这将简化互操作性。

尽管该工具已经非常有用并且有用,但是仍然缺少一些重要功能。特别是,我们希望添加一个REST风格的,基于JSON的版本化API,因为我们期望人们最终将编写使用sq的脚本,并且我们希望避免让他们在屏幕上刮擦其输出,这无疑会导致安全问题。

更广泛地说,我们计划继续在生态系统中开展工作,尤其侧重于工具。

目前,有六人在红杉工作。他们都是由p≡p基金会支付的。 Wau Holland基金会在2018年一次性捐赠了额外的财务支持。PGP的创建者Phil Zimmermann捐赠了1000欧元。ProtonMail捐赠了1000欧元,因为我们的互操作性测试套件在OpenPGP.js和GopenPGP中发现了多个问题,他们维护。

尽管p≡p基金会的资金在中期是安全的,但对于红杉的长期健康至关重要的是,我们会分散其资金。您无需直接使用红杉就可以对其产生积极的影响。例如,OpenPGP CA是用于创建联合CA的新工具,旨在简化不依赖集中式身份验证解决方案的激进主义者,律师和新闻工作者对OpenPGP的使用。因此,请考虑捐赠。当然,ifyour公司正在使用红杉,请考虑赞助一个或两个开发人员。注意:如果您想使用GPLv2 +以外的许可来使用红杉,请联系基金会。