RI 和目标填充

状态

在 0.9.57 中实施。 保持此提案开放，以便我们在“未来规划”部分加强和讨论这些想法。

概述

摘要

自 0.6 版本（2005 年）发布以来，目标中的 ElGamal 公钥一直未被使用。 虽然我们的规范确实说明了它未被使用，但并没有明确告诉实现者可以避免生成 ElGamal 密钥对，并简单地用随机数据填充该字段。

我们提议更改规范，以说明该字段被忽略，并且实现可以选择用随机数据填充该字段。 此更改是向后兼容的。没有已知的实现去验证 ElGamal 公钥。

此外，此提案为实现者提供了指导，关于如何为 Destinations 和 Router Identity 生成随机数据的填充，使其可被压缩且仍然安全，同时不让 Base 64 表示看起来是损坏或不安全的。 这提供了去除填充字段的大部分好处，而不会带来任何破坏性的协议更改。 可压缩的目标减少了流媒体 SYN 和可回复数据报的大小； 可压缩的路由器身份减少了数据库存储消息、SSU2 会话确认消息和重新播种 su3 文件的大小。

最后，提案讨论了可能的新目标和路由器身份格式，这将完全消除填充。此外，对后量子密码学及其可能影响未来规划的方式进行了简要讨论。

目标

• 消除为目标生成 ElGamal 密钥对的要求
• 推荐最佳实践，使目标和路由器身份高度可压缩，但 Base 64 表示中不出现明显的模式。
• 鼓励所有实现采用最佳实践，以便字段不可区分
• 减少流媒体 SYN 大小
• 减少可回复数据报大小
• 减少 SSU2 RI 区块大小
• 减少 SSU2 会话确认大小和碎片化频率
• 减少数据库存储消息（带 RI）大小
• 减少重新播种文件大小
• 在所有协议和 API 中保持兼容性
• 更新规范
• 讨论新目标和路由器身份格式的替代方案

通过消除生成 ElGamal 密钥的要求，实现者可以完全移除 ElGamal 代码，视其他协议的向后兼容性考虑而定。

设计

严格来说，单独的 32 字节签名公钥（在目标和路由器身份中）和 32 字节的加密公钥（仅在路由器身份中）是一个随机数，提供了 SHA-256 散列在这些结构中拥有的所有必要熵，使其在网络数据库 DHT 中具有密码学上的强度和随机分布特性。

然而，出于谨慎考虑，我们建议在 ElG 公钥字段及填充中至少使用 32 字节的随机数据。此外，如果字段全为零，Base 64 目标将包含长串的 AAAA 字符，这可能会引起用户的警觉或困惑。

对于 Ed25519 签名类型和 X25519 加密类型： 目标将包含随机数据的 11 个副本（352 字节）。 路由器身份将包含随机数据的 10 个副本（320 字节）。

预计节省

在每个流媒体 SYN 和可回复数据报中都会包含目标。 数据库存储消息中的路由器信息（包含路由器身份），以及在 NTCP2 和 SSU2 中的会话确认消息中也有这些信息。

NTCP2 不压缩路由器信息。 数据库存储消息和 SSU2 会话确认消息中的 RIs 是经过 gzip 压缩的。 重新播种 SU3 文件中的路由器信息是经过压缩的。

数据库存储消息中的目标没有压缩。 流媒体 SYN 消息在 I2CP 层是经过 gzip 压缩的。

对于 Ed25519 签名类型和 X25519 加密类型，预计节省如下：

注：假设 7 字节证书不可压缩，零附加 gzip 开销。两者都不是真的，但影响很小。 忽略路由器信息的其他可压缩部分。

规范

我们当前规范的建议更改在下方记录。

通用结构

修改通用结构规范以指定 256 字节目标公钥字段被忽略，并可包含随机数据。

在通用结构规范中添加一个章节，推荐目标公钥字段和目标与路由器身份中的填充字段的最佳实践，如下：

