嗨，大家，又到了每周的那个时候了，

  • Index
  1. 开发状态 2) Tunnel IVs（初始化向量） 3) SSU MACs（消息认证码） 4) ???
    1. Dev status

又过了一周，又有一条消息说 “SSU 传输方面取得了很大进展” ;) 我的本地修改已经稳定，并已提交到 CVS（HEAD 目前在 0.5.0.7-9），但还没有发布。很快会有更多这方面的消息。与 SSU 无关的更改细节已经写在历史记录 [1] 中，不过到目前为止我把 SSU 相关的更改排除在该列表之外，因为现在还没有非开发者在使用 SSU（而开发者会看 i2p-cvs@ :)）

[1] http://dev.i2p.net/cgi-bin/cvsweb.cgi/i2p/history.txt?rev=HEAD

    1. Tunnel IVs

在过去几天里，dvorak 一直在发布一些关于如何攻击 tunnel 加密的偶尔想法，虽然其中大多数已经得到应对，但我们确实想出了一个场景，使参与者能够标记一对消息，从而确定它们属于同一个 tunnel。其工作方式是：较早的节点先让一条消息从自己身边通过，随后把那第一条 tunnel 消息的 IV（初始化向量）和第一个数据块取出，替换到一条新的消息中。这条新的消息当然会损坏，但看起来不像重放，因为 IV 不同。沿途的第二个节点随后可以丢弃该消息，这样 tunnel 端点就无法检测到该攻击。

其背后的核心问题之一在于：若不引发一大批攻击，就没有办法在 tunnel 消息沿 tunnel 传递的过程中对其进行验证（参见早先的 tunnel 加密提案[2]，其中提出了一种较为接近的方法，但其概率假设相当不可靠，并且对 tunnels 施加了一些人为的限制）。

[2] http://dev.i2p.net/cgi-bin/cvsweb.cgi/i2p/router/doc/tunnel.html?rev=HEAD

不过，对于上面概述的这种特定攻击，有一个很简单的规避方法——只需将 xor(IV, first data block) 视为要送入布隆过滤器的唯一标识符，而不是只使用 IV（初始化向量）。这样，中间的对等节点会在其到达第二个串通的对等节点之前识别为重复并将其丢弃。CVS 已更新以包含这一防御，不过鉴于当前的网络规模，我非常非常怀疑这会构成实际威胁，因此我不会单独把它作为一个发布版本推出。

不过，这并不影响其他时序攻击或 shaping 攻击（基于流量整形的攻击）的可行性，但在我们发现那些容易处理的攻击时，最好先把它们解决掉。

    1. SSU MACs

如规范 [3] 所述，SSU 传输为每个传输的数据报使用 MAC（消息认证码）。这是在每个 I2NP 消息随附的验证哈希（以及客户端消息上的端到端验证哈希）之外的。当前，规范和代码使用的是截断的 HMAC-SHA256——只传输并验证 MAC 的前 16 个字节。这咳有点浪费，因为 HMAC 在其运算中会调用两次 SHA256 哈希，每次都计算一个 32 字节的哈希，而最近对 SSU 传输的性能剖析表明，这已经接近 CPU 负载的关键路径。为此，我尝试用普通的 HMAC-MD5(-128) 替换 HMAC-SHA256-128——尽管 MD5 显然不如 SHA256 强，但反正我们把 SHA256 截断到与 MD5 相同的大小，因此发生碰撞所需的穷举工作量是一样的（2^64 次尝试）。我目前在做一些尝试，提速非常可观（在 2KB 数据包上，HMAC 吞吐量比使用 SHA256 高出 3 倍以上），所以也许我们可以改用它上线。或者，如果有人能给出不这么做的充分理由（或更好的替代方案），切换起来也很简单（只需改一行代码）。

[3] http://dev.i2p.net/cgi-bin/cvsweb.cgi/i2p/router/doc/udp.html?rev=HEAD

    1. ???

目前大致就是这些，一如既往，欢迎随时提出你的想法和顾虑。现在即使没有安装 junit，也可以再次构建 CVS HEAD（目前我已将测试从 i2p.jar 中移除，但仍可通过 test 的 ant target 运行）。我预计很快会有关于 0.6 测试的更多消息（我现在还在和 colo box（托管服务器）的各种怪异问题斗争——在本机上通过 telnet 连接我自己的接口会失败（没有有用的 errno），但远程却可以，而且没有任何 iptables 或其他过滤器。真是“开心”）。我在家里仍然没有网络访问，所以今晚的会议我不会参加，也许下周可以。

=jr