@jings 仍然有量子计算机解决不了的密码算法。

例如，量子计算机虽然很快，但是爆破散列的速度也只是将 256 比特的散列降低到 128 比特（ SHA512 降低到 SHA256 还是很安全的）。然后，用散列就可以构建公钥签名算法（如 MSS 算法）。

能抗量子计算机的公钥加密算法也是有的。例如 NTRUEncrypt 。

不要用 MD5 ，不要用 SHA ，不要用 RIPEMD ，不要用 WHIRLPOOL ，不要用任何散列！

用 PBKDF2 ，或者 scrypt ，或者 bcrypt ！

你的目的不是混淆密码，而是让人在获得密码存储后无法暴力破解。

存储密码要的是拖延破解的时间。单一散列不能。

@gzlock 可以， RSA 现在需要 2048bit 以上的 RSA 才算安全。你必须想办法能验证你所使用的、认为是对方的 RSA 公钥确实来自于对方，避免中间人攻击。

这方法最简单的是，将自己的 RSA 公钥散列，然后取前若干比特生成一个几个字母或者汉字构成的短句。对方收到你的公钥之后，也用同样的算法生成一个短句。然后两人用语音等方式核对。

如果你能进一步管理公钥，还可以参考 ZRTP 的协议：因为两个人第一次建立的通信很少有被中间人攻击盯上的，所以可以用过去成功交换的密钥作为对未来的密钥的认证。

@gzlock Res 是什么？

@gzlock 你这不是坑爹呢么，如果有人分析了你的代码，这和没有加密还有区别吗？
（别和我说使用混淆什么的，没用。密码学第一定律：你的加密方式总是公开的。）

你需要使用不对称加密，或者例如 Diffie-Hellman 这样的密钥交换协议。

咖啡！

@gzlock AES 是对称加密，你还至少需要了解如何交换 AES 密钥的知识（需要不对称加密或者某种密钥交换协议）。
此外，还要考虑消息的完整性，因为即使是加密了，传输中的错误或者其他因素也可以导致消息在解密后和原文不一样。还要考虑消息来源的可靠性，包括如何确定发送者没有被仿冒。还有可能需要可以或者不可抵赖性，等等。

在国外可以起诉，是有先例的。据我所知会胜诉。
或者会被列到耻辱柱上。

也有一些绕过的方法，比如 7 楼的方法，那个封装的程序开源。

@TakanashiAzusa 除了虚拟网卡之外，还有路由表是需要配置的，我的理解是类似电脑上有 2 张网卡，比如笔记本同时插网线还用 wifi ，那么怎么上网，走哪个，并不是自动的。类似的 Python 程序确实有使用 ip route 命令自动修改系统配置的例子，退出时改回来。我认为这个比较费解，不知道一来如何保证适合于所有的系统，二来不知道程序出错崩溃之后不改回来会有什么后果，所以先不做。不过，确实应该是有这个潜力的，比如可以先尝试手动配置。

@rwx 原则上可以如此，然而我并没有写这方面的代码。

@TakanashiAzusa 不一定，不过可以。需要配置路由表，本渣表示还是先在服务器上架代理比较好理解。

@aliuwr 非常感谢！其实我在墙外，所以在调试中并没有感受到连接问题。我 ping 的时候小 2 个数量级。

我认为一方面是墙的问题，一方面，目前用 WebSocket 或者所有的 TCP 连接传送 UDP 数据包（强调下实际上只是 UDP 数据包的内容，亦即加密的 IP 数据帧）是个很糟糕的主意。对于被代理的 TCP 连接，这就成了 TCP over TCP 。可以说只是用来验证可行性之用。

实话说，我不太理解为什么 SS 会更快。不过既然它很快，那么给我的程序写一个利用 SS 的代理的话是不是也会很快？ XD

---

@aalska @quix UDP 在本程序中只是作为一种内部的接口协议而存在。当然也可以真的在互联网上放出 UDP 包。但是 UDP 包在穿越各种防火墙时并不容易，程序也不好写。

@rwx 这个很难分析啊。我倾向于抱有希望。程序中用到 UDP 的地方，实际上是和中间的隧道代理解除了耦合，不需要等待具体哪个隧道代理完成对包的发送。因为传递的 IP 帧是可以被丢弃的，不像 TCP 协议。实际情况可能是，一个隧道代理被堵塞之后，程序接着往这里发包，包就不会被传送出去。在 TCP 看来包也许是 drop 了，所以会重发。重发时因为随机选择路线，就可能走另一条路线。

@aliuwr 不过这么说难道偶尔还是可用的？(目前能确认这一点对我来说就是好消息了)

我测试时用 polipo 搭的 http 代理到服务器上的 tor 。要注意的是防火墙的设置。

@aliuwr 可以./run_as.py --debug c|s 就是添加 debug 选项。会输出收发的包。不过我注意到这个确实和别的因素还有点关系，比如如何处理 MTU 大小的包，这应该是问题所在。

我目前没有墙的环境，没办法严格测试，还请多多指教。

@rainy3636 头像是新画的，不过难道没人认出我的 id 和这个软件名的梗？

@cnnblike Readme 是赶出来的，我会继续修改。

我设计的重点是多路连接和穿墙的隐蔽和灵活性，效率，我想一方面多路连接有可能弥补一点效率，一方面是这个损失只要比墙带来的效率损失有优势就行。

IP 帧在加密时会增大 56 字节，其中 32 字节为 HMAC ， 24 字节是加密的 IV 。之后密文通过 UDP 传递给隧道代理， UDP 只是隧道代理的接口协议，所以不能计算进来。至于隧道代理如何处理这个加密的包，就不一定了。比如可以直接换成 TCP 发出去，等等。