一种不需要密码的加密方法(用于防止网盘扫描等场景)

2022-01-12 11:28:28 +08:00
 SuperMild

安全与便利总是难以兼顾,记忆密码或管理密码,加密或解密时输入密码等操作如果能彻底免除,会非常便利,但是安全性也自然会降低。

幸好,日常生活中有些场景本身就不要求很高的安全规格,只需要稍稍加点防护就足够了。

比如上传到网盘,只要不被轻易扫描、或者万一泄露文件时让人看着一堆乱码不乐意花时间精力去解密,就足够了。

因此,我想到了把密钥直接内嵌到密文里的方法,从此不需要记忆或管理密码,因为密码就在密文里,解密时也不需要填写密码,用脚本自动化提取密码就可以解密了,方便到极致!

当然,该方法只适用于大多数普通文件,不适用于真正的机密。

听起来不靠谱?(原理)

其实很靠谱,因为:

  1. 一般人根本想不到密码就在密文里
  2. 就算想到了,也不知道具体位置
  3. 如果我把一个密钥拆成 3 段,分别镶嵌在不同位置,就更难猜了
  4. 如果我把密钥拆成 N 段,并且调换顺序后再镶嵌进密文里,你还乐意去猜吗?

而加密解密却很方便,不需要记住密码,因为程序可以自动化提取密钥。

即便如此,当然还是不适用于真正的机密,但日常大多数文件这样处理已经足够安全了。

开源脚本

不久之前我做了一个命令行工具框架,用来管理零散的脚本,这个加密脚本也是其中的一个插件。

安装框架的方法看这里: https://github.com/ahui2016/ffe/blob/main/docs/usage.md (简单来说,pip install ffe 就可以了,要求 python 3.10+)

安装了 ffe 之后,用以下命令安装这个加密解密脚本:

ffe install -i https://github.com/ahui2016/ffe/raw/main/recipes/mimi.py

如果遇到网络问题,也可以使用 gitee 地址:

ffe install -i https://gitee.com/ipelago/ffe/raw/main/recipes/mimi.py

最后安装依赖 pip install cryptography (只依赖这一个第三方库)

使用方法

可见,加密解密过程都不需要输入密码。

使用命令 ffe dump -r mimi file.txt > mimi.toml 可以生成一个 mimi.toml 文件,以后可以使用命令 ffe run -f mimi.toml 来执行相同的任务,这对于需要经常重复的操作来说是很方便的。而且,在 toml 文件里还可以添加别的任务(比如打包压缩),一次性依次执行一系列任务。

关于 ffe

ffe 是一个命令行插件框架,可以用 Python 来写插件,多个插件可组合使用,适合用来管理零散的脚本。后续我还会发帖介绍我写的插件,比如免费上传文件到云端。多个文件组合后,使用一个命令 ffe run -f <toml file> 即可一次性执行打包、加密、上传,toml 文件的编辑也很直观。

9073 次点击
所在节点    分享创造
154 条回复
kirisamemarisas
2022-01-13 11:15:36 +08:00
接上文(手滑发出去了)
因此,这个算法的适用人主要还是取决于使用者能够接受多少文件被放置到非私人场景吧。
给有想法自己实现这种算法的楼主点赞。
glfpes
2022-01-13 11:18:36 +08:00
整个密码九宫格让 OP 乐乐? why so serious

守序 对称加密 /非对称加密才是有效的加密
中立 不知道领域知识的话,你们解不开 OP 的编码,这也是一种加密(梵语,base64 表示赞同)
混乱 猫叫也是加密
SuperMild
2022-01-13 11:18:48 +08:00
@glfpes 我没有不肯承认啊,有人说我这个是编码,但他们没有说理由,我问理由是什么,问理由就是嘴硬吗?

我不该问理由吗?

有人说了理由,我有不懂的地方,就继续问,这就是交流啊。
SuperMild
2022-01-13 11:21:55 +08:00
@kirisamemarisas 谢谢支持!

我这个还有个好处:不会退化为暴力破解。

