关于av协议和MicroCai的讨论


#1

[下午 1:55:13] MicroCai: there ? [下午 2:39:41] Jack: 在了 [下午 2:40:45] MicroCai: avim 啊 [下午 2:40:51] MicroCai: 居然又开始了 [下午 2:40:56] Jack: 又开始了啊? [下午 2:40:58] MicroCai: 是啊 [下午 2:41:00] Jack: 我看了部分讨论 [下午 2:41:07] Jack: 怎么想到又开始了? [下午 2:41:38] MicroCai: 呵呵 [下午 2:41:39] MicroCai: 不知道 [下午 2:41:59] MicroCai: 那个我问下, RSA 密钥长度最短可以到多少 [下午 2:42:00] MicroCai: ? [下午 2:43:35] Jack: 2的N次方 [下午 2:43:43] Jack: 最小一般好像是1024 [下午 2:45:32] MicroCai: 512 也可以的吧。 [下午 2:45:46] Jack: 好像也可以 [下午 2:45:56] Jack: 默认是2048好像 [下午 2:46:30] MicroCai: 为了方便验证,所有的av数据包都会带上 发送方的公钥。而为了节约网络通信, 需要使用的是仅仅 512bit 长度的密钥。 为了防止过短的密钥被污染,这个密钥仅仅使用有限的一段时间。因此,每个 aver 都会使用一个 4-096bit 长的密钥,然后每个月生成一个 512bit 的新密钥,并利用自己的证书对这个密钥进行签名。 [下午 2:46:49] MicroCai: 你觉得这样的设计 ok 吧。 [下午 2:47:16] MicroCai: 4096bit 高强度密钥仅仅用来给低强度的密钥签名使用。 [下午 2:47:34] MicroCai: 低强度的密钥每月生成,甚至可以每天生成一份新的 [下午 2:48:57] Jack: 还没太看明白 [下午 2:49:04] MicroCai: https://www.avboost.com/t/av/584 [下午 2:49:07] MicroCai: 这个 [下午 2:49:17] MicroCai: 我总结在这帖子里了 [下午 2:51:27] Jack: 看了第一段,感觉有问题 [下午 2:51:39] MicroCai: 啥问题 [下午 2:51:44] Jack: 没法发给不在线的用户 [下午 2:51:47] Jack: 这是不科学的 [下午 2:51:59] MicroCai: 哦,这个是 av协议 [下午 2:52:06] MicroCai: 在这个上面还有个 im 协议 [下午 2:52:15] MicroCai: 发给不在线用户,这个是 im 协议要解决的事情 [下午 2:52:26] MicroCai: im 协议还没设计呢 [下午 2:52:44] MicroCai: im 协议会需要离线消息服务器之类的设备 [下午 2:52:55] MicroCai: 明白? [下午 2:53:13] Jack: 明白了 [下午 2:53:23] Jack: 我想下 [下午 2:53:49] Jack: 给不在线的用户发消息这一点必须有的 [下午 2:53:53] MicroCai: 这个协议开销很大的,所以只能传文字。如果是语音和视频的话,会通过 av网交换双方 ip地址,然后直接 p2p 建立连接,直接传输视频数据 [下午 2:54:15] MicroCai: 我管这个叫 avtunel . [下午 2:54:49] MicroCai: avtunel 绕过了 av协议和 av路由器,直接建立了链接。 [下午 2:55:06] MicroCai: 主要用于视频数据,大数据量的传输 [下午 2:55:20] MicroCai: 所以 av协议开销大点我觉得没关系的 [下午 2:55:29] MicroCai: 安全性是第一位的 [下午 3:02:13] Jack: 让我好好理解一下你说的av协议 [下午 3:02:41] Jack: 也就是说,每个用户都有一份公私钥 [下午 3:02:45] MicroCai: 用 ip 协议来理解 av 协议就很轻松了 [下午 3:02:54] MicroCai: 只是 ip 地址是可以伪造的 [下午 3:03:00] MicroCai: av地址是无法伪造的 [下午 3:03:04] Jack: 我是说实现 [下午 3:03:12] MicroCai: 恩 [下午 3:03:19] Jack: 实现上是怎么操作的 [下午 3:03:31] MicroCai: 实现上每个用户都有份 公私钥 [下午 3:03:37] Jack: 存哪呢? [下午 3:03:45] MicroCai: 公钥会制作成一个证书,由 avplayer.org 签发。 [下午 3:03:52] Jack: 这2个钥分别存在哪 [下午 3:03:59] MicroCai: 都存用户自己电脑上啊 [下午 3:04:32] MicroCai: https 一样的啊,公钥和私钥不都存服务器上啊 [下午 3:04:45] Jack: 那你发消息的时候,需要加密吧?是用私钥加密?然后把公钥也一起发过去? [下午 3:04:51] MicroCai: 对 [下午 3:05:03] MicroCai: 用私钥加密,把公钥发过去 [下午 3:05:13] Jack: 那么,首先这个公钥没必要存自己电脑上 [下午 3:05:21] MicroCai: 证书用来防止伪造的公钥 [下午 3:05:39] Jack: 因为它本身需要公开的 [下午 3:05:48] MicroCai: 公钥和私钥啊,是存储在一起的啊! [下午 3:05:49] MicroCai: jack [下午 3:05:59] MicroCai: 本来就是直接存储在一起的 [下午 3:06:08] Jack: 。。。 [下午 3:06:11] Jack: 你理解有问题吧? [下午 3:06:56] MicroCai: 不是,公钥必须要每次都附带。 我考虑过了,如果公钥不附带,接收方就要到一个集中的服务器上去查找 av地址对应的公钥 [下午 3:06:56] Jack: 公私钥确实可以存在一个文件,但是一般是需要分开存储的 [下午 3:07:19] MicroCai: 这样就不容易做分布式了 [下午 3:07:58] Jack: 而公私钥保存在自己电脑上,要考虑一个实际操作的问题,就是更新系统丢失的问题 [下午 3:08:18] MicroCai: 哦,这个问题啊,不是协议要考虑的。这个是客户端实现的时候要考虑的 [下午 3:08:26] MicroCai: 可以考虑存到 U 盾里 [下午 3:08:29] Jack: 。。。 [下午 3:08:32] Jack: 这不现实 [下午 3:08:42] MicroCai: 也可以存到服务器上啊 [下午 3:08:51] MicroCai: 用户记者密码就能下载了解锁 [下午 3:09:01] MicroCai: 这个不是协议要考虑的事情吧 [下午 3:09:16] Jack: 必须引入服务器啊 [下午 3:09:25] Jack: 否则完全没法实际操作 [下午 3:09:36] MicroCai: 目前先设计好协议。 [下午 3:10:00] MicroCai: 至于客户端怎么实现这个协议,证书存哪里,这些问题都可以慢慢解决的 [下午 3:10:03] Jack: 协议要考虑实际情况啊,不然就能是想象了 [下午 3:10:22] MicroCai: 因为这个对协议没有任何影响啊! [下午 3:10:31] Jack: 有影响 [下午 3:10:34] Jack: 影响很大 [下午 3:10:35] MicroCai: 你证书存哪里的问题,协议完全不关心啊 [下午 3:10:42] MicroCai: 你说 [下午 3:10:44] Jack: 我给你这样说吧 [下午 3:10:50] Jack: 先作一个假设 [下午 3:11:34] Jack: 用户都是傻瓜,他们不会备份公私钥,IM服务运营者必须帮他们搞定这些事 [下午 3:11:54] Jack: 事实上,我也不会备份,就比如taobao的证书,我每次都是下载新的 [下午 3:11:59] Jack: 或者生成新的 [下午 3:12:01] MicroCai: 哦,你说这个啊,这个是 im 协议层要解决的! [下午 3:12:10] Jack: 等等 [下午 3:12:11] MicroCai: 这个不会在 av层解决 [下午 3:12:12] Jack: 你听说我 [下午 3:12:42] Jack: 我要说的就是,你这个协议转了一大圈,结果又回到了原点 [下午 3:13:02] MicroCai: 啥原点? [下午 3:13:20] Jack: 原点就是,还是服务器在帮用户保管信息 [下午 3:13:30] MicroCai: 没有 [下午 3:13:34] Jack: 如果一开始直接这样设计,也是一样的 [下午 3:14:07] Jack: 那么可以节省那些步骤 [下午 3:14:25] Jack: 因为最终会变成摆设 [下午 3:14:33] MicroCai: 客户端除了信任 root CA , 你自己也可以校验证书,直接信任就可以了。 完全可以绕过 CA [下午 3:14:51] Jack: 你还没明白我说的 [下午 3:15:37] Jack: 首先,如果按照你所设想的去做,消息传递将会非常复杂 [下午 3:16:15] Jack: 其次,最终运营的时候,其重要信息,主要还是由服务器保管。 [下午 3:16:24] Jack: 因为用户是sb [下午 3:16:57] Jack: 当然,如果你不假设用户是sb,那是可行的,但我们必须这样假设,你说是吧 [下午 3:17:07] MicroCai: 。。。 。。。 [下午 3:17:38] Jack: 如果一旦你这样假设,那么,你的上层设计,就必须由服务器托管我说的这些 [下午 3:17:39] MicroCai: jack 傻逼用户不考虑安全性! 不考虑安全性那就把你的私钥交给服务器吧,彻底解决丢失问题 [下午 3:17:53] MicroCai: 我们要做的就是给不傻逼的用户一个安全的 im [下午 3:17:58] Jack: 。。。 [下午 3:18:01] Jack: 那肯定不行 [下午 3:18:06] MicroCai: 同时也不排斥 傻逼用户,只是傻逼用户得不到好处 [下午 3:18:09] Jack: 不是傻逼的用户用电子邮件就行了 [下午 3:18:46] Jack: 不是傻b用户用签名或加密的邮件,一点问题也没有 [下午 3:18:49] Jack: 你说是吧 [下午 3:20:32] Jack: so,我认为这个设计过于复杂却最终并没有解决太多问题 [下午 3:20:46] MicroCai: 本来就不指望解决太多问题 [下午 3:20:54] Jack: so,这么复杂的代价是不值得的 [下午 3:21:02] MicroCai: 没关系。 [下午 3:21:15] Jack: 我的意思是,宁愿在邮件协议的基础上,更加简化 [下午 3:21:22] Jack: 更加加强加密 [下午 3:21:26] Jack: 这样就行了 [下午 3:21:35] Jack: 我认为可能会更好 [下午 3:21:46] Jack: 另外,也更容易实际操作 [下午 3:21:49] Jack: 以及实现 [下午 3:21:59] MicroCai: 邮件依赖 DNS [下午 3:22:12] Jack: 都得依赖DNS吧 [下午 3:22:15] MicroCai: 需要自己买域名,买服务器,配置 dns ,配置软件 [下午 3:22:28] Jack: 运营im就得需要这些 [下午 3:23:00] MicroCai: 反正你要的任何功能邮件都能实现 [下午 3:23:21] MicroCai: 我根你在 skype 上聊,其实邮件就可以了 [下午 3:23:26] MicroCai: 为啥不用邮件呢? [下午 3:23:43] MicroCai: 所以 skype 是没有意义的,应该在邮件协议的基础上搞 [下午 3:23:48] Jack: 邮件确实可以实现,但是目前邮件客户端做的并不好用 [下午 3:23:58] Jack: 你认为邮件不可能? [下午 3:24:39] Jack: 关键是,你提出的复杂做法,并没有真正带来便利性 [下午 3:24:45] MicroCai: 并不复杂 [下午 3:24:52] Jack: 而且几乎完全实现不了 [下午 3:24:58] MicroCai: 哈哈,恰恰相反 [下午 3:25:02] MicroCai: 很快就能实现了 [下午 3:25:52] Jack: 我认为更合理的做法就应该这依赖在邮件协议这种模式来做分布式 [下午 3:25:57] Jack: 并且提高安全性 [下午 3:26:18] Jack: 这是最直接,最容易的方案 [下午 3:26:28] MicroCai: 代码量差不多 [下午 3:26:38] MicroCai: 真的 [下午 3:26:56] Jack: 不会,你那个路由连看懂的都没几个,怎么去实现? [下午 3:27:03] Jack: 你不会想一个人都实现了吧? [下午 3:27:34] MicroCai: 目前的实现模式就是中心式的。 一个域下一个路由。 [下午 3:27:42] MicroCai: 和邮件不是差不多么? [下午 3:28:13] Jack: 但是概念复杂化了 [下午 3:28:15] Jack: 复杂多了 [下午 3:28:29] MicroCai: 概念复杂那是的,但是实际实现并不复杂 [下午 3:28:52] Jack: 这一点上,复杂的概念并没有带来好处 [下午 3:28:58] MicroCai: 要知道 ip 协议其实几千行代码就实现了。但是需要用3卷书来描述 [下午 3:29:16] Jack: ip协议? [下午 3:29:19] MicroCai: yeah [下午 3:29:26] Jack: ip协议的东西没法在win上跑 [下午 3:29:35] MicroCai: win 不支持 ip 协议? [下午 3:29:45] Jack: 直接发ip包? [下午 3:29:49] MicroCai: 不是啊。 。。 [下午 3:30:06] MicroCai: 内核里 和 ip 相关的实现代码就几千行 [下午 3:30:19] Jack: 这没用啊,要能工作起来才行啊 [下午 3:30:20] MicroCai: tcp 比 ip 多一些 [下午 3:30:23] MicroCai: 也不太多 [下午 3:30:27] Jack: 不止是linux [下午 3:30:33] Jack: linux是小众用户 [下午 3:30:35] MicroCai: 但是 ip tcp 协议3卷书都说不完 [下午 3:31:00] MicroCai: 我的意思是概念复杂不等于实现上复杂 [下午 3:31:14] Jack: 我的意思你的实际操作会非常复杂 [下午 3:31:19] Jack: 几乎实现不了 [下午 3:31:27] MicroCai: 这个不用担心 [下午 3:31:40] Jack: 必须得基于tcp、udp来做 [下午 3:31:44] Jack: 而不是ip [下午 3:32:26] MicroCai: 没说基于 ip 来做啊! [下午 3:32:39] MicroCai: 我只是拿 ip 协议来类比 av协议啊! 让读者好理解。。。。。 [下午 3:32:46] Jack: 这就更不好理解了


