I2P 开发者会议 - 2006年9月12日

16:06 <jrandom> 0) 嗨 16:06 <jrandom> 1) 0.6.1.25 和网络状态 16:06 <jrandom> 2) I2PSnark 16:06 <jrandom> 3) Syndie（是什么/为什么/何时） 16:06 <jrandom> 4) Syndie 的加密问题 16:06 <jrandom> 5) ??? 16:06 <jrandom> 0) 嗨 16:06 * jrandom 挥手 16:06 <jrandom> 每周状态说明已发布于 http://dev.i2p.net/pipermail/i2p/2006-September/001307.html 16:07 <jrandom> 既然那些说明在好几个小时前就发出来了，你们应该都读过并做好了笔记，对吧？ ;) 16:07 <jrandom> 跳到 1) 0.6.1.25 和网络状态 16:08 <vulpine> <Complication> 就 0.6.1.25 而言，在我这儿看起来运行良好，只出现了一个之前没见过的错误 16:08 <jrandom> 不错，什么问题？ 16:08 <vulpine> * Complication 正在搜索日志 16:09 <jrandom> 网络规模似乎比以前更大了，不过仍在同一数量级 16:09 <vulpine> <Complication> "Unknown error reading the net.i2p.data.i2np.GarlicMessage: wtf, fromLong got a negative? -840" 16:10 <vulpine> <Complication> Started with "ERROR [NTCP read 1 ] .router.tunnel.FragmentHandler: Error receiving fragmented message (corrupt?)" 16:10 <jrandom> 啊好，那个问题存在很久了，可以放心忽略 16:11 <vulpine> <Complication> 只出现了一次 16:11 <vulpine> <frosk> 我遇到过好几次刚才那个 16:11 <vulpine> * jrandom 戳了下 fox 16:12 <vulpine> <Complication> 哦，还有一个: "router.tunnel.TunnelDispatcher: wtf, took 1121 to dispatch net.i2p.data.i2np.TunnelBuildMessage@XXXX out YYYYY in net.i2p.router.tunnel.PumpedTunnelGateway@ZZZZ" 16:12 <vulpine> <Complication> （看起来也不重要，可能只是简单拥塞） 16:12 <jrandom> 嗯，大概是 16:13 <jrandom> 现在 irc 显然还有点糙 16:13 <jrandom> （不过这一次可不是 i2p 的错 :)） 16:14 <jrandom> 好，关于 1) 网络状态和 0.6.1.25 还有别的吗？ 16:15 <kostya213> 补充一下，.25 修复了我过去几个月遇到的所有问题 16:15 <jrandom> 太棒了！ 16:16 <vulpine> <green> 请在只使用 NTCP 时修改状态计算 16:16 <jrandom> 行，不过不建议禁用 udp（我记得我还明确说过我不会告诉大家如何禁用 udp） 16:17 <jrandom> 但状态应该更新，考虑到 udp 不是唯一的传输方式 16:17 <jrandom> 我会在下个版本修好，多谢 16:17 <vulpine> <green> jrandom：当然你不说，但我会读代码 ;) 16:18 <jrandom> 没错，不过当我不推荐某件事、还叫大家别试的时候，若显示信息让人困惑也别惊讶 ;) 16:19 <vulpine> <green> 当然，我也可以只是在控制台显示 "OK" :) 16:19 <jrandom> 确实 16:21 <jrandom> 好，我们跳到 2) I2PSnark 16:21 <jrandom> zzz 现在似乎不在 16:22 <jrandom> zzz 正在做一些改动，以改进 i2psnark 的调度 16:23 <jrandom> （如果我没记错，目前它有点…过于简单，不过我不完全确定 zzz 在改哪些） 16:23 <jrandom> （（不过我很期待进展！）） 16:25 <jrandom> 好，如果 2) I2PSnark 没别的了，我们继续到 3.*) Syndie 相关 16:26 <jrandom> 先从 3.1) 什么是 syndie 开始，因为要讲的很多 16:27 <jrandom> 会前我收到几个关于帖子加密的问题 16:27 <jrandom> 基本上，帖子是“对称”加密的——拥有对称密钥的人就能读帖，因为他们被授权 16:28 <jrandom> 频道回复使用非对称加密，针对频道/论坛关联的公钥加密 16:28 <jrandom> 有些帖子可以使用基于口令的加密来生成用于阅读的对称密钥 16:29 <jrandom> 还有些帖子可以在帖子可读的头部中包含该对称密钥（这样任何人都能读） 16:29 <modulus> 最后一种有什么意义？ 16:29 <jrandom> 还有些论坛本身可以在论坛元数据中包含对称密钥，这样任何人都能读帖子，但前提是他们有该频道的元数据 16:29 <jrandom> modulus：这样所有东西始终都是加密的，即使是公开可读的内容 16:29 <jrandom> （这样简单的窃听就没用） 16:30 <modulus> 好，我明白了。 16:31 <jrandom> 好，我想这就覆盖了会前提到的加密问题 16:31 <jrandom> 关于 3.1) 什么是 syndie，还有问题吗？ 16:31 <jrandom> （当然，随着发布，会有更多细节明确） 16:32 <vulpine> <void> 嗯 16:33 <jrandom> void，怎么样？ 16:33 <vulpine> <void> <void> 我想消息 (.zip) 归档也可以包含其他消息，可能来自别人，比如被引用的消息？ 16:34 <jrandom> 嗯，是的，你可以把 .snd 文件作为附件包含进来，但有明确的命名空间，所以你可以用标准的 References: 风格链接到之前的消息 16:34 <jrandom> （也就是说你不必用 frost 风格的“串帖”） 16:35 <vulpine> <void> 好，明白 16:37 <vulpine> <Complication> 关于 Syndie，我在想大家如何解决这样的问题：给某个多人发帖的论坛授予发帖权限（类似普通论坛的账号），但不要不可撤销；当需要撤销权限（不管什么原因）时，如何避免不必要的混乱 16:38 <vulpine> <Complication> 当然一种方案是由作者指定建议，让客户端显示哪些人的回复 16:38 <jrandom> Complication：创建一个新的公钥/私钥对，把私钥给（临时）被授权的人，并把公钥加入“允许发帖的密钥”列表 16:38 <vulpine> <Complication> ……而客户端如果不打算追溯历史，就遵循这个建议（或者更准确地说，遵循它的最新版本） 16:38 <jrandom> （当他们不再被授权时，就从“允许发帖的密钥”列表中移除该密钥） 16:39 <kostya213> jrandom：你可能想用一个不同于 .snd 的扩展名，因为它广泛用于音频应用，MIME 会混淆 16:39 <jrandom> 啊，对——所有论坛都有一个“所有者”（一个用于签名的私钥），可以管理谁被允许发帖的列表等 16:39 <vulpine> <Complication> “允许发帖的密钥”会作为元数据附在作者的最新帖子或其他某条消息上，对吗？ 16:39 <jrandom> 说得好，kostya213，不过那我们可能就只能用 .dat 了 ;) 16:40 <jrandom> Complication：啊抱歉，不是那样，它像当前/旧的 syndie——为论坛/频道本身单独发布带签名的元数据帖子 16:40 <vulpine> * Complication 觉得好像已经有人把 .dat 用在别的什么上了 :) 16:40 <jrandom> 对，那个叫作 "octet-stream" 的应用 ;) 16:40 <vulpine> <void> 看起来 .syn 没被用在什么重要的地方 16:41 <vulpine> <Complication> 啊哈，特殊的元数据帖子……对，这可行 16:41 <jrandom> 哦，妙，我们能用 syn！ 16:41 <jrandom> （眼尖的 void，谢谢 kostya213） 16:41 <vulpine> <void> 嗯，" 16:41 <vulpine> <void> 嗯，"Word Synonym File", Company: Microsoft 16:42 <jrandom> 好吧，我相信我们会想出办法的 16:42 <kostya213> 是的，它被 Word 使用 16:42 <vulpine> <void> 但我们也可以无视它 :) 16:42 <kostya213> 别灰心，我觉得能找到不会与广泛使用的 MIME 类型冲突的扩展名 16:43 <jrandom> 好，关于 3.1) 什么是 syndie，还有别的吗？ 16:43 <vulpine> <void> 呃，不过为什么我们要拘泥于三字母扩展名？那是 DOS 时代的遗留物 16:43 <kostya213> 有个必须问的问题：为何要限制三字母扩展名？没人再用 DOS 了 16:44 <jrandom> 嘿 16:44 <kostya213> 和 void 说一块儿了 16:44 <kostya213> 我觉得 .syndie 不错 16:44 <vulpine> <void> .synd 似乎也不会与任何东西冲突 16:44 <kostya213> 也不错 16:45 <vulpine> <void> 该死的延迟 :( 16:48 <jrandom> 好，我们跳到 3.2) 为什么 Syndie 重要？ 16:48 <vulpine> <void> jrandom：等下 16:48 <cervantes> （因为你说它重要） 16:48 * jrandom 等着 16:48 <jrandom> !thwap cervantes ;) 16:48 <vulpine> <void> 状态说明里提到，帖子可以附带一个头像，否则将使用默认头像 16:49 <vulpine> <void> 但如果有人想预设多个头像，而不是只有一个“默认”头像呢？ 16:49 <jrandom> 嗯，作者可以在自己频道的元数据里包含一个默认头像 16:49 <vulpine> <void> 每次都附上另一个头像效率不高 16:49 <jrandom> 问得好，void——我们来看下说明里的那段脚本代码 16:50 <jrandom> listauthkeys --authorizedOnly true 16:50 <jrandom> authenticate 0 16:50 <vulpine> <void> (?) 16:50 <jrandom> listauthkeys 会显示所有你可以签名为你自己的身份，而 "authenticate 0" 是选择一个用来签名的身份 16:51 <jrandom> 因此，该身份有自己的频道，而该频道有自己的元数据，其中可以包含一个头像 16:51 <vulpine> <void> 嗯，单独的身份意味着单独的密钥对吗？ 16:51 <jrandom> 是的 16:51 <vulpine> <void> 那如果一个人在同一身份下想有多个头像呢？ 16:52 <jrandom> 他们在频道元数据里有一个默认头像，也可以按每条消息进行覆盖 16:52 <kostya213> 价值存疑 16:52 <vulpine> <void> 有几个可供选择的“默认”头像 16:52 <vulpine> <void> 还是我在钻牛角尖？ :) 16:53 <jrandom> 啊，我明白你的意思了。 暂时不支持 16:53 <jrandom> 也许以后吧 16:53 <vulpine> <void> 说得对，kostya213，那就算了 16:53 <vulpine> <void> :) 16:53 <jrandom> （不过头像尺寸会非常小，包含进去应该问题不大） 16:53 <vulpine> * Complication 认为增加每条消息的头像应该很容易实现 16:53 <vulpine> <void> 那么，3.1) 什么是 syndie？ 16:53 <vulpine> <Complication> （最终会的） 16:54 <vulpine> * cervantes 把 irc 服务器粘在一起 16:54 <vulpine> <void> Complication：jrandom 刚说他已经要这么做了 :) 16:54 <jrandom> （每条消息的头像会作为基础功能，Complication；而关于“提供多个‘默认’可选，通过在消息里写“use avatar 1”来选择，而不是包含头像本身”的这个想法） 16:54 <vulpine> <Complication> 延迟，延迟…… 16:54 <jrandom> 好，关于 3.1 还有别的吗？ 16:54 <jrandom> 没有的话，我们跳到 3.2 16:55 <vulpine> <void> 我想就这些 16:55 <jrandom> wr0d. 16:56 <jrandom> 除了 cervantes 的冷嘲热讽外，关于“为什么”还有谁有问题/评论/担忧？ 16:56 <jrandom> （呃，是“concerns”） 16:58 <vulpine> <Complication> cervantes：在给 ircd 上胶之前，你有没有先用酒精清洁表面？ ;) 16:58 <kostya213> 我认为 syndie 不需要特别论证，对任何已经对匿名网络感兴趣的人来说，它的价值是不言自明的 16:58 <kostya213> 而且也明白信息集中化的危险 16:59 <vulpine> <Complication> （重发，如果已经到服务器请忽略） 16:59 <vulpine> * Complication 认为 Syndie 之所以重要，是因为“普通用户”运行 phpBB 很快就会被攻破，“普通用户”运行 $random_blogging_tool 也一样 16:59 <vulpine> <Complication> （即使概率可能不同） 16:59 <vulpine> <void> 确实 16:59 <jrandom> 嗯，另外，任何面对真实敌对对手的人（甚至不一定是国家级别） 17:00 <jrandom> 好，行，我只是想和大家过一遍 17:00 <jrandom> 关于 3.2 还有别的吗，或者我们转到 3.3) 什么时候可以用 syndie？ 17:01 <vulpine> <void> 嗯，本质上它是一个基于密码学原语、与传输层无关的论坛/博客/电子邮件/通信工具 17:01 <vulpine> <Complication> ……并且在极端情况下，如果“普通用户”的对手进行交集攻击，任何运行任何形式 eepsite 的人最终都会被攻破（除非网络非常庞大） 17:01 <kostya213> 对那些看不到隐私/匿名即时价值的人来说，可能更难推广 17:01 <jrandom> kostya213：嗯，不过我们也许可以整点活，比如能够安全离线浏览 17:02 <vulpine> <Complication> 不管怎样他们可能都会欣赏安全性 17:02 <jrandom> （例如一个离线 RSS 阅读器，不仅拉取 RSS 摘要，还拉取引用的完整页面集） 17:02 <vulpine> <void> 所以是的，我不明白为什么需要论证 :) 17:02 <vulpine> <void> kostya213：使用 syndie 不一定要匿名 17:02 <cervantes> 我们什么时候能用 syndie，或者说 syndie 什么时候可用？ 17:02 <jrandom> 说得对，void :) 17:03 <cervantes> 对于文本界面，我想需要相当多的使用文档 17:03 <jrandom> cervantes：目前 syndie 是可用的（你可以创建帖子、管理频道、读帖子、回帖等） 17:03 <kostya213> jrandom：syndie 如何处理冗余？内容消失的抗性如何？ 17:03 <cervantes> （在它被认为“可用”之前） 17:03 <jrandom> cervantes：有内联菜单，每个命令都有文档（至少是最基本的） 17:04 <cervantes> 好，有计划提供一些用例示例吗？ 17:04 <jrandom> kostya213：syndie 在内容层工作——冗余由别的东西处理。 如果你发布到 usenet，它会在 usenet 上复制传播（比如说） 17:04 <cervantes> 我觉得关键在于学会如何把它们脚本化地组合在一起 17:04 <vulpine> <void> 那超出了 syndie 的范围，它依赖于传输机制 17:04 <vulpine> <void> 不幸的是 17:04 <jrandom> 好主意，cervantes 17:05 <jrandom> Syndie 的第一个版本会包含一个类似旧/现有 syndie 的 HTTP 复制系统 17:05 <jrandom> cervantes：也许一些测试用户可以整理他们喜欢的脚本，供我们分发 :) 17:05 <modulus> 嗯，这是个控制台应用吗？ 17:05 <jrandom> modulus：是的，首个基于文本的应用 17:06 <modulus> 太棒了！ 17:06 <cervantes> jrandom：前提是测试用户能摸清怎么用 ;-) 17:06 <jrandom> 呵呵 17:06 * jrandom 考虑过 curses 等，以及纯 CLI，但一个可交互、可脚本化的文本界面可能最简单也最有用 17:07 <jrandom> （也就是没有 GUI） 17:07 <cervantes> modulus：看吧，jrandom 采纳了你没完没了的反馈 :) 17:07 <vulpine> <Complication> 如果大家愿意，应该可以在它之上构建更交互的文本界面 17:07 <jrandom> 嗯，当然 17:08 <jrandom> （代码是为易于与 irc 客户端集成而构建的，比如 pircbot） 17:08 <modulus> cervantes：呵呵 17:09 <modulus> 我想也可以在它之上加一个 GUI，如果它大体按我想的那样工作的话 17:09 <modulus> 不过那会多很多工作。 17:09 * kostya213 等待 emacs 插件 17:09 <modulus> 哈哈哈 17:09 <jrandom> 呵 17:09 <modulus> 其实做个 emacs 模式也不是坏主意，也许会吸引更多“奇葩”来用。 17:10 <cervantes> 按 ctrl-alt-shift-break-上箭头-num7-b 来选择你的身份 17:10 * jrandom 会把这事留给 elispers 去折腾 ;) 17:10 <kostya213> 无意冒犯，但我不确定这个项目需要吸引更多奇葩 17:10 <vulpine> <Complication> 那种奇葩也会写代码吗？ 17:11 <jrandom> 希望如此，complication 17:11 <jrandom> 好，希望 3.3) 能解释一下接下来会有哪些东西 17:11 <jrandom> 至于“什么时候”，嗯，走着瞧，但我希望“很快” ;) 17:12 <jrandom> 好，关于 3.3) 还有别的吗？ 17:12 <vulpine> * Complication 那我就欢迎一大波那样的奇葩 :D 17:12 <cervantes> 嗯，写代码是一回事，写用 Perl 解释的难懂 Tcl 又是另一回事 17:12 <kostya213> 做个 FUSE 插件可能也有用 17:13 <jrandom> 嗯 17:13 <jrandom> 好，我们跳到 4) syndie 的加密 17:13 <jrandom> 对这些问题有人有评论吗？ 17:14 <vulpine> <Complication> 真希望有，但我不具备评估这些密码/哈希/密钥长度强度的能力 17:15 <vulpine> <void> ElGamal/RSA 签名有多长？2kbit 的密钥要 4kbit 的签名吗？ 17:15 <vulpine> * Complication 把这话题完全留给别人 17:15 <jrandom> 一时想不起来 17:15 <vulpine> <void> 对比 DSA 呢？ 17:16 <jrandom> （不过 ECC 看起来又小又好） 17:16 <modulus> ElGamal 签名又难又长。正如 gnupg 团队发现的那样。 17:16 <jrandom> 嗯，不过有些技巧与密钥复用有关 17:16 <vulpine> <void> 啊，好的 17:16 <vulpine> <void> 是的 17:16 <tethra> modulus：如果它们又难又长，是有特定癖好网站的 17:17 <jrandom> 好，那一点主要是提前告知一下，也欢迎大家想到时随时评论 17:17 <cervantes> 能不能实现某种可插拔的密码套件——当更好的建钥方法标准化后，我们把它加到 syndie 里，新帖子开始使用它们，但旧帖子仍能用过时的方法 17:17 <tethra> （抱歉） 17:17 <jrandom> cervantes：它包含一个 DSA: 前缀，所以用 Elg: 前缀也可以 17:17 <modulus> 你们用的是限制为 1024 的 DSA 吗？ 17:18 <modulus> 另外哈希用什么？SHA1 还是更高版本？ 17:18 <cervantes> 所以你现在主要关注的是让 syndie 有个好的开始 17:18 <jrandom> DSA 只有 1024bit（有更长的 DSA2 提案，但还未标准化） 17:18 <jrandom> 是的，DSA 需要 SHA1 17:18 <modulus> 嗯，我的理解是，在标准化之前它们相当强。 17:18 <kostya213> cervantes 说得有道理，让 syndie 内容固定使用某套密码，对前向保密性不利，你永远不知道某个算法什么时候会挂掉 17:18 <modulus> 不过我没有足够密切地跟进流程，所以你可能是对的 17:19 <jrandom> kostya213：但“可选项”对匿名/密码学不利，所以能固定时就应该固定 17:19 <jrandom> （因为匿名性会受影响） 17:19 <vulpine> <void> 你知道为什么没有更多人/协议使用 ECC 吗？是担心研究不够，还是只担心兼容性？ 17:19 <modulus> 专利。 17:20 <jrandom> 专利和 FUD，还有一些实现方面的担忧 17:20 <vulpine> <void> 啊，对，modulus 17:20 <modulus> 顺便问一下，比如选择 DSA 而不是 RSA-SHA512 有什么充分理由吗？ 17:20 <tethra> 专利、FUD 和国家（天哪） 17:20 <modulus> 不是想找茬，只是考虑到比如 gpg 就走了这条路，等等。 17:20 <jrandom> 好多年没评估过那个选项了，modulus 17:21 <modulus> 显然 DSA 是标准，这是它的优点，但密钥较小，哈希也较弱。倒不是说我认为它很可能成为最弱的一环 ;-) 17:23 <cervantes> 我不会提出“选择”——而是让新版 syndie 打包越来越安全的（强制）密码套件 17:23 <vulpine> <Complication> 在结构上留下空间以便未来更改，不管当前哪种密码学最好，这看起来都合理 17:23 <jrandom> 嗯，不过这意味着需要回退到更弱/更旧的版本来互操作 17:23 <jrandom> 不过，好吧，我们会想办法处理 17:24 <jrandom> 好，我们跳到 5) ??? 17:24 <jrandom> 还有别的要在会上提的吗？ 17:25 <cervantes> 不能从你最喜欢的来源读取最新帖子，这本身就是促使大家保持升级的好动力 17:25 <jrandom> 在一定程度上是 17:26 <cervantes> no=not 17:26 <jrandom> （嗯，这是个动力，但人们很懒/对“升级软件”没兴趣，等等） 17:27 <jrandom> s/people/some people/ 17:27 <cervantes> 不过我想那是他们自己的问题 17:27 <jrandom> 确实如此 17:27 <kostya213> 至少 i2p 的实现可以无痛升级 17:28 <jrandom> 当然 17:28 <cervantes> 关于 ???——为 irc 连接问题道歉——ISP 应该会“尽快”恢复其一家主要网络运营商的服务 17:29 <jrandom> w3wt 17:29 <vulpine> <Complication> 关于 ??? 这个话题，我或许可以补充，NTP 修改的第二部分（更大规模的那部分）快要能用了，我希望很快就能提交进行测试 17:29 * cervantes 捏点盐 17:29 <kostya213> router 近期待开发计划是什么？路线图准确吗？ 17:29 <jrandom> 太棒了，complication 17:29 <vulpine> <Complication> 它的目标是基于对端时钟偏移来对 NTP 服务器进行二次判断 17:29 <jrandom> kostya213：在 syndie 发布之前以稳定为主 17:30 <jrandom> （就我而言） 17:30 <vulpine> <Complication> （并避免采取可能损害连接性的操作） 17:31 <cervantes> 好极了 17:32 <jrandom> 好，会议还有别的吗？ 17:34 * jrandom 做收尾 17:34 * jrandom 将会议 *baf* 地结束了