我这个是最不怕暴力破解的,因为密文里混入了密钥,破解者如果不把密钥分离出来,就无法获得真正的密文,自然无法暴力破解。
glfpes
2022-01-13 11:23:22 +08:00
@SuperMild 你没必要问理由,你只应该承认这玩意就是个编码,然后结束讨论。
krixaar
2022-01-13 11:23:57 +08:00
怎么吵了这么多楼……
咬文嚼字的事儿不重要,重要的是这方法本来存在的目的是不记密码,但需要记流程,你自己发明的流程你当然印象深刻,我要是同时看到多个人的类似方法分享(好比刚才说的我自己之前用的 XOR ,你这个密钥分散,别人再来个密钥是文件名,甚至古典加密都用上),然后脑子抽了不同的时候用了不同的流程处理,到头来想不起来用哪个流程加密的(我要是脑子这么好使我就记住密码了),还得穷举,于是怕自己忘了用了哪个流程,得记加密流程,记下来的加密流程就得存在哪个地方,然后还得保证能记住放在了哪个地方,这个地方得能容灾,明文写下来是不是就不安全了,违背了加密的初衷,于是再想办法加密记下来的加密方法……

我再给浇点油吧,你这加密就是混淆( obfuscation )🤣
SuperMild
2022-01-13 11:24:14 +08:00
@glfpes 如果破解者拿到 10 份,梵语、base64 、或别的编码算法处理过的文件,这 10 份对照着看,可以看出有某种规律,可以判断是编码而不是算法。

但我这个方法处理过的文件,拿 10 份去对照着看,不能看出任何规律。

这就是我认为编码与加密的不同。
SuperMild
2022-01-13 11:27:25 +08:00
@glfpes 你说 “你没必要问理由,你只应该承认这玩意就是个编码,然后结束讨论。”

从旁观者看来,你这种态度更像嘴硬。

如果你不喜欢交流,大可拉黑我,这很正常。但你不能对我说:你闭嘴。这很幼稚,因为你明知道你这样很不礼貌,你也没这个权力。
2i2Re2PLMaDnghL
2022-01-13 11:38:08 +08:00
算力不支持网盘自动破解加密
SuperMild
2022-01-13 11:50:29 +08:00
@2i2Re2PLMaDnghL 如果只针对短密码、生日、电话号码、常见密码去尝试,算力是足够的,请看隔壁贴的讨论 https://v2ex.com/t/827977 百度网盘会不断升级扫描系统。
Asvel
2022-01-13 12:32:32 +08:00
@SuperMild 几行关键代码只是举例子,这个记不准那就「 len_of_key=43,len_of_head=15 」,还是记不准那就 md5("43,15"),总不能说只有逻辑记得住其他啥也记不住吧。

重点不在于记住什么,而是你这个加密方法依赖的仍然同样是“记住”,那这个记住的内容本质就是口令( password )。
2i2Re2PLMaDnghL
2022-01-13 12:35:15 +08:00
@SuperMild 我记得算出来按现在的网盘上传量,如果对每个文件进行 8 位以内纯数字尝试(包括不同的算法和配置),估计消耗算力在每天 300 亿美元来着?
问题不是实际算力不足,问题是这个预算根本不在合理范围内。杀头的生意有人做,赔本的生意没人做。
SuperMild
2022-01-13 13:32:10 +08:00
@Asvel 你说本质是记住一个口令,这点我同意,只是每个人的记忆特点不一样。

如果说我做的事是选择了一种适合我的“选择密码并且记住密码”的方式,这样说我完全同意。

也可以说我提供了一种“选择弱口令并且记住弱口令”的方法,我觉得我这种弱口令,比生日、电话号码稍强一点。

记“len_of_key=43,len_of_head=15”这个当然可以,但必须是我真的写了一个这样的脚本,这句代码才会有意义,才会变得容易记而不是一句随手写的代码,因此,本质上还是需要做写脚本镶嵌密钥这件事,这是记忆的基础。
SuperMild
2022-01-13 13:42:13 +08:00
@2i2Re2PLMaDnghL 想到了一个类比

假设我有一个女朋友,假设她的生日是 8 月 27 日,我基于这个假设去记忆 8.27 这个日期,我觉得不好记。