#2

avim 分成 2 层, 一个 av 一个 im . im 层专注 消息格式和 GUI 的实现。不需呀操心登录啦,数据包的传输啊这些细节问题。 这些问题由 av层解决。 av 层呢,则向 im 层提供最简单的 2个接口: av_sendto 和 av_recvfrom im 层提供的是未加密的数据, av层将数据加密后,通过 tcp 或者其他神码协议之类的,把数据传输到目的地。然后目的地的 av层再对数据解密,再提给给它的 im 层。 这样 im 层就可以不用操心数据的完整性啊,加密性之类的问题 安心做好一个 IM , 让用户爽快的聊天 因此, api 主要就 2 个 , av_sendto 和 av_recvfrom 当然,还有一些辅助手段的 api , 比如控制 av协议的初始化和关闭之类的。 当然这些 api 都比较简单, main 前面几行调用一下,初始化一下就可以了 。 这类 api 等以后实现的时候再因地制宜的添加一下。


#3

那么为了大家能更好的理解 av协议,我这里给大家带入一个场景:

假设 jack 要给 dr 发一条消息。 jack 的av地址是 jack@avplayer.org,dr 的地址是 dr@avplayer.org . 当然,目前是第一期,所以不支持 p2p , 也不支持多个服务器登录。 所以 jack 和 dr 的客户端都连接到router@avplayer.org。

