这是一个创建于 3319 天前的主题，其中的信息可能已经有所发展或是发生改变。
客户端与服务端分别下载同一个（比如说 4 个 g 的）大文件，并校验文件相同；
对此文件分别进行相同的处理，得到一个新文件：
循环 n 次，从文件开始偏移量递增，长度 1MB （或者更长）的内容，用相同的密码作盐，算 md5 。。。
然后结果堆起来变成一个大文件，比如说上面步进为 1 字节，
那么可以得到的新文件可以是大约 4g*16 那么大。
--------------
然后拿这个对原文 xor 。。
为什么发在这个节点呢？ 是因为这么个东西打算拿来加密协议头部。。。 混淆协议特征哈
这个思路有弱点吗
对此文件分别进行相同的处理，得到一个新文件：
循环 n 次，从文件开始偏移量递增，长度 1MB （或者更长）的内容，用相同的密码作盐，算 md5 。。。
然后结果堆起来变成一个大文件，比如说上面步进为 1 字节，
那么可以得到的新文件可以是大约 4g*16 那么大。
--------------
然后拿这个对原文 xor 。。
为什么发在这个节点呢？ 是因为这么个东西打算拿来加密协议头部。。。 混淆协议特征哈
这个思路有弱点吗
 | 1 HankAviator 2016-09-13 22:21:01 +08:00 我手机上现在就剩 3GiB 了，看到第一句就怕了 |
 | 2 aeshfawre 2016-09-13 22:29:47 +08:00 这是数学家干的活，你别抢别人的饭碗啊。 rsa 不好么，那些数学家玩出来的东西，你为啥想去挑战它。 |
 | 3 rtyurtyu 2016-09-13 22:47:21 +08:00  1 没有什么意义的步骤，额外的计算量没有带来实际效益 从两个角度分析： 1.密钥分配安全性 你这个文件 url 最初怎么让双方知道，这个 url 实际上就是密钥分配嘛 如果程序里硬编码，那别人拆了程序就得到了 如果随机指定一个，那分配的信道不安全也一样白搭 与其这样还不如约定某随机函数的种子值当密钥呢，至少省了下载的时间还更安全一些 2.抗差分分析 随机的一个文件，如果里面有一堆 0(这可能性很高)，那 md5 就重复一堆一样的 这种分析出部分明文来可以说易如反掌 而密码学安全的伪随机数至少比上面要难分析的多 其实最正统的一次一密乱码本应用方法就应该是真随机数一堆预先用另外的安全信道分配好 这样才能放心异或加密明文，绝对安全 任何通过密钥计算出乱码本再 xor 的都不如直接用成熟的对称加密算法加密 说白了,xor 除了跟真随机数结合，其他的都没有安全性 |
 | 4 Siril OP @HankAviator 先讨论理论上的可行性。。。 假设两侧都是 linux x86_64 ，硬盘不小于 10GB ，假设包平均大小 512 字节，仅处理前 32 个字节的话， 10GB 可以满足 160GB 的需求，够一个月用吧。如果上面的想法没啥弱点，应该可以极大地提升识别协议的难度。 ss 被特征识别了你听说过没。 @aeshfawre 我知道不应该自创加密算法，所以问题重点是： 从一个具备一定特征的源文件（比如 iso 格式，无压缩的对吧，里面有一大堆 rpm 文件） 生成一个尺寸扩充、找不出特征的新文件。 这个过程不是加密，而是变形的摘要算法，不可逆。 如果此法有效（数据的模式被清除掉了）， 以此作为密码本可得完美加密 |
| 5 Siril OP @rtyurtyu 我发帖前搜了伪随机数，看见会出现衰减或出现循环 这两种问题。 #求教哪里找得到密码学安全的伪随机数算法。 至于差分分析，上面说了从文件中裁剪一大块，一大块还完全相同的情况应当比较罕见。 加盐，算。。。比如说 md5 。 是否就清除了原先文件的模式特征呢 我信赖 ssh 是可靠的，比如说从不太稳定的其他隧道过 1 个跳板跳板配置好服务端 我承认这种想法会浪费巨长的 cpu 时间获得不相称的收益。。。 那么求教更好的办法 |
 | 6 lhbc 2016-09-13 23:13:54 +08:00 2 一个椭圆曲线比你这复杂度多不知道多少个指数级了 总之，别想着弄什么惊世骇俗的算法，直接 openssl 搞定你大多数烦恼 |
