thisismr2 最近的时间轴更新
thisismr2

thisismr2

https://t.me/s/txthinking_news
V2EX 第 406251 号会员,加入于 2019-04-25 23:11:32 +08:00
问: A 和 B 通过 S 中转来进行消息传递是否安全
  •  1   
    程序员  •  thisismr2  •  3 天前  •  最后回复来自 sBuk
    35
    Alfred Workflow 操作 Brook VPN
  •  1   
    分享发现  •  thisismr2  •  93 天前
    jb - 用轻松的方式写脚本
  •  1   
    程序员  •  thisismr2  •  101 天前  •  最后回复来自 thisismr2
    13
    Brook 上架 Mac App Store 了
  •  2   
    macOS  •  thisismr2  •  114 天前  •  最后回复来自 thisismr2
    23
    一个全自动管理 Brook 的 Web UI
  •  2   
    分享创造  •  thisismr2  •  2022-09-01 21:49:30 PM  •  最后回复来自 PickleFish
    68
    屏蔽最新版 Youtube App 广告的脚本
    Apple  •  thisismr2  •  2022-05-31 14:44:49 PM  •  最后回复来自 fenfire
    6
    替代软路由。 Linux , macOS, Windows 都可以成为透明代理网关
  •  1   
    宽带症候群  •  thisismr2  •  2022-05-23 20:03:38 PM  •  最后回复来自 omaidb
    4
    https://ipip.ooo 支持了下简单查询 IP. 和 简单 JSON API
  •  1   
    分享创造  •  thisismr2  •  2022-04-16 12:15:25 PM  •  最后回复来自 thisismr2
    19
    android 可以像 ios keychain 那样追踪用户吗
    Android  •  thisismr2  •  2022-02-28 16:37:16 PM  •  最后回复来自 XXWHCA
    54
    Brook v20220401
  •  2   
    宽带症候群  •  thisismr2  •  2022-02-22 12:17:24 PM  •  最后回复来自 thisismr2
    1
    thisismr2 最近回复了
    @thisismr2 #18

    结贴了: https://signal.org/blog/safety-number-updates/

    结论:也就是大家在使用 WhatsApp 或 Signal 时,是无法保证如他们宣传般的安全的,除非你和你的朋友再通过其他方式去验证 指纹(也就是上面的这个文章),其他方式必须是 WhatsApp 或 Signal 之外的方式(裁判和运动员不能是同一角色),比如线下或发邮件。

    ---

    声明: [以上结论仅是笔者研究两天的结果,仅供参考,并不代表权威] 。如果你是密码学或相关领域专家,可以阅读 https://www.whatsapp.com/security/WhatsApp-Security-Whitepaper.pdfhttps://signal.org/blog/safety-number-updates/ 以及其他相关 paper ,以得出更权威的结论。

    -- END
    @gscsnm 是的,存在消息被 S 丢弃的可能,但因主观原因被丢弃的可能不大,因为 S 无法解密进而审查。客观原因倒是有,比如负载过高,像某些 IM 那样投递后删了,没有 ACK 机制,等
    @mightybruce “你的电脑和手机在出厂的时候就已经植入受信的安全证书。” 也算是依赖可信第三方,新增角色了。( CNNIC)
    @mightybruce #22 是的核心问题就是 基于身份的密码学。涉及到贴文的内容就是 基于一个不可信的第三方来交换密钥。所以才质疑 WhatsApp/Signal 作为不可信第三方的,又没有提供其他渠道(比如线下)来确认。

    IBE 好像也是需要依赖一个可信第三方 PKS 。

    Boneh Franklin 我搜了一下,好像仍存"可疑",可能如你所说的是 性能问题
    @geelaw #11 嗯,对安全性没有定义明确

    - A 和 B 之外的第三者(方)可以得到 A 和 B 之间的明文消息
    - 或有第三者(方)冒充 A/B 身份 向 B/A 发送消息(当然 S 的认证机制可以保证,因为假设了 cookie 不会泄漏)

    @geelaw #11 @wy315700 #14 @leonshaw #17

    嗯,这个问题是其实是一个比较简单的加密场景。看来漏洞就是 C 通过多人转告或 [C 公开了 K] ,比如 push 到 github 上。这样 S 就能解密 A 和 B 的密文了

    @geelaw 感谢赐教

    背景是,在看 WhatsApp 的白皮书 https://www.whatsapp.com/security/WhatsApp-Security-Whitepaper.pdf
    开始的阶段需要交换公钥,无论是 Diffie–Hellman ,还是 PGP ,在通过中间人交换公钥的时候,都有可能被中间方替换,而这个中间方就是 WhatsApp 的服务端自己。

    但才疏学浅,没看十分明白,即 A 和 B 通过 WhatsApp 交换公钥的时候,怎么让 A 和 B 相信自己得到的公钥就是来自 A 和 B ,而不是 WhatsApp 的。[1]

    比如 TLS 本身是依赖一个公共的 CA 列表,大家都相信。PGP ,有时依赖一个 https://keys.openpgp.org ,这个有个简单的身份信息认证机制,有时依赖一个慢慢建立起来的信任网络。

    基于[1];同时,WhatsApp 的协议的复杂度也难于让用户(比如抓包)自己审计传输了什么。就在想有没有可能设计一个最简单的 minimal 的 end-end 加密的方案,用户随时可自行审查的,比如用户随时自己抓包就可以验证整个交互内容和逻辑。

    谢谢
    @GeruzoniAnsasu 感谢回复。
    > K 可由 C 泄露,
    是的 C 可以继续泄漏 K 。但文中有一个描述:“C 和 S 没有关系,也就是说他们之间不会(直接或间接的)共享自己知道的东西“。
    > 消息可从 S 截获
    TLS
    > 毕竟你只预设 A 和 B 的终端是可信的,S 和 C 没有包含在内
    抱歉。没有描述很清楚。我 append 一条 S 的终端也是安全的。
    C 终端自己是自由的,当然注意文中已经描述 任何客户端和 S 都有认证机制 cookie (注册)
    @ryuutanyou 感谢回复。但您指的“不安全”仍是主观的,因为 C 只有 K 没有密文。参考 #5
    /ping @geelaw
    101 天前
    回复了 thisismr2 创建的主题 程序员 jb - 用轻松的方式写脚本
    @julyclyde nami 比较简单,只会在保存独立命令文件在 ~/.nami/bin ,不会写很多文件库到其他目录
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   我们的愿景   ·   实用小工具   ·   3422 人在线   最高记录 5930   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 24ms · UTC 05:02 · PVG 13:02 · LAX 22:02 · JFK 01:02
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.