jack 发送一个消息,首先用 dr 的公钥加密,将加密后的数据再用自己的私钥加密,然后发给 dr。在路由判断的时候,一般客户端上只有一条 “所有的数据都让 router@avplayer.org 代发”。

所以客户端就根据这个简单的路由表,把要发给 dr 的数据包发到了 router@avplayer.org 这个就通过 tcp链接直接发送就可以了, 因为这条连接自软件打开以来就保持着的。 然后到了 router@avplayer.org 它再根据路由表,就找到了 和 dr 相连的那条 tcp 链接。 然后数据再次被转发。于是 dr 就收到了。

这个时候,首先要进行数据签名校验。通过使用 jack 的工钥解开数据,证实数据来自jack,否则数据包会被直接丢弃。 接着再使用自己的私钥解密, 这样就取得了 jack 发来的消息。 那么这个过程中, 会有第三方知道 jack 发来的是啥消息么? 那是不可能的事情。 除非 dr 把私钥给泄漏了。


#4

【AV4】匠人(f_x_p)(464518486) 21:30:00 hyq avtcpif和avif 关系 看不懂啊 【AV6】hyqi@hyq.me 21:30:29 avtcpif实现了avif 【AV6】hyqi@hyq.me 21:30:36 大概就是这么个意思 【AV6】hyqi@hyq.me 21:30:52 也可以说avtcpif is_a avif 【AV6】cai(464893490) 21:38:21 avkernel 和 avtcpif 是非常独立的2个类 【AV6】cai(464893490) 21:38:33 这个可以由 两个人分别做 【AV5】木头(32065151) 21:40:08 看到kernel这个单词 瞬间高大上了 【AV4】Mic(736511465) 21:41:26 其实就是core 【AV4】多多(346345565) 21:43:00 那我就提提意见 首先是通讯 shiyongtcp长链接 【AV4】多多(346345565) 21:43:23 通讯协议 头部 加上版本 【AV4】多多(346345565) 21:43:39 那样就可以 【AV4】Mic(736511465) 21:44:00 加上版本?不要,协议号不进版本 【AV4】多多(346345565) 21:44:19 随时换协议版本时更改加密算法 【AV4】多多(346345565) 21:44:47 数据通信使用对称加密 【AV4】匠人(f_x_p)(464518486) 21:45:00 多多的思维 一直都是逆向。。。 【AV4】多多(346345565) 21:45:19 密钥的交换 在登陆时使用非对称 【AV4】多多(346345565) 21:45:48 至于多平台数据同步 【AV4】多多(346345565) 21:46:03 可以使用微软的active sync 【AV4】多多(346345565) 21:46:38 协议包构建可以用protobuf 【AV4】多多(346345565) 21:47:46 sync还支持离线消息同步 【AV4】多多(346345565) 21:48:09 那个做协议的没有版本号? 【AV6】cai(464893490) 21:48:46 继续 【AV4】多多(346345565) 21:48:46 好吧 你们继续 【AV6】cai(464893490) 21:48:48 继续 【AV4】多多(346345565) 21:49:50 protobuf过后的数据压缩还是压缩后protobuf 【AV4】多多(346345565) 21:49:58 看你如何设计了 【AV4】多多(346345565) 21:50:21 你可以在协议中注明压缩标志 【AV6】cai(464893490) 21:50:31 继续 【AV6】cai(464893490) 21:50:35 还有没