LibrePGP 是 OpenPGP 加密标准的更新替代规范
加密和签名工具的主要开发者和维护者 Werner Koch 的主要开发者和维护者 广为人知 前几天的消息创建 LibrePGP 项目，是的 一把叉子 专注于开发更新的替代规范 符合 OpenPGP 标准。
有人提到 原因之内 这个分叉的创建 显然是为了回应争议 互联网工程任务组内 (IETF) 关于 OpenPGP 标准的未来发展，因为 Koch 认为即将发布的 OpenPGP 规范更新从兼容性和安全角度来看是有问题的。
根据科赫的说法：
他表示，IETF 内部工作分离和 LibrePGP 启动的出发点是，计划对 OpenPGP 标准 (RFC 4880) 的更新“不利于 OpenPGP 软件的当前使用”。他在广告中写道。在不讨论具体技术细节的情况下，争论又回到了如何适应当前 OpenPGP 标准以适应未来的问题。
而我ETF 没有逐步更新规范，而是试图重新发明标准 除了强制支持很难正确实现的GCM对称加密模式之外，还对其进行了违反互操作性的重大更改，忽略了专利几年前到期的OCB（偏移码本模式）。
支持该分叉的 GnuPG、RNP（Thunderbird OpenPGP 实现）和 Gpg4win 项目的开发人员担心，计划中的更改将不利于基于 OpenPGP 的应用程序的现有实现，而这些应用程序的用户希望该规范长期稳定。尚未准备好支持破坏兼容性的更改。
除此之外， LibrePGP 创建者质疑添加带有随机填充的可选包 以防止流量分析。据他们称，这些具有不可验证的初始随机填充的数据包构成了被用来创建隐藏数据传输通道并绕过数据泄漏预防系统的威胁。此前，包含填充的想法被视为应用程序级问题而不是加密级问题而被拒绝。
此外， 他们还质疑使用修改后的 ECDH 加密方案，而不是使用 RFC-6637 中已经描述并在 PGP 和 GnuPG 中实现的选项，以及消除一些实用功能，例如经典的密钥撤销方法、用于标记 MIME 数据的“m”标志和“t ” 标志将文本与二进制数据分开（对于 UTF-8 编码文本，“t”标志被“u”标志取代）。
考虑到这个问题和其他问题，造成这种情况的原因是什么？ 创建 LibrePGP，它被提到结合了近年来为 OpenPGP 规范的未来版本开发的有用改进，但避免了会对兼容性产生负面影响的更改。例如，与当前的RFC-4880标准相比， LibrePGP 采用了以下功能：
- 支持Camellia加密算法（RFC-5581），
- OpenPGP 的 ECC（椭圆曲线加密）扩展 (RFC-6637)。
- 强制支持 SHA2-256 哈希（SHA-1 和 MD5 被归类为不推荐，并且无需完整性检查即可解密数据的能力被归类为完全弃用）。
- 将指纹大小增加到 256 位。
- 支持EdDSA数字签名方案和BrainpoolP256r1、BrainpoolP384r1、BrainpoolP512r1、Ed25519、Curve25519、Ed488和X448椭圆曲线签名方案。
- 支持 CRYSTALS-Kyber 算法，该算法在量子计算机中难以选择。
- 支持 OCB（偏移码本模式）认证加密模式。
- 实施具有元数据保护的第五版数字签名格式。
- 支持带有数字签名的扩展分包。
最后值得一提的是OpenPGP的支持者 他们已经发表了一个又一个的批评。因此，如果无法找到折衷方案，分裂可能会导致 OpenPGP/LibrePGP 实现中的不兼容性增加。为了部分解决这个问题，OpenPGP 开发人员修复了第五版本的签名格式，使其与 LibrePGP 兼容，并继续开发第六版本。
如果你是 有兴趣了解更多，您可以查看详细信息 在下面的链接.