数十年来，加密工程师一直在抱怨PGP的缺点 。 当普通开发人员听到此消息时，他们会感到非常惊讶。 怎么，PGP不好？ 那么，为什么建议使用它呢？ 答案是，PGP确实不好，并且绝对不应推荐给任何人。 他必须消失。

如您将很快看到的，PGP存在很多问题。 如果您不做详细介绍，则主要原因是该程序是在90年代开发的，当时的现代加密技术尚未出现。 如今，没有胜任的加密工程师会以这种形式开发系统，并且不会容忍任何其他系统中的大多数缺陷。 认真的密码学家基本上放弃了PGP，并且不再花时间（一些著名的例外 ）。 因此，PGP中众所周知的问题十多年未解决。

两个小笔记。 首先，该文章是为工程师而不是律师和活动家撰写的。 其次，从OpenPGP标准到GnuPG中的参考实现，“ PGP”可能有很多含义。 所有这些我们都使用术语“ PGP”。

问题所在

荒谬的复杂性

由于目前尚无人了解的原因，PGP是基于程序包的。 PGP消息（在.asc文件中）是键入的程序包的存档。 根据使用的是“新”还是“旧”格式的数据包，至少有八种不同的方式来编码数据包的长度。 像BER这样的“新格式”数据包的长度是可变的（尝试编写PGP实现，而ASN.1编码标准将看起来像糖果）。 包可能包含子包。 一些软件包选项相互重叠。 对密钥服务器的最后一次攻击是由于以下事实：由于这种不负责任的格式，GnuPG密钥解析意外地在二次时间内离开 。

这只是一种编码。 实际的系统要复杂得多。 有钥匙和插头。 密钥标识符，密钥服务器和密钥签名。 密钥仅用于签名，仅用于加密。 众多钥匙扣。 证书吊销。 三种不同的压缩格式。 表示我们尚未达到智能卡的支持。

瑞士军刀设计

如果您迷失在森林中，并且...例如，我不知道是否需要修整牛仔裤上的翻领-是的，刀上有剪刀非常方便。 但是对于严肃的工作，没有人会定期使用这种剪刀。

瑞士军刀会做很多事情，而且一切都不好。 PGP是用于签署文档的非常平庸的工具；它使用密码的加密相对较差，而使用公钥的加密则较差。 PGP对于安全的文件传输不是特别好。 这是对软件包签名的笨拙方法。 保护备份不是很好。 这是交换安全消息的极其危险的方式。

早在MC Hammer时代，当PGP出现时，“加密”本身就是一种特殊的事物。 有一种用于发送文件，备份，加密和签名文件的工具。 现代密码学不能那样工作，我们需要专门的工具。 用于安全消息传递的加密不同于用于备份或签名程序包的加密。

向后兼容沼泽

PGP先于现代加密技术，在此期间非常过时。 如果幸运的话，默认情况下，您的GnuPG将具有2048位RSA密钥，CFB中的64位CAST5密码和OpenPGP MDC校验和（稍后将对此进行介绍）。 如果使用密码而非公用密钥进行加密，则OpenPGP协议将为PGP建立S2K密钥生成算法。 坦率地说，这些并不是加密工程师会为现代系统选择的原语。

自从书呆子史蒂夫·乌克尔（Steve Urkel）在美国广播公司（ABC） 布置黄金时段以来，我们学到了很多东西。 我们了解到应该对加密的文本进行身份验证（并避免使用CFB模式），认为64位块密码不好，RSA不够完善，压缩和加密的组合很危险，并且必须在时间和内存上严格生成KDF。

无论OpenPGP RFC怎么说，如果使用PGP，您可能都不会在此列表中做任何事情，并且无法确定建议何时开始实施。 以AEAD密码为例：Rust中的红杉PGP默认为AES-EAX AEAD模式。 太好了 但是现在没有人可以阅读他们的消息，因为大多数PGP版本都不知道EAX模式是什么，这不是很酷。 在每个不良的密码系统中，最终结果都是支持椭圆曲线或AEAD的RFC扩展，因此其支持者可以在支持现代密码技术的论坛中大喊大叫。 RFC没关系：只有实际设置。 我们在20年前发明了经过身份验证的加密技术，PGP即将退休。 足够的借口。