而如果我真的有一个女朋友,她的生日真的是 8.27 ,并且我还陪她过过生日,那我就会觉得这个日期好记多了。

这是我的记忆特点,也许别人不一样。
SuperMild
2022-01-13 13:51:23 +08:00
@2i2Re2PLMaDnghL 如果一个扫描系统不断积极地升级改善,那么我就有理由相信,当它发现一些用户总是上传加密文件上来时,会特别“关照”这些用户,因为这是“可疑”用户,数量也不多,特别关照他们不需要太高成本。

一个不断积极地升级改善的扫描系统,其背后的开发人员显然有奖惩机制,才会让他们积极工作,而既然有奖惩,他们自然会在成本可控的前提下想方设法建立功劳。
fregie
2022-01-13 14:13:34 +08:00
@SuperMild "镶嵌方式是可以有很多种变化"
这当然不算加密,如果你没公开你的镶嵌方式,那就是其他人因为不知道编码方式而不能解码的编码,如果你公开了你的镶嵌方式,那么其他人可以随时解码。
反观加密,任何加密算法本身的逻辑和算法都是公开,但是每个人在这个前提下,因为可以用只有自己知道的密钥而完成加密不让别人知道。
如果你打算通过不公开编码方式而达到加密的效果,是可行的,但并不代表你这种算法就是属于加密算法了。
说白了你这就属于“把编码方式作为密钥不公开而达到加密效果的编码”
关键就在于你公不公开你的逻辑,不公开自己用的话,就没必要在这里跟大家分享了,公开的话,它就不能加密了。
SuperMild
2022-01-13 15:05:31 +08:00
@fregie 你和我的主要分歧,与上面一些人一样,主要集中于一个问题:镶嵌方式是一种编码方式,还是一个密码。

你说 “如果没公开镶嵌方式,其他人因不知道**编码方式**而不能解码”

但我可以说 “如果没有公开镶嵌方式,其他人因不知道**密码**而不能解密”,我们只是各执一词,你并没有提供更多理由来支持“镶嵌方式不属于密码,而属于编码方式”这个说法。

我的加密算法也是公开的( cryptography.Fernet ),我把密钥镶嵌在密文里,比如分三段,依次镶嵌在原密文的第 3 、5 、7 个位置,等效于一个密码:Split-3-into-357 。我只是把原来复杂的密钥转换为这样一个简单的密码,加密过程用的依然是公认的加密算法。


---- 重点:加密后的密文,即使被拿到多份一起对比,依然看起来是无规律的加密,而不是有规律的编码。(这点很重要,请务必重视)----


另外,你还没正面回答这个问题:如果我宣布密码可能是我的生日、也可能是我的电话号码,也可能是 123 abc 之类的简单密码,这种情况下,密钥不是固定的,那你认为算不算加密呢?

(因为这个假设的情形与我把密钥插进密文,本质上是一样的。如果你觉得在这个假设里,你很难说出“那不属于加密,而是属于编码”,那么,也许我的这个方法,也并非那么轻易就能被断定为编码吧)
SuperMild
2022-01-13 15:11:12 +08:00
@fregie 我又想到了一个理由来支持我的说法

上面有人说,用生日日期来做种子,生成密钥后拿去用。貌似大家都不会质疑这是编码还是加密。

那我现在只是类似于用镶嵌方式做种子,用这个种子可以找出真正的密钥。
SuperMild
2022-01-13 15:16:51 +08:00
我认为最终判断这是一种编码还是加密,对于结果我不是很在乎,但我希望有人认同这至少需要讨论之后才能渐渐弄清楚,而不是一眼就能看出来的事情。

我觉得一部分人下判断太快了,看起来好像判断与结果很重要,输赢很重要,讨论过程不重要。而我更看着讨论过程。
fregie
2022-01-13 16:17:42 +08:00
@SuperMild 可以的,只要你永远不公开你的脚本,永远也没人能破解的出来,但是也永远只能你一个人用,这能算是加密。但是这有什么意义呢,不公开的话何必在这里讨论呢?难道要让大家都自己写一个脚本来自己加解密吗?随便找一种别的加密算法保存一个密钥永远不公开不是一样的。

这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://tanronggui.xyz/t/827768

V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX