如此制作“一次性密码本”是否可行？

V2EX = way to explore

V2EX 是一个关于分享和探索的地方

已注册用户请登录

这是一个创建于 2790 天前的主题，其中的信息可能已经有所发展或是发生改变。

客户端与服务端分别下载同一个（比如说 4 个 g 的）大文件，并校验文件相同；
对此文件分别进行相同的处理，得到一个新文件：
循环 n 次，从文件开始偏移量递增，长度 1MB （或者更长）的内容，用相同的密码作盐，算 md5 。。。

然后结果堆起来变成一个大文件，比如说上面步进为 1 字节，
那么可以得到的新文件可以是大约 4g*16 那么大。

--------------

然后拿这个对原文 xor 。。

为什么发在这个节点呢？是因为这么个东西打算拿来加密协议头部。。。混淆协议特征哈

这个思路有弱点吗

文件

相同

密码

比如说

20 条回复 • 2016-10-14 08:41:45 +08:00

HankAviator

2016-09-13 22:21:01 +08:00

我手机上现在就剩 3GiB 了，看到第一句就怕了

aeshfawre

2016-09-13 22:29:47 +08:00

这是数学家干的活，你别抢别人的饭碗啊。
rsa 不好么，那些数学家玩出来的东西，你为啥想去挑战它。

rtyurtyu

2016-09-13 22:47:21 +08:00

没有什么意义的步骤，额外的计算量没有带来实际效益
从两个角度分析：
1.密钥分配安全性
你这个文件 url 最初怎么让双方知道，这个 url 实际上就是密钥分配嘛
如果程序里硬编码，那别人拆了程序就得到了
如果随机指定一个，那分配的信道不安全也一样白搭
与其这样还不如约定某随机函数的种子值当密钥呢，至少省了下载的时间还更安全一些
2.抗差分分析
随机的一个文件，如果里面有一堆 0(这可能性很高)，那 md5 就重复一堆一样的
这种分析出部分明文来可以说易如反掌
而密码学安全的伪随机数至少比上面要难分析的多

其实最正统的一次一密乱码本应用方法就应该是真随机数一堆预先用另外的安全信道分配好
这样才能放心异或加密明文，绝对安全

任何通过密钥计算出乱码本再 xor 的都不如直接用成熟的对称加密算法加密
说白了,xor 除了跟真随机数结合，其他的都没有安全性

Siril

2016-09-13 22:48:25 +08:00 via iPad

@HankAviator
先讨论理论上的可行性。。。假设两侧都是 linux x86_64 ，硬盘不小于 10GB ，假设包平均大小 512 字节，仅处理前 32 个字节的话， 10GB 可以满足 160GB 的需求，够一个月用吧。如果上面的想法没啥弱点，应该可以极大地提升识别协议的难度。 ss 被特征识别了你听说过没。

@aeshfawre 我知道不应该自创加密算法，所以问题重点是：
从一个具备一定特征的源文件（比如 iso 格式，无压缩的对吧，里面有一大堆 rpm 文件）
生成一个尺寸扩充、找不出特征的新文件。

这个过程不是加密，而是变形的摘要算法，不可逆。

如果此法有效（数据的模式被清除掉了），以此作为密码本可得完美加密

Siril

2016-09-13 23:04:14 +08:00 via iPad

@rtyurtyu 我发帖前搜了伪随机数，看见会出现衰减或出现循环这两种问题。
#求教哪里找得到密码学安全的伪随机数算法。

至于差分分析，上面说了从文件中裁剪一大块，一大块还完全相同的情况应当比较罕见。
加盐，算。。。比如说 md5 。是否就清除了原先文件的模式特征呢

我信赖 ssh 是可靠的，比如说从不太稳定的其他隧道过 1 个跳板跳板配置好服务端

我承认这种想法会浪费巨长的 cpu 时间获得不相称的收益。。。

那么求教更好的办法

lhbc

2016-09-13 23:13:54 +08:00

一个椭圆曲线比你这复杂度多不知道多少个指数级了

总之，别想着弄什么惊世骇俗的算法，直接 openssl 搞定你大多数烦恼

rtyurtyu

2016-09-13 23:14:23 +08:00

@Siril 密码学安全的伪随机数是一大族，相对于统计学安全伪随机数
很多加密工具包里需要随机数的地方都有密码学安全的伪随机
给你个有代码的算法： https://zh.wikipedia.org/wiki/Trivium_(%E7%AE%97%E6%B3%95)

循环是不可避免的，与算法的向量长度有关
像上面那个算法 80bit ，比你的 160GB(2^38)要长得多得多

Siril

2016-09-13 23:18:12 +08:00 via iPad

@rtyurtyu 谢谢，接触一个毫无了解的领域，感觉自己变成了小学生：）

tabris17

2016-09-13 23:21:20 +08:00

4G 数据做一次性密码本，这个没问题，后面说什么生成 4g*16 什么的都是扯淡

lsylsy2

2016-09-13 23:32:13 +08:00

ss 的特征统计不一定是统计包的内容，也可能是包的大小和发送速度，可能性还很大。
所以被识别的是“被加密的 HTTP 流量”，而不管他是被怎么加密的。
再换个角度，现在也有可能策略是“只要我看不懂是什么类型的加密流量，大到一定程度，掐掉它”

Siril

2016-09-13 23:32:41 +08:00 via iPad

@tabris17 这 4g 数据不是完全随机的，可能出现多处局部重复、而且包含相对固定的模式。
无论 4GB 的 iso 或者 mkv 。基于此种考虑发帖扯淡：）

就是不想生成 4GB 的随机数然后吭哧吭哧浪费带宽哈

那么，有没有一种算法把这 4GB 加上一个密码当成种子，生成消除了特征的巨大尺寸的"伪随机"数据? （用 md5 或其他摘要算法消除原数据的特征？）

Siril

2016-09-13 23:34:30 +08:00 via iPad

@lsylsy2 确实很可能如此。。。那就几乎没有办法了是吗

rtyurtyu

2016-09-13 23:54:21 +08:00

@Siril 如果就是不安全的信道安全通信，现代密码学已经有解决方案了
通常的步骤就是：
明文传公钥
非对称加密传密钥
用密钥对称加密传密文

如果 ss 防 gfw ，那么加密不是重点，重点是欺骗
我想过一个方法：
伪装成 http 下载图片文件，密文作为文件内容
client 这边可以把密文放在 url 或 cookie 或 post 参数，灵活性很大

gfw 想流量探测这个需要图像识别，难到几乎不可能