您可能对90年代的程序具有向后兼容性，或者您拥有良好的加密技术；或者 你不能两者兼得 。

讨厌的用户体验

很难比泰德·昂格斯特（Ted Unangst）更好地制定：

几年前，进行了PGP可用性研究，其中一组技术专家被放置在装有计算机的房间中，并要求配置PGP。 两个小时后，他们都没有回应。

如果您需要自己的经验数据来确认这一点，请执行以下实验：找到远离计算机的律师，并帮助他通过电话安装Signal。 他可能会毫不歇斯底里地应付。 现在尝试使用PGP执行此操作。

长期秘密

PGP要求用户几乎永远将根密钥与其身份联系在一起。 这些“密钥签名方”和“信任网络”的密钥生成和交换繁琐，其中密钥依赖于其他密钥。

长期按键几乎总是不舒服 。 如果继续使用该密钥，它将最终成为公共密钥。 从称职的系统设计的角度来看，如果对当前密钥的安全性至少有一些担忧，则有必要将损害最小化并确保用户在考虑生成新密钥时毫不犹豫。

PGP粉丝会立即回答：“这就是为什么您需要将钥匙保持在Yubikey上。” 但是根据一个快速的粗略估计，世界上几乎没有人使用昂贵的Yubikey，并且这种情况将来不太可能改变（我们几乎无法部署U2F，而且这些密钥是一次性的）。 我们不能接受坏的密码系统只是为了让Unix书呆子更自在地玩玩具。

身份验证失败

有关PGP原始元素的更多信息：早在2000年，OpenPGP工作组就意识到有必要对加密的文本进行身份验证，而PGP签名则不需要。 因此，OpenPGP发明了MDC系统 ：具有MDC的PGP消息将纯文本SHA-1附加到纯文本本身，然后以常规方式在CFB模式下对其进行加密。

如果您想知道当现代系统使用相对复杂的AEAD方案（因为它们不能仅将SHA-1附加到明文）时PGP如何处理此问题，那么这是一个很好的问题。 您如何形容这部动画片？ 可以清除PGP MDC的消息-编码方式非常简单，可以截断密文的最后22个字节。 为了保持与不安全的旧消息的向后兼容性，PGP引入了一种新型的程序包，表示需要MDC验证。 如果使用错误的类型，则不会检查MDC。 即使这样做，新的SEIP数据包格式也非常接近不安全的SE格式，这可能会诱使接收者降低密码。 Trevor Perrin将SEIP减少到仅16位安全性 。

最后，即使一切正常， 即使MDC不匹配 ，PGP参考实现也会根据请求生成未经身份验证的纯文本。

身份不一致

PGP是一个应用程序，与其他应用程序的一组集成，文件格式，社交网络和亚文化。

PGP提出了密码身份的概念。 创建密钥，将其保存在钥匙串中，在名片上打印其指纹，然后将其发布在密钥服务器上。 您签署别人的钥匙。 反过来，它们可能会也可能不会依赖您的签名来验证其他密钥。 有些人试图与其他PGP用户会面，以交换密钥并更安全地在此“信任网络”中注册。 其他人则组织关键签署方。 如果您想像一下所有这些活动，那么很明显，专用PGP爱好者切换到新技术有多么困难。

但是整个系统在实践中不起作用。 具有密钥签名的信任网络，密钥服务器或参与者都没有。 普通人将信任所有看起来像PGP密钥的东西，无论它来自何处-即使专家难以制定如何评估密钥的方式，他们也将如何信任？ 专家不信任自己没有收到的密钥。 其他所有人都依赖于集中式密钥分发服务。 PGP密钥分发机制是一个马戏团。

