I2P 开发者会议 - 2006年2月7日

15:36 <jrandom> 0) 嗨 15:36 <jrandom> 1) 网络状态 15:36 <jrandom> 2) _PRE 网络进展 15:36 <jrandom> 3) I2Phex 0.1.1.37 15:36 <jrandom> 4) ??? 15:36 <jrandom> 0) 嗨 15:37 * jrandom 挥手 15:37 <jrandom> 每周状态备注已发布在 @ http://dev.i2p.net/pipermail/i2p/2006-February/001258.html 15:37 <bar> 你好 15:38 <jrandom> 当你们翻那份哦-如此-刺激的材料时，我们先进入 1) 网络状态 15:38 <jrandom> 从 i2p 的角度看，上周线上网络变化不大，所以我这儿也没太多可补充的 15:39 <jrandom> 有人想就当前网络状态提些什么吗？ 15:39 <KBlup> 我在长时间运行 i2p 时看到客户端失败的可怕飙升……不确定这是否算 1) 里的内容 15:39 <jrandom> KBlup：这是否与高 CPU 负载或带宽消耗相关？ 15:40 <KBlup> 结果是 msg-delay> 10000ms :-/ 15:40 <jrandom> 啊，这很可能是开发 _PRE 网络的原因之一 :) 15:40 <KBlup> 我想它随后会尝试建立新的 tunnels，并不断失败，导致有时出现 300+ 个任务…… 15:41 <KBlup> 我的机器相当强，但因此还是过载了…… 15:41 <jrandom> 是的，这些都已经为 0.6.1.10 做了重构，在它准备好之前请耐心等待 15:43 <jrandom> 好的，关于 1) 还有别的吗，还是我们慢悠悠地转到 2) _PRE 网络进展 15:43 <+Complication> 0.6.1.10 看起来确实包含了大量改动 15:45 <jrandom> 是啊，这里有很多干货。当前状态是新的创建代码已就位且似乎运行正常，不过我正借此机会进一步调试一些底层问题 15:46 <+Complication> 你提到必须预先投入大量 CPU 时间 15:47 <+Complication> 这种开销现在会与构建任何类型的 tunnel 相关联吗？ 15:48 <+Complication> （意思是，在构建之前的短时间内，你需要执行一批重量级的加密运算） 15:48 <jrandom> 是的，所有 tunnel 构建请求都需要进行 k 次高强度的加密运算（其中 k = 正在构建的 tunnel 的跳点数） 15:49 <+Complication> 我想问的是……只是间隔比以前更紧了，还是数量也更大了？ 15:50 <jrandom> 既更大，也更小，也更紧。更紧，是因为它们都提前做完。更大，是因为如果较早的跳点拒绝，我们不能走捷径而不为某个跳点做加密；更小，是因为较早的跳点失败少了很多 15:51 <jrandom> 此外，与早期版本不同，我们不再对 tunnel 请求使用 ElGamal（算法）/AES+SessionTag——我们使用（相当）直接的 ElGamal 15:52 <+Complication> ……除非你知道最终会成功的集合，否则无法预先计算，对吗？ 15:52 <jrandom> 这意味着虽然以前我们可以在没有非对称操作的情况下“作弊”，但现在不再这么做了（因为这种作弊本身暴露了一类攻击） 15:53 <+Complication> （节点集合） 15:53 <jrandom> 嗯，当然可以预先计算，前提是你知道要在该 tunnel 中询问哪些节点 15:54 <jrandom> 新的 tunnel 创建过程在单独的线程中进行，这样在负载下就不会拖慢主任务队列，并且能更好地自我节流 15:54 <+Complication> 还能否假设：在可用信息不变的情况下，如果尝试失败，至少知道接下来要询问的几个对象？ 15:54 <jrandom> 嗯，我不太确定我跟上了 15:55 <+Complication> 或者说，知道这些也没用，因为该结构必须从头重做？ 15:56 <+Complication> （意思是：至少那些 ElGamal 要从头重新计算） 15:56 <jrandom> 啊，该结构是 http://dev.i2p.net/cgi-bin/cvsweb.cgi/i2p/router/doc/tunnel-alt-creation.html?rev=HEAD#tunnelCreate.requestRecord 15:56 <jrandom> 所以，是的，如果下一跳改变，ElGamal 必须重做 15:56 <jrandom> （如果你预计算） 15:56 <+Complication> 对，我当时不太肯定 15:57 <+Complication> 不过现在我明白了 15:57 <jrandom> 另一方面，我们确实在努力提高构建成功率，而新的构建流程应能自适应，尽量减少不必要的创建 15:58 <+Complication> 实际效果如何？ 15:58 <jrandom> （哦，该结构在 _PRE 分支上稍作了修改：http://dev.i2p.net/cgi-bin/cvsweb.cgi/~checkout~/i2p/router/doc/tunnel-alt-creation.html?rev=1.1.2.1;content-type=text%2Fhtml#tunnelCreate.requestRecord ） 15:59 <+Complication> 我注意到 ElGamal 加密速度有了飞跃…… 15:59 <jrandom> 嗯，构建成功率比线上网络高得多，但这可能只是因为 _PRE 网络规模较小 16:00 <jrandom> 是的，比如创建一个 2 跳结构，1120 次运行的平均耗时为 44ms；相比之下，线上网络的 ElGamal 加密时间为 542ms（基于 1344 次运行） 16:02 <jrandom> （在同一台机器上） 16:02 <+Complication> 这个 542 是否也包含失败后的重试，还是仅指纯构建？ 16:02 <+Complication> 如果只是纯构建，我得把下巴找回来……它掉在地上某处了。 :P 16:02 <KBlup> 关于指数变化：这会在多大程度上影响匿名性？ 16:02 <jrandom> 不，那是纯 ElGamal 统计，因为线上网络并未构建新的 _PRE 网络结构 16:04 <jrandom> KBlup：匿名性？没有影响。安全性？据我所读，228 位已经足以匹配 2048 位的 ElGamal 16:04 * Complication 不太了解 ElGamal 的 x 和 y 16:04 <+Complication> 不足以做出有意义的评论 16:06 <+Complication> 如果严肃研究者认为更短的 x 仍然足够难，而那些密码学怪才也没有尖叫着逃跑…… 16:06 <@cervantes> 不仅如此，还有降到 1024/160 的影响 16:07 <KBlup> 我想我得晚点去读那篇论文 ;) 16:07 <+Complication> cervantes：是的，肯定比那更好 16:08 <+Complication> 此外，这个密码体制首先需要抵御的攻击是什么？这种攻击的有效期有多长？ 16:09 <+Complication> 是否只有在短时间内破解才有价值，还是即便最终破解也有收益？ 16:11 <+Complication> 如果我理解正确，它直接保护的秘密是下一个 tunnel 的参与者，对吗？ 16:11 <+Complication> （更准确地说，是下下一个） 16:11 <@modulus> 会议还在进行吗？ 16:11 <+Complication> （只有下一个才可能知道） 16:11 <@cervantes> modulus: ayre 16:11 <@cervantes> -r 16:11 <jrandom> 对于一个现实的（但强大到离谱的）对手，必须在 tunnel 的生命周期内将其攻破。若在该 tunnel 生命周期结束后才攻破，只有在你记录了所有网络流量并攻破了所有 tunnels 的情况下才有用（也就是说，在破解临时性的传输层加密之后再去处理 tunnel 层加密） 16:11 <jrandom> 所以，我们说的是几分钟量级，而不是几十年 16:12 <jrandom> （因此 1024 位可能都算过度） 16:12 <@cervantes> 有办法以有意义的方式评估风险吗？ 16:13 <+Complication> 另外，对于跳点更多的 tunnel，对手得破好几个，对吧？ 16:13 <+Complication> （不过构建者也要构建多个） 16:13 <@cervantes> 如果我们不需要超过 1024 位，那真的有必要用更多吗？ 16:14 <@cervantes> 三年后当我们有强大得多的量子计算机时，我们随时可以换用更强的算法 16:14 <@modulus> jrandom：如果对手知道在 hh:mm 会有重要数据通过 tunnel，他们是否有可能通过记录来破解？ 16:14 <jrandom> Complication：对，他们得破好几个（以及保护传输层的 DH（Diffie-Hellman）密钥） 16:14 <@modulus> 据我所知 1024 位在算力很强的情况下是可以 break() 的 16:15 <jrandom> 需要大量算力和十年 16:15 <jrandom> （或三十年） 16:15 <@cervantes> jrandom：尝试更弱的密码体制很难吗？ 16:15 <@modulus> 我原以为如今 1024 位合数在几个月内就能被因式分解。 16:15 <@cervantes> 我们能先部署到 _PRE 网络 16:15 <@cervantes> 然后看看是否真的带来很多好处吗 16:16 <@cervantes> modulus：是的，但他们需要破好几个 16:16 <@modulus> 如果这是基于离散对数域那些东西，那我就啥也不懂了 16:16 <@modulus> cervantes：啊哈 16:16 <jrandom> cervantes：这需要修改很多结构，因为我们目前使用 512 字节的槽位。不过，也许我们可以在测试时先用 0x00 填满前 256 字节 16:17 <jrandom> modulus：ElGamal 基于离散对数 16:17 <@cervantes> jrandom：值得测试吗？ 16:17 <@modulus> 对对，我刚才想成了 RSA 16:17 <@cervantes> 还是更好专注于其他事情，必要时再回头？ 16:18 <jrandom> 绝对值得测试，不过此刻我正埋头做一些传输层评估 16:18 <+Complication> 我想这取决于在现实中计算如何处理。 16:18 <jrandom> （而且 44ms 的加密时间目前已经够用，尽管 4ms 会更好 :) 16:19 <+Complication> 如果在现有计算机上还能顶得住，那么新机器上会更好。 16:19 <@modulus> 尤其是如果出现专用加密硬件，在某些领域已经开始出现了 16:19 <jrandom> 当然，更改这个参数不会轻易或立刻进行。但如果有人有充分理由不要这么做，请联系我 16:21 <jrandom> modulus：我听说过专用的 AES 和 RSA 芯片，但没听说过 DH/ElGamal。另一方面，把 NSA/等机构当作对手来看，他们可以自己做，这是有可能的 16:22 <@cervantes> 他们有基于撒糖针甜甜圈环技术构建的加密机器 16:23 * Complication 愿意把 Celeron 300 升级到 Athlon 600，如果这能挡住撒糖针甜甜圈的浪潮 :D 16:23 <tethra> 呵呵 16:24 <jrandom> 嗯嗯嗯 甜甜圈 16:25 <jrandom> 好的，关于 2) _PRE 网络进展，还有别的吗？ 16:25 <jrandom> 如果没有，我们跳到 3) I2Phex 0.1.1.37 16:26 <jrandom> Complication：给我们说说要点？ 16:26 <+Complication> 嗯，看起来能用。 :) 16:26 <+Complication> 有望很快获得更多 webcaches 以增加冗余。 16:27 <jrandom> 好 16:27 <jrandom> 嗯，你觉得我们需要更多 webcaches 吗？有一个可用不就够了吗？当然，多一些也无妨 16:27 <+Complication> （如果 legion 能解决困扰他初次尝试的那些谜团） 16:27 <+Complication> 里面还有个神秘的 Bug，但它不太严重，我正试着找到它。 16:28 <+Complication> 有一个可用就足够了 16:28 <+Complication> 多一些只是提高有一个在线的概率 16:28 <jrandom> 不错 16:28 <+Complication> 因为在当前阶段，它不会把 webcaches 标记为坏并丢弃——总数太少了。 16:29 <+Complication> （该例程在数量超过 10 时才会触发） 16:29 <+Complication> （如果我没记错的话） 16:29 <+Complication> 至于这个 Bug：运行很久之后，webcache 子系统有时会卡住 16:30 <+Complication> 很可能是某个 httpclient 的 GET 请求无法成功中止 16:31 <@modulus> 所以它需要不时挂掉？ 16:31 <+Complication> 它是安全的，而且似乎从不影响新加入的机器 16:31 <jrandom> 嗯，这在功能上意味着什么？过一阵子它会停止向 webcache 注册，因此新人不会被提供他们的引用？ 16:31 <+Complication> 如果它影响到一台已经很好融入的机器，那台机器可以从它已连接的节点那里获得足够的节点 16:31 <+Complication> 所以目前影响几乎为 0 16:31 <@modulus> 酷 16:32 <+Complication> 只是挺古怪的 16:32 <@modulus> 没有关于何时会失败的规律吗？ 16:32 <+Complication> modulus：一般不会在 20 小时之前发生 16:33 <+Complication> 而且我又没法强制它重现，调试有点慢 16:33 <@modulus> :_) 16:34 <+Complication> 不管怎样，找到就修，找不到就去折腾别的东西 :) 16:34 <jrandom> :) 16:34 <jrandom> 听起来像是我们在 streaming lib / eepproxy 见过的一些 Bug 的症状，所以修了那些应该也会修好这个 16:35 <+Complication> 可能吧 16:38 <jrandom> 好的，很棒，干得好 Complication 16:38 <jrandom> 关于 3) I2Phex 0.1.1.37 还有别的吗，或者我们跳到大杂烩 4) ??? 16:41 <jrandom> （就当我们已经跳过去了） 16:41 <jrandom> 好的，这次会议还有别的吗？ 16:42 <tmp> 否则你就永远屏住呼吸？ 16:43 <jrandom> 永远永远 16:43 * jrandom 做结束准备 16:43 * jrandom 将会议*baf*地宣布结束