| 7 rtyurtyu 2016-09-13 23:14:23 +08:00 1 @Siril 密码学安全的伪随机数是一大族，相对于统计学安全伪随机数 很多加密工具包里需要随机数的地方都有密码学安全的伪随机 给你个有代码的算法： https://zh.wikipedia.org/wiki/Trivium_(%E7%AE%97%E6%B3%95) 循环是不可避免的，与算法的向量长度有关 像上面那个算法 80bit ，比你的 160GB(2^38)要长得多得多 |
 | 9 tabris17 2016-09-13 23:21:20 +08:00 4G 数据做一次性密码本，这个没问题，后面说什么生成 4g*16 什么的都是扯淡 |
 | 10 lsylsy2 2016-09-13 23:32:13 +08:00 ss 的特征统计不一定是统计包的内容，也可能是包的大小和发送速度，可能性还很大。 所以被识别的是“被加密的 HTTP 流量”，而不管他是被怎么加密的。 再换个角度，现在也有可能策略是“只要我看不懂是什么类型的加密流量，大到一定程度，掐掉它” |
| 11 Siril OP @tabris17 这 4g 数据不是完全随机的，可能出现多处局部重复、而且包含相对固定的模式。 无论 4GB 的 iso 或者 mkv 。 基于此种考虑发帖扯淡 ：） 就是不想生成 4GB 的随机数然后吭哧吭哧浪费带宽哈 那么，有没有一种算法把这 4GB 加上一个密码当成种子，生成消除了特征的巨大尺寸的"伪随机"数据? （用 md5 或其他摘要算法消除原数据的特征？） |
| 13 rtyurtyu 2016-09-13 23:54:21 +08:00 @Siril 如果就是不安全的信道安全通信，现代密码学已经有解决方案了 通常的步骤就是： 明文传公钥 非对称加密传密钥 用密钥对称加密传密文 如果 ss 防 gfw ，那么加密不是重点，重点是 欺骗 我想过一个方法： 伪装成 http 下载图片文件，密文作为文件内容 client 这边可以把密文放在 url 或 cookie 或 post 参数，灵活性很大 gfw 想流量探测这个需要图像识别，难到几乎不可能 |
 | 15 zoudeze 2016-09-14 01:13:18 +08:00 via iPhone 我想到了一个更简单的，直接用 ip 地址作为数据内容不就得了（就说把发送方的 ip 改为传输内容），弱点是双方必须有公网 ip |
| 16 HankAviator 2016-09-15 09:00:57 +08:00 @Siril 我学密码学时第一课的课前须知就有一条 “不要尝试自创算法”。目前现有的二次验证几乎都不需要预先下好如此庞大的数据才能使用，也并不要求在线。 伪随机加密一次和 3DES 想法基本一致，这样的方式抵抗中途相遇攻击的能力弱，如果用在 ss 上反而会成为整个环节上最薄弱的一环。 |
| 17 HankAviator 2016-09-15 09:04:08 +08:00 另外 10GiB 的数据，一个月一次可能实际应用也困难重重。仿佛感受到多年前同步比特币区块的痛。对手机简直是腊肠强奸一样。 |
 | 18 chinawrj 2016-09-15 10:18:42 +08:00 一次性密码本由不是一次的密码制作。不可行啊。 |
 | 19 lilydjwg 2016-10-07 13:50:15 +08:00 「信息隐藏」？ |
 | 20 testcaoy7 2016-10-14 08:41:45 +08:00 One Time Pad 可行啊，只不过变成跑流量的了，切记密码本不可重复使用！！！ |
Select Language