使用强大的密码学伪随机数生成器 (PRNG) 生成 32 字节的随机数据，并根据需要重复这 32 字节以填充公共钥(field 字段（对于目标））和填充字段（对于目标和路由器身份）。

私钥文件

私钥文件（eepPriv.dat）格式不是我们规范的正式部分，但它在 Java I2P javadocs 中已文档化，其他实现也支持它。这使私钥能在不同实现之间便携。添加一个注解到该 javadoc，说明加密公钥可能是随机填充，而加密私钥可能全是零或随机数据。

SAM

在 SAM 规范中指出加密私钥未使用，且可能被忽略。客户端可能会返回任意随机数据。SAM Bridge 在创建时（通过 DEST GENERATE 或 SESSION CREATE DESTINATION=TRANSIENT）可能发送随机数据，而不是全零，这样 Base 64 表示就不会显示一串 AAAA 字符，看起来是损坏的。

I2CP

无需对 I2CP 做出任何更改。目标中的加密公钥的私钥不会发送到路由器。

未来规划

协议变更

在协议更改和缺乏向后兼容性的成本下，我们可以更改我们的协议和规范，以消除目标、路由器身份或两者中的填充字段。

该提案与 “b33” 加密租赁集格式有些相似，仅包含一个密钥和一个类型字段。

要保持某种兼容性，某些协议层可以用全零“扩展”填充字段，以便呈现给其他协议层。

对于目标，我们还可以去除密钥证书中的加密类型字段，从而节省两个字节。 或者，目标可以在密钥证书中获得一个新的加密类型，指示一个零公钥（和填充）。

如果在某些协议层中没有包括旧格式和新格式之间的兼容转换，以下规范、API、协议和应用程序将受到影响：

• 通用结构规范
• I2NP
• I2CP
• NTCP2
• SSU2
• Ratchet
• Streaming
• SAM
• Bittorrent
• 重新播种
• 私钥文件
• Java 核心和路由器 API
• i2pd API
• 第三方 SAM 库
• 捆绑和第三方工具
• 几个 Java 插件
• 用户界面
• P2P 应用程序，如 MuWire、比特币、门罗币
• hosts.txt、地址簿和订阅

如果在某个层中指定转换，列表将会缩减。

这些更改的成本和收益尚不明晰。

具体建议待定：

PQ 密钥

后量子（PQ）加密公钥，对于任何预期的算法，都是超过 256 字节的。这将消除任何填充和上述建议变更带来的节省，对于路由器身份而言。

在“混合”PQ 方法中，就像 SSL 正在做的那样，PQ 密钥仅为临时密钥，并不会出现在路由器身份中。

PQ 签名密钥不可行，目标不包含加密公钥。 ratchet 的静态密钥在租赁集中，而不在目标中。 因此我们可以将目标从后续讨论中排除。

因此，PQ 仅影响路由器信息，并且仅对 PQ 静态（非临时）密钥，而不是 PQ 混合体。 这将是一个新的加密类型，会影响 NTCP2、SSU2 和加密的数据库查找消息和回复。 设计、开发和推出的预计时限是？？？？？？？？？？ 但会是在混合体或 ratchet 之后？？？？？？？

有关进一步讨论，请参见 this topic 。

问题

可能需要以缓慢的速率重新密钥网络，以为新的路由器提供掩护。“重新密钥”可能仅意味着更改填充，而不是真正更改密钥。

无法对现有的目标进行重新密钥。

路由器身份中填充在公钥字段中的应否通过密钥证书中的不同加密类型识别？这将导致兼容性问题。

迁移

用填充替换 ElGamal 密钥时，没有向后兼容性问题。

如果实施重新密钥，它将类似于之前路由器身份过渡中的三次： 从 DSA-SHA1 到 ECDSA 签名，接着到 EdDSA 签名再到 X25519 加密。

受限于向后兼容性问题，以及在禁用 SSU 之后，实现可能会完全移除 ElGamal 代码。 网络中约 14% 的路由器是 ElGamal 加密类型，包括许多 floodfills。

Java I2P 的草稿合并请求在 git.idk.i2p 。