@ae86
都在这里 https://www.txthinking.com

@deorth 应该希望不大了，一来很多没实现，二来实现了的有很多不标准，三来 socks5 的 UDP 协议标准本身就有点绕

https://www.txthinking.com/talks/articles/socks5-and-http-proxy.article

@jim9606 嗯，是的

#4 下载的 curl 也是单个独立文件

@weeei brew 是不是也有类 port 的此类参数

@Masoud2023 没优势，就一个二进制文件

@thisismr2 #18

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

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

---

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

-- END

@gscsnm 是的，存在消息被 S 丢弃的可能，但因主观原因被丢弃的可能不大，因为 S 无法解密进而审查。客观原因倒是有，比如负载过高，像某些 IM 那样投递后删了，没有 ACK 机制，等

@mightybruce #23 #25 更正 PKG https://en.wikipedia.org/wiki/Identity-based_encryption

@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

@julyclyde nami 比较简单，只会在保存独立命令文件在 ~/.nami/bin ，不会写很多文件库到其他目录

@julyclyde

一个方便安装命令的工具，比如

```
bash <(curl https://bash.ooo/nami.sh)
```
```
nami install joker
```

安装运行 brook

nami install brook
joker brook wsserver -l :20000 -p world

安装运行 shadowsocks

nami install shadowsocks
joker ssserver -m aes-256-gcm -k hello -s 10.138.1.6:30000 -U --udp-timeout 60 --tcp-no-delay

查看

joker list

@Al0rid4l

之前一直在用 zx ，jb 是 zx 的 port 。
好处是不用安装 node 栈，jb 就是一个独立的二进制文件，放到 path 里就可以了
还有就是 zx 需要 await $`ls -l`, jb 不需要 await ，直接 $`ls -l`