元数据泄漏

一秒钟，不用担心电子邮件崩溃（我们稍后会再讲）。 PGP本身会泄漏元数据。 在正常使用中，消息直接与整个PGP信任网络中与用户标识符相关联的密钥标识符相关联。 另外，相当大比例的PGP用户使用自己向网络发布的密钥服务器，PGP用户相互之间交换消息。

没有直接保密

恰当的例子：用于安全消息传递的加密要求前向保密。 直接保密意味着，如果攻击者收到您的密钥，他仍然将无法阅读以前的消息。 在现代密码学中，我们假设对手将所有内容都写入了无限存储中。 PGP的反对者包括世界各国政府。 当然，其中一些人会这样做。 对于严重的对手，在没有直接保密的情况下破解密码只是时间问题。

为了在实践中确保直接保密，您通常会保留两个秘密密钥：短期会话密钥和长期可信密钥。 会话密钥是临时的（通常是DH交换产品），并且受信任的密钥对其进行签名，因此中间的人无法使用自己的密钥。 从理论上讲，可以使用PGP工具实现直接保密。 当然，几乎没有人这样做。

斧头键

OpenBSD表示公共密钥是一个Base64字符串，足够短以适合电子邮件中句子的中间部分。 不是交换格式的私钥只是一个字符串左右。 PGP公钥是一个巨大的Base64文档。 如果您经常使用它们，则可能已经习惯于将它们粘贴在附件中，而不是将其粘贴在邮件中以免损坏它们。 符号密钥由高级Ed25519算法生成，PGP由较弱的RSA生成。

您可能会认为这无关紧要，但是很重要。 与PGP相比，使用SSH和管理SSH密钥的人数增加了数个数量级。 SSH密钥处理起来很简单。 PGP-不。

和解

PGP支持ElGamal，RSA，NIST p曲线，Brainpool，Curve25519，SHA-1，SHA-2，RIPEMD160，IDEA，3DES，CAST5和AES。 这不是PGP支持的完整列表。

如果在过去的20年中，我们了解了有关密码学的三件事，至少其中两件事，那就是和解与兼容性是邪恶的。 通常，密码系统的缺点出现在实现中，而不是原始类型，并且扩展的密码兼容性增加了实现的数量。 诸如TLS 1.3之类的现代协议试图摆脱与RSA之类的陈旧性的向后兼容性，而不是添加它。 较新的系统仅支持一组原语和一个简单的版本号。 如果这些原语之一失败，那么您将放弃该版本并立即删除整个旧协议。

如果我们不走运，并且20年后人们仍然会使用PGP，则这仍然是至少在某处应用CAST5标准的唯一原因。 我们不能说得更清楚些，我们需要重复很多次：要么您与90年代的程序向后兼容，要么您的密码学很好； 你不能两者兼得。

垃圾桶代码

PGP的事实上的标准实现是GnuPG。 这个程序写得不是很整齐。 C语言有广泛的代码库，并且具有重复的功能（例如，在最近对SKS解析的拒绝服务攻击的描述中，据说它具有多个关键解析器），CVE记录很长，从内存损坏到加密攻击通过第三方渠道。 有时可以从消息中删除身份验证，但是GnuPG并未注意到这一点。 您可以在没有正确指纹的情况下给他喂钥匙。 在2018年，Efail漏洞是由GnuPG根据要求提供未经身份验证的纯文本的事实引起的。 GnuPG不好。

GnuPG既是PGP的参考实现，也是大多数其他PGP密码集成工具的基础。 他不会去任何地方。 依赖PGP意味着依赖GPG。

答案

要说服一个人放弃PGP，请务必向他解释PGP无可替代，这很正常 。 替代工具取决于任务。

对话内容

使用信号。 或Wire，WhatsApp或其他基于Signal协议的安全Messenger。

