I2P 开发者会议 - 2005年10月18日

16:10 <jrandom> 0) 嗨 16:10 <jrandom> 1) 0.6.1.3 16:10 <jrandom> 2) Freenet、I2P 和 darknets（天哪） 16:10 <jrandom> 3) Tunnel 引导阶段攻击 16:10 <jrandom> 4) I2Phex 16:10 <jrandom> 5) Syndie/Sucker 16:10 <jrandom> 6) ??? 16:10 <jrandom> 0) 嗨 16:10 * jrandom 挥手 16:10 <jrandom> 每周状态笔记已发布：http://dev.i2p.net/pipermail/i2p/2005-October/001017.html 16:10 <dust> 耶，现在能用了。谢谢 Gregor 16:10 <cervantes> 哈喽 16:11 <+fox> <blx> heloa 16:11 <jrandom> 好的，进入 1) 0.6.1.3 16:11 <jrandom> 大家升级得很快，谢谢！ 16:12 <jrandom> 情况看起来相当不错，不过除了状态笔记里写的，我也没太多可补充的 16:12 <jrandom> 关于 0.6.1.3，大家有问题/评论/担忧吗？ 16:13 <jrandom> 如果没有，那我们就快进到 2) Freenet、I2P 和 darknets（天哪） 16:13 <cervantes> 已知 609 个节点！ 16:14 <cervantes> （w00t） 16:14 <jrandom> 嗯，网络一直在增长 16:14 <+fox> <blx> oh my! 16:14 * cervantes 正在竞猜多久能到大 1000 16:14 <jrandom> 呵 16:14 <tethra> 呵呵 16:15 <tethra> 我们用数字现金打赌？ ;) 16:15 <cervantes> 但这也说明 I2P 核心最近很稳，用户增长在加速 16:16 <cervantes> 不……jrandom 已经在不知情的情况下把他今年所有的啤酒钱都捐了 16:16 <jrandom> 呵呵 16:16 <jrandom> 好，关于 2)，我也不确定还有啥可补充的（我觉得这匹马已经被鞭打够了）。有人对此有问题/评论/担忧吗？ 16:18 <cervantes> 正如你所说，就算没有别的，它至少激发了一些有意思、半相关的安全讨论，即 3) 16:18 <jrandom> 如果没有，我们可以快速进入 3) Tunnel 引导阶段攻击 16:18 <jrandom> 确实如此 16:19 <jrandom> Michael 提出的议题把我一直以来的一个总体看法量化了，但明确说出来还是很不错的 16:20 <jrandom> 今晚晚些时候会继续讨论那个较新的攻击（等我写好回复），不过前一个看起来不是什么大问题 16:21 <jrandom> 大家明白吗？或者对它有没有什么问题或担忧？ 16:22 <cervantes> 呵……这要么意味着大家都没问题，要么就是完全搞不清楚问题在哪 16:23 <cervantes> 我就把自己归到“无知者无畏”一类 16:23 <jrandom> 呵，基本上那是一种攻击：坏人碰巧成为你所建每条 tunnel 的出站端点 16:23 <jrandom> 而当你刚启动时，“你所建过的每条 tunnel”这个数量非常小（比如 0、1、2） 16:24 <jrandom> 但几秒之后，这个数量就会变大，把 (c/n)^t 变成一个非常非常小的数 16:25 <tethra> (c/n)^t 是…… 16:25 <jrandom> （这也是我们不会在启动后立刻启动 i2cp listener——因此也不会立刻启动 i2ptunnel 等——的原因之一） 16:25 <jrandom> c == 串通的节点数（坏人），n == 网络中的节点数，t == 你已经建过的 tunnels 数量。 16:25 <cervantes> 明白了…… 16:25 <tethra> 啊 16:26 <jrandom> 所以随着 t 增大，攻击成功的概率会变得非常小 16:26 <cervantes> 那么想要它有可行性，你得在启动后几分钟内就用你的 router 做敏感操作？ 16:26 <jrandom> （或者说，无论如何，它都比在一个 tunnel 中控制所有跳点的概率还要小） 16:26 <tethra> 啊，我懂了 16:27 <jrandom> cervantes：是立刻，在第三条 tunnel 建好之前 16:27 <jrandom> （假设你用的是 3 跳的 tunnels） 16:27 <cervantes> 这相当不大可能 16:28 <cervantes> 就使用场景而言 16:28 <jrandom> 没错。 16:28 <jrandom> 而且我们会在允许任何客户端运行之前，在启动时先构建超过 3 条 tunnels，这不仅仅是个概率问题 16:28 <jrandom> 但把这种攻击量化出来还是好的 16:29 <cervantes> 值得让 router 多运转一会儿来防范这种可能性吗？ 16:30 <cervantes> 或者运转更“卖力”些…… 16:30 <jrandom> 也许吧。如果我们忽略连接建立时间以及非随机的节点选择，那它的可能性为零 16:31 <tethra> 这应该值得来一句“woot!”吧？ 16:32 <jrandom> 是的，不过从工程角度看，我们不该忽略这些特性 ;) 16:32 <jrandom> 所以，对于 0.6.2，我们也许要在重做的 tunnel peer 选择/排序实现里看看，确保它行为合理 16:34 <jrandom> 好，如果 3) 没别的了，我们转到 4) I2Phex 16:34 <jrandom> sirup 不在，而且我没在 IRC 上见到 striker——redzara，你在吗？ 16:36 <+redzara> 在 16:36 <+redzara> 第一阶段快完成：把 Sirup 的修改移植到最新的 Phex CVS。 16:36 <jrandom> 给力！ 16:36 <+redzara> 接着：第二阶段：把 Sirup 代码与最初发行所用的 Phex 基础代码做 diff，确保我没漏掉任何东西 :) 16:37 <+redzara> 也许这个周末能完成 16:37 <jrandom> 哇，那太好了 16:37 <+redzara> 第三阶段：与 GregorK 一起重构通信层 16:37 <+fox> <GregorK> 希望你知道，在最新的 Phex CVS 里下载代码不稳定，而且下载文件和之前的版本不兼容 16:38 <jrandom> 这是 I2P，我们习惯不稳定了 :) 16:38 <+fox> <GregorK> :) 16:38 <+redzara> 最后一个阶段，因为我目前没有和 GregorK 取得联系，这会相当难 :( 16:38 <jrandom> GregorK：你建议怎么做集成？ 16:39 <+fox> <GregorK> 嗯你现在已经联系到我了 ;) 16:39 <jrandom> 啊，那就好 redzara，前两个阶段就已经够大了 :) 16:39 <+redzara> GregorK：嗨兄弟 16:40 <+redzara> GregorK：我把所有代码都细看了 16:40 <+fox> <GregorK> 我有个关于如何构建一层的想法……我可以尽量准备好，然后看看契合度如何，以及需要改什么 16:40 <+fox> <GregorK> 全都看了？？哇…… 16:40 <+redzara> Gregork：是的，全都看了！！ 16:41 <cervantes> 他连你内裤尺码都知道 16:41 <Rawn> :D 16:41 <+fox> <GregorK> 太好了……下次我去购物直接问你就行…… 16:43 <+fox> <GregorK> 如果能让 I2Phex 团队里有人同时加入 Phex 团队就更好了…… 16:43 <jrandom> redzara：那么，你觉得我们会先发一个 0.1.2 的 I2Phex 版本，包含你第二阶段的成果，然后再把一切合并到主线 Phex 的插件层里？还是一次到位？ 16:43 <+redzara> 抱歉，我的英语读/写/说都不够好，不太能听懂你刚才说的笑话 16:43 <+fox> <GregorK> 这样也有助于修复两边都会出现的 bug 16:44 <jrandom> GregorK：希望我们能找到一种方式，让 I2P 这边只是 Phex 里的一个薄插件，对吧？ 16:44 <jrandom> 或者你觉得两者应该保持分离？ 16:44 <+redzara> jrandom：我觉得我们可以让 Phex 2.6.4 跑在 I2P 上，对我来说 I2Phex 可以结束了 16:45 <jrandom> 结束了？ 16:45 <+fox> <GregorK> 我不确定一开始能不能做到这样，但我觉得大部分都可以拆分成一个插件。 16:45 <jrandom> 酷，这肯定是很多工作 16:46 <jrandom> 尤其是像 java.net.URL 这样的东西（在实例化时会泄露 DNS 请求等） 16:46 <+redzara> jrandom：结束了，终结 16:46 <+Ragnarok> grr 16:47 <jrandom> 好的对，redzara，一旦我们能让 Phex 2.6.4 在 I2P 上一切工作正常，我同意，似乎就不太需要一个单独的 I2Phex 了 16:47 <+fox> <GregorK> 对……我记得 Phex 有些地方用的是 apache 的 URI 类来绕过这个……不过只在必要时才用 16:48 <jrandom> 啊对，我记得玩过那个库，看起来不错 16:49 <jrandom> 在通过 I2P 面向终端用户之前，我们肯定会帮忙做一些匿名性/安全审计 16:49 <jrandom> （并不是说 Phex 有问题，而是每个应用都会有问题，希望我们能帮着理一理） 16:50 <+fox> <GregorK> 对于 Socket 的使用之类的我有个怎么平滑集成的想法……但其他地方，比如不同功能、UDP 等……我还不确定怎么做最好 16:50 <+fox> <GregorK> 哦我确定 Phex 里有很多问题。:) 16:50 <jrandom> 啊，是的，sockets 会很容易，但我们可能需要禁用其他一些东西。UDP 用来做什么——快速查询？ 16:51 <+fox> <GregorK> 目前只用于引导 16:51 <+fox> <GregorK> UDP Host Cache……是 GWebCache 的替代 16:52 <jrandom> 啊哈，明白。 16:52 <+redzara> 那如果我们有一个像样的 GWebCache，就不需要它了？ 16:53 <+fox> <GregorK> 是的……但标准的 GWebCache 也有它的安全问题…… 16:53 <+redzara> GregorK：在 I2P 内部应该没有 16:54 <jrandom> 哦，那部分可以克服——I2PSocket 是有认证的——你知道对端的“destination”（I2P 地址标识），所以他们不能说“我，呃……whitehouse.gov……对！” 16:54 <jrandom> 但你说得对，这需要验证一下 16:54 <+fox> <GregorK> 另外防火墙到防火墙传输也是个我们想用 UDP 做的主题，一旦找到志愿者就做 :) 16:54 <jrandom> 啊，I2P 不需要防火墙到防火墙传输——I2P 提供完全开放的端到端地址空间 :) 16:55 <jrandom> 不过……哦，这也许有用 16:55 <jrandom> 如果 Phex 用户使用“0 跳的 tunnels”，他们就能免费获得 NAT 穿透/防火墙到防火墙传输，并且速度相当不错 16:55 <+fox> <GregorK> 另一个是 LAN 中的查询广播之类的……便于在私有网络中更容易分享内容 16:56 <jrandom> （0 跳的 tunnels 能提供一定的合理否认性（plausible deniability），而不需要中间节点转发流量） 16:57 <jrandom> 嗯，LAN 广播是好东西，不过我不确定 I2P 是否真需要它（因为知道对端在哪里会带来匿名性风险 :)，所以也许这个功能在使用 I2P 插件时可以禁用？ 16:58 <cervantes> 默认禁用即可 16:58 <+fox> <GregorK> 嗯它现在还不可用……但在这种情况下，用户通常彼此认识来构建那个私有网络…… 16:58 <jrandom> 哦对 cervantes 16:58 <jrandom> 对对，GregorK 16:59 <+fox> <GregorK> 用户界面这边会有变化吗？？ 17:00 <+bar> 嗯，我们不需要国旗图标 :) 17:00 <jrandom> 至少能有一些与 I2P 相关的配置选项会很有用。 17:01 <jrandom> 我记得 sirup 能把界面里的一些显示改成用 I2P 的“destination”，而不是显示 IP + 端口号，所以我觉得没问题 17:01 <+redzara> 至于 bitzy 先不说，但旗帜和国家没用上 17:01 <jrandom> bitzy？ 17:01 <+redzara> 抱歉，贴错了 :( 17:02 <+fox> <GregorK> 你能提供一份所需配置项和可选特性的清单吗？ 17:03 <jrandom> 我们可以给你。一条 I2P 运行的主机+端口，再加上几个与性能/匿名性调整相关的下拉选项就够了 17:03 <jrandom> 细节我们会给你 17:02 <cervantes> [x] 超级传输速度模式 17:02 <+fox> <GregorK> 嗯 bitzi 用来识别文件……这会有匿名性问题吗？ 17:03 <vulpine> <redzara> GregorK：我正在准备，但基本上没有变化 17:03 <+fox> <GregorK> :) 去问你的服务商吧 cervantes…… 17:03 <redzara> GregorK：也许吧，我在研究 17:04 <cervantes> GregorK：呵 英国居民……没戏 ;-) 17:04 <+fox> <GregorK> 如果你在同一台 PC 上两个 Phex 实例之间传文件……传输会快得飞起 ;) 17:05 <cervantes> 酷……我可以和自己分享很多酷电影了 :) 17:05 <cervantes> * 把这句从会议记录里划掉 * 17:06 <bar> jrandom 之前提过，但还是把那个疯狂点子再说一次： 17:06 <+bar> 把 I2P 集成到 Phex 里，让普通用户默认用 0 跳的 tunnels 怎么样？ 17:07 <+fox> <GregorK> 我觉得旗帜和 IP+端口的显示来自 HostAddress 对象……而新层会把它隐藏起来……所以可以显示别的东西 17:07 <+bar> （为了合理否认性和 UDP 防火墙打洞） 17:08 <+fox> <GregorK> 不太确定我是否真的明白这是什么意思 ;) 17:08 <+bar> 可能我自己也没明白 ;) 17:09 <jrandom> GregorK：基本意思是，Phex 用户仍然彼此直接通信，但能获得合理否认性，因为他们也可能是间接通信 17:09 <+bar> jrandom，我确定你懂我的意思，你能详细说说吗？ 17:09 <jrandom> 他们还能免费得到 I2P 的 NAT 穿透，以及数据安全与防 ISP 等嗅探的保护 17:09 <+redzara> GregorK：所以你得把所有与 host+port、IsLocalIP、IsPrivateIP + … 相关的代码都删掉 17:10 <jrandom> 另一方面（非常重要的一点），它将无法和不跑在 I2P 之上的 gnutella 客户端通信 17:10 <jrandom> （不过最终，它们都会的 ;) 17:10 <+fox> <GregorK> 我觉得第一步——而且这一步已经够大了——是让 i2p 和 phex 走得更近。 17:10 <jrandom> 同意 17:10 <+bar> （糟糕，我没想到这点） 17:11 <+bar> 是的，当然 17:11 <jrandom> 这就是天马行空的想法。先把实用的事做起来 17:11 <+fox> <GregorK> 等我们看看这一步做得如何，再决定之后怎么走…… 17:11 <jrandom> 正是如此 17:12 <+fox> <GregorK> redzara：我想要两个 HostAddress 的实现，一个用于 i2p，一个像现在这样。 17:14 <+redzara> Gregork：没问题，我在我的修改里把相关代码都注释了，你很容易就能做两个实现。先让我把初始工作完成吧 17:14 <+fox> <GregorK> 行……没问题…… 17:14 <jrandom> :) 好，redzara，你觉得基于 Phex-2.4.2 的新版本能在下周找人做个 alpha 测试吗？ 17:15 <jrandom> （第二阶段的内容。你的第三阶段要花更多功夫集成到主线） 17:15 <+redzara> jrandom：next 对我来说没问题 17:16 <jrandom> 太好了 17:16 <+redzara> s/next/next week/ 17:16 <jrandom> 好的，这真让人兴奋，顺利跑起来就太棒了 17:17 <jrandom> 有人还想就 4) I2Phex 提点别的，还是我们简短转到 5) Syndie/Sucker？ 17:17 <cervantes> I2P 肯定会从这样的杀手级应用中受益 17:18 <+fox> <GregorK> 顺便说，Phex 有个 CVS 邮件列表，会发所有 Phex 的 CVS 变更……或许有用 17:18 <jnymo> *咳*……当然有用 17:18 <jrandom> 太好了，谢谢 GregorK 17:18 <jrandom> 的确，cervantes 17:19 <jrandom> 好，关于 5)，除了那里写的，我也没别的可加 17:19 <jrandom> dust：你在吗？ 17:19 <+redzara> GregorK：谢谢，不过我一个人维护一个版本就够折腾了 :) 17:19 <jrandom> 呵呵 redzara 17:19 <dust> 最近没什么空，但如果有的话，我想先把 addresses.jsp 这块理顺，在里面的协议下拉框里加上“RSS”，然后从 Updater、Sucker 到 BlogManager 把流程打通。 17:20 <dust> 除非有人有更好的主意 17:20 <jrandom> 太棒了 17:20 <jrandom> 听起来很合适。 17:21 <jrandom> 不过，嗯，可能还需要一个额外字段（“发到哪个博客”和“标签前缀是什么”）…… 17:21 <jrandom> 也许单独一个表单/表格更合适，不过也不一定 17:22 <dust> 哦，我以为 addresses.jsp 只针对一个博客（因为得登录才能进去？） 17:22 <jrandom> 啊，对，说得好 17:23 <jrandom> Updater 那部分有点模糊，不过你说得对 17:23 <dust> （到时候我们再弄明白） 17:23 <jrandom> 好的 17:24 * jnymo 觉得 www.i2p.net 可以搞个“周边小店”之类的 17:24 <jnymo> 卖写着“我就是 Jrandom（I am Jrandom）”的 Eyetoopie T 恤 ;) 17:24 * mrflibble 还在补看那场“口水战”，看起来正朝着一场真正的骂战发展 :) 17:24 <jrandom> 呵 jnymo 17:25 <jrandom> 是啊，那个线程内容很多 17:25 <jrandom> 好吧，这样我们就到了 6) ??? 17:25 <jrandom> 还有人要在会上提点别的吗？ 17:25 <+bar> 有，就关于 symmetric NAT 的一个小注（我稍微查探了下）： 17:25 <+nickless_head> jrandom：我知道真相！ 17:25 <+fox> <blx> kaffe？ 17:25 <mrflibble> 哦，抱歉 jr 17:26 <jnymo> 但说真的……只要是有点规模的开源项目都有自己的周边区 17:26 <+nickless_head> jrandom：我有确凿证据证明你黑了 last.fm 的首页！ 17:26 <+nickless_head> （注册后能得到什么的那一栏里写着“a pony”） 17:26 <jrandom> jnymo：我觉得你说得对，我们会想去探索这条路，可能也是个筹款的好办法 17:27 <jnymo> jrandom：正是 17:27 * mrflibble 会买那件 T 恤 17:27 <+bar> 好，说回 symmetric NAT， 17:27 <+bar> 就我掌握的情况看，不像我们已支持的那些 NAT，有什么魔法招数。唯一正确的做法是研究并考察每一个 symmetric NAT 的行为，并用引介者来探测。 17:28 <jrandom> blx：最新的 Kaffe CVS 完全坏掉了。加密包不在源码里，PRNG 初始化失败，而且 URL 处理器搞不定 file:// :( 17:28 <jnymo> 在 I2P 用户想用托管服务器来跑 I2P 的情况下，你们有什么宽松又便宜的主机托管商推荐吗？ 17:28 <+bar> （我相信比如 Hamachi 和 Skype 就是这样从 symmetric NAT 背后做 UDP 打洞的） 17:28 <+nickless_head> jnymo：马克杯也很棒 :) 17:28 <+bar> 根据我在网上看到的，symmetric NAT 的端口预测算法基本都很糟。 17:28 <jrandom> 嗯，bar 16:28 <mrflibble> 呵呵，我不会把我的昵称印上去。哦对了，虽然我有一件 IIP T 恤，我现在还活着/没被捕 16:28 <jrandom> 是的，我看到的也是如此 17:29 <+bar> 我会尽量再找一些好而相关的资料。 17:29 <+redzara> 小问题：0.6.1.3 中平均重传字节的百分比大概是多少？ 17:29 <jrandom> 谢谢 bar 17:29 <+fox> <jme___> bar，他们的预测结果一致吗？ 17:29 <+fox> <jme___> bar，我换个问法 :) 17:29 <+fox> <blx> jrandom，听到这个我很难过 17:30 <jrandom> redzara：我不巧忘了把那个放进 netDb。我现在倒是看到 2.6 和 3.8 了 17:30 <jrandom> blx：我也很难过 :( 17:30 <+fox> <jme___> bar，当你分析 NAT 盒子的行为并找到一个预测公式时，它对这个 NAT 盒子总是奏效吗？还是一会儿能用，一会儿不行？ 17:30 <jrandom> blx：我知道他们现在正和 classpath 做一些合并，希望合并完就好了 17:30 <+fox> <blx> 这可能意味着我不会加入这场派对了 17:30 <jrandom> blx：你是必须用 kaffe，还是只要 OSS/DFSG 就行？ 17:31 <+fox> <blx> 自由软件 17:31 <+fox> <blx> 你可以说 DFSG 17:31 <jnymo> 如果某个 I2P 用户想用托管服务器跑 I2P，应该选哪家自由、便宜的托管服务公司？ 17:31 <+bar> jme___：据说 hamachi 能调解 97% 的连接尝试。我猜还是有些 NAT 在分配端口时几乎表现得像随机的 17:32 <jrandom> 好的，我相信我们能想办法搞定，blx。Kaffe 以前是能用的，而且我们并不依赖任何 Sun 特有的东西 17:32 <jrandom> jnymo：我在用 sagonet.net，不过他们把价格从 65/月涨到 99/月（但带的是高速链路，1250GB/月） 17:32 <jrandom> 我知道德国也有一些便宜的 17:33 <+fox> <jme___> bar，97% 就很棒了 17:33 <jrandom> redzara：你这边看到的重传率是多少？ 17:33 <+bar> jme___：对，所以我猜大多数 symmetric NAT 是可预测的 17:33 <+fox> <blx> jrandom，我当然希望如此。我真的对这玩意很感兴趣 :) 17:33 <+fox> <jme___> bar，你会怎么做？中继、UDP 打洞、连接反转……还有别的技术吗？ 17:33 <jnymo> 99 算贵吗，平均来看？ 17:34 <+redzara> jrandom 在 3.8 和 4.2 之间 17:34 <jrandom> jme___：我们用的是 UDP，不需要连接反转 :) 17:35 <+bar> jme___：我不是专家，也许下周的会议我会有更多信息（但这味儿很像画像 + UDP 打洞 ;) 17:35 <jrandom> jnymo：对 1250GB 来说，不算。见过 50-100GB/月 报 60-120 美元/月的 17:35 <jrandom> bar：也许 UPnP 会更好？ 17:35 <+fox> <jme___> jrandom，即便用 UDP 也有用的 :) 17:35 <+redzara> jrandom：但只有部分节点有较大影响，可能是一些老的 17:35 <+fox> <jme___> vulpine：好 17:35 <jrandom> 不过那只能帮到能控制自己 NAT 的人 17:36 <+fox> <jme___> UPnP 必须支持，但它不是其他手段的替代 17:36 <jrandom> 嗯，我们现在做的一切都没用任何 UPnP 17:36 <+fox> <jme___> 因为并不是所有 NAT 都支持 UPnP，差得远呢 17:36 <jrandom> 对，比如运营商的 NAT 17:36 <+bar> jrandom：如果 UPnP 没有安全问题的话，我觉得加上也无妨。不过 hamachi 不用 UPnP 16:36 <+fox> <jme___> 这里“必须”的意思是：为了提供最大的连通性 17:37 <+fox> <jme___> 好，我回去写我的 C++ 了 :) 17:38 <jrandom> 对，jme___，不过如果我们既能做 symmetric 的打洞，也能做 cone/restricted 的打洞，那就很棒了 17:38 <jrandom> 回见 jme___ 17:38 <jrandom> 是啊，理想情况下我们不需要它 17:39 <jrandom> 好，还有人要在会上提点别的吗？ 17:41 <jrandom> 如果没有…… 17:41 * jrandom 做结束准备 17:41 * jrandom *baf* 地宣布会议结束