现代安全信使是专为消息传递而设计的。 他们使用机密身份验证握手，消息取消，为每个消息交换提供密钥的加密棘轮 ，以及现代加密原语。 Messenger的使用非常简单，没有按键和子按键的麻烦。 如果您使用Signal，您将获得更多：您会变得对保存来自服务器的私有元数据感到非常狂妄，它甚至通过隧道Giphy搜索查询来避免流量分析攻击，并且直到最近它甚至还不支持用户配置文件。

邮件加密

不要这样做。

电子邮件不安全 。 即使使用PGP，默认情况下这也是纯文本格式，也就是说，即使您正确执行了所有操作，某些完全合理的信件收件人，做绝对合理的事情也必定会将加密邮件的纯文本引用给CC中的其他人（我们不知道电子邮件用户PGP邮件，没有遇到此问题）。 PGP电子邮件中没有直接保密。 电子邮件元数据（包括主题（实际上是消息的内容））始终以明文形式传输。

如果您需要其他原因，请阅读Efail漏洞文章 。 GnuPG社区未能披露有关Efail的信息 ，但对其提出了强烈的批评，但在Usenix Security（软件安全性最高的学术中心之一）以及Black Hat USA会议（领先的软件安全性会议）上被接受。 这是过去五年中最好的加密攻击之一，并且是对PGP生态系统的破坏性炸弹。 正如您将从文章中看到的那样，S / MIME并不更好。

它永远不会被修复。 要制作真正安全的电子邮件，您必须通过电子邮件建立另一个协议的隧道（您仍然容易受到流量分析的攻击）。 这就是重点，为什么要装作呢？

加密电子邮件会带来麻烦。 如果出现威胁，鼓励用户加密电子邮件是一种过失。 告诉您有关使用PGP加密的电子邮件通信的安全性的任何人都将其奇怪的偏好置于您的安全之上。

发送文件

使用魔术虫洞 。 蠕虫客户端将一次性密钥认证与密码认证（PAKE）结合使用来加密文件。 这很容易（至少对于书呆子而言），安全且有趣：我们向其展示“痣洞”的每个人都立即开始将所有文件连续地传递给我们，就像我们所做的那样。

有人立即在Rust或Go上启动Windows的安装程序，这个程序太酷了，无法使用它。

如果您与律师而不是工程师交谈，Signal可以很好地完成文件传输。 对于错误报告，请发布信号编号，而不是PGP密钥。

备份加密

使用Tarsnap。 Colin将说明Tarsnap如何优化以保护备份 。 或确实采取其他备份加密工具； 它不会像Tarsnap那样好，但是仍然会比PGP更好。

需要离线备份吗？ 使用磁盘映像加密； 它内置于Windows，Linux和macOS的现代版本中。 全盘加密不是很好，但是它可以很好地完成此任务，并且比PGP更简单，更安全。

包裹签名

使用Signify / Minisign。 泰德·安格斯特（Ted Unangst）会告诉你一切 。 此工具用于在OpenBSD中对软件包进行签名。 它非常简单，并应用了现代签名。 Frank Denis Minisign （libsodium开发人员之一）在Windows和macOS上实现了相同的设计。 它具有对Go，Rust，Python，Javascript和.NET的绑定； 它甚至与Signify兼容。

应用程序数据加密

使用libsodium：这是一个通用的库，带有一个很难出错的接口，并且您不需要二进制文件即可工作。

文件加密

这确实是一个问题。如果您具有/否/备份，/否/存档用于长期脱机存储，/否/用于传输的文件加密和/否/根据需要装入/卸载的虚拟磁盘的加密，那么没有一个好的工具可以加密文件。出于其他目的，菲利波·沃尔索达（Filippo Walsorda）正在开发一种年龄工具，这似乎很有希望，但尚未准备好。

希望这是一个非常狭窄的用例。我们从事软件安全领域的工作，并处理机密数据，包括错误报告（当他们大喊“我们需要PGP！”时，这是另一种很常见的情况），但几乎从未使用PGP。