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

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 文件的编辑也很直观。

9072 次点击
所在节点    分享创造
154 条回复
vangjing
2022-01-12 17:09:34 +08:00
上面一堆人谈是加密解决还是编码解码,忘了自己要达成什么目的
“日常生活中有些场景本身就不要求很高的安全规格,只需要稍稍加点防护就足够了。
比如上传到网盘,只要不被轻易扫描、或者万一泄露文件时让人看着一堆乱码不乐意花时间精力去解密,就足够了。”

我的方法很简单,文件名[密码].7z ,密码可以是真正的密码,也可以是密码的一部分,看文件保密程度。
SuperMild
2022-01-12 17:18:29 +08:00
@Greenm 我很好奇,如果让你写一个暴力破解算法,你有什么思路?

网上已有的别人写好的暴力破解程序,是绝对破解不了我这个密文的,因为需要先把真正的密文分离出来。



另外,我们的分歧可能集中在一点:镶嵌方式是加密算法,还是密码?

我的看法是,镶嵌方式是密码,而不是算法。理由是:如果我做的是编码,那么一个人拿了 10 个按同一种编码方式处理过的文件,是能轻易看出规律来的,这 10 个文件可以相互印证。

但如果我做的是加密,拿到 10 个按同一种加密方式处理过的文件,也是无法相互印证的,看不出规律来。
SuperMild
2022-01-12 17:24:04 +08:00
@xinghen57 非常同意重要东西不放网盘,我现在主要用网盘来临时存放一些文件,然后我会定期保存到本地多个机械硬盘里,就把网上的删了。

但我不同意你说成本大,这个加密脚本很容易写的。
eason1874
2022-01-12 17:29:09 +08:00
我用 AES 分组密码模式,IV 放在文件开头,然后把 IV 反转编码成 Base64 再取 UTF-8 字节作为密钥,然后加密,效果也一样,不用记密码,不知道代码的人只看密文也不知道怎么解

只靠代码保密来加密,相当于只有一个密钥,代码就是密钥本身。如果要保存代码,那跟把密钥写死在代码里没分别。如果不保存代码,靠记代码思路,那跟记一个密钥明文没分别
fregie
2022-01-12 17:31:06 +08:00
别讨论了,就是等效于编码。
不知道编码方式没办法解码,知道编码方式无成本解码。
你说你能看出相同方式编码文件的规律,如果是适用于任何编码方式的话,我觉得你的大脑计算能力已经超出人类的的范畴了。
SuperMild
2022-01-12 17:45:46 +08:00
@fregie 你说 不知道**编码方式**没办法解码,知道编码方式无成本解码。

我说 不知道**密码**没办法解码,知道密码无成本解码。

都说得通,你能说说你认为镶嵌方式是加密算法而不是密码的理由吗?

另外,你能说出一种编码方式是不容易被看出有规律的吗?(我是指看出有规律,而不是指看出这个规律的细节)
SuperMild
2022-01-12 17:52:39 +08:00
@fregie 补充说明一下为什么我认为能不能“看出有规律”是重要的,因为看出有规律,就可以初步判断采用了编码而不是加密,接下来的解密方式就不一样了。

对于加密过的文件,通常会考虑彩虹表之类的暴力破解。而对于编码,则会尝试各种常见的 bit 操作,或者找其中的相同区块,编码处理通常会产生很多相同区块。
xinghen57
2022-01-12 17:56:34 +08:00
@SuperMild 首先,我不是搞密码的,所以不会从纯技术角度考虑这事。其他如下:

成本我能想到的有这么几方面:
1 、如何保证自己使用的系统整体环境安全?或者能确定只在自己信任的系统下使用?
2 、文件加解密开销。
3 、定期更换密钥、储存位置的记录、应用等开销。

不想网盘扫描,不必这么麻烦。
不想让人看的,你是指网盘内容被泄露?这在网盘行业是大新闻,没哪家公司会主动做的。当然配合有关部门除外。

我个人理解,数据从产生后存储、传输到传播,除非全部安全可控,不然基于木桶原理,总会取决于最短板。
你这种方式,存网盘是整个流程最薄弱的环节。
这环境脱离你的掌控,如果真存在私人网盘内容被可以泄露的情况,你存的内容被破解只是时间问题和你本身重要性问题。
或者你的解密算法强到在密码领域无人能破解?

与其专注于加密算法,我更倾向使用行业认可的加密算法,把精力放在存储、传输传播等方面。

因此,综合对比下,我觉得你这方式就不合适了。

你这么做,只有成本。这既不能带来收入的增加,也不能提高效率。有的只是幸存者偏差下的安全。
FakNoCNName
2022-01-12 17:59:47 +08:00
@SuperMild 我刚才的意思是,文件只是加密前后的哈希变了,分享加密后的文件一样网盘可以通过 hash 来判断。

尤其是有人举报的时候。
crab
2022-01-12 18:06:21 +08:00
之前把移动硬盘的 XX 视频异或文件头防止误触发直接播放。
momocraft
2022-01-12 18:10:52 +08:00
wq
SuperMild
2022-01-12 18:11:06 +08:00
@xinghen57

你说的很有道理,我基本同意(只是关于成本与收益部分不太同意)。

其实我做这个,主要是用来处理临时文件的,因为现在不怎么用 U 盘,而且在外出差之类的时候使用 U 盘、移动硬盘也容易弄丢,我就加密后上传到网盘,大概几天之内等我本地备份好,或者改用冷储存之后,就删除网盘里的临时文件。

网盘泄露我是亲自见证过的,不是我的资料泄露,是某网盘发生了大型泄露,我按照网上流传的方法去看了很多陌生人的照片、视频。

而且,我怀疑他们内部也会有人工抽检,会有人去看用户的资料,比如 OCR 扫描图片发现敏感词时,会不会有人工抽检复核?(这个只是怀疑,没有依据)

但如果采用我的方法加密了,这个加密过程很轻松,既能防止被扫描,万一网盘泄露也没有人专门针对一份加密文件去破解,可以说我的目的达到了,成本也不高。
SuperMild
2022-01-12 18:15:21 +08:00
@FakNoCNName 原来如此,但我这个不用于分享,而且我把密钥插进密文里,理论上已经变成另一个文件了,大概能防住一点吧。
momocraft
2022-01-12 18:16:36 +08:00
在网盘这个用途上
用自己生辰 hash 当密码同样不需要管理, 而且 (在不泄漏具体 hash 函数时) 不怕暴力破解
更重要是不用骗自己
ganbuliao
2022-01-12 18:19:56 +08:00
理论上来说,是编解码器吧,自己用是没有人知道的编解码器。开源了用的人少就是,小众编解码器。用的人多了,新的文件格式。
SuperMild
2022-01-12 18:26:52 +08:00
@momocraft 用生日 hash 也很好,其实直接用生日日期也行,不需要 hash 。

但我这个方法也不见得很差吧,也没比生日 hash 差啊。
timethinker
2022-01-12 18:27:43 +08:00
我还记得之前 github 收费的时候,就有人尝试使用公开仓库来当作网盘使用,甚至还为此开发除了一套自动化的脚本程序,push/pull 的时候自动本地加密 /解密。使用过程中无感,只需要配置一个密钥即可,当然那个时候的限速还没有现在这么严重。Windows 平台也有很多在驱动层实现的透明加密软件。

所以如果只是想要文件在落地的时候进行加密,防止其他人直接绕过系统得到原始数据,完全可以采用一些比较成熟的方案,而且安全性是比较高的。记得很久以前在学习安全这一块的时候,给我印象最深的一句话就是“不要自己去发明加密系统,除非你是从事这个行业的专家”。

当然了,如果只是为了绕过一些自动化的扫描,也完全可以使用压缩软件+密码的形式。不管做什么,明智的做法应当是尽快找到一种正确的方式好让自己别把时间浪费在本不应该浪费的事情上面。
SuperMild
2022-01-12 18:34:12 +08:00
@ganbuliao “理论上来说,是编解码器”,你这里说的理论,具体是什么理论呢?

我真的认为镶嵌方式是密码,而不是加密算法,上面有不少人说我的是编码,但也没人说出很硬的道理来。

第一步,用 cryptography.Fernet 加密,这一步是加密大家应该都同意
第二步,把密钥插入密文的某个位置,这一步,为什么就让整个过程变成编码了呢?

我的看法是,第二步只是把一个长的、复杂的密码换成一个短的简单的密码。

采用简单密码的加密,还是加密啊。
des
2022-01-12 18:38:38 +08:00
无法理解……你这样玩,不变相脚本等于密码?
真想不用密码,建议 gpg
软件公开容易获取,安装也方便,加密完全不需要用到密码
SuperMild
2022-01-12 18:41:13 +08:00
@qwe520liao “不要自己去发明加密系统” 这个道理我懂,如果我搞了这一套,然后我声称这一套很安全,是强加密,那我才是你说的那种情况。

但我知道这套方法的有缺点,并且强调了不适用于真正的机密,很明显不是自己发明加密了。

我是故意降低一点安全性,换取更高的便利性。

成熟的方案我也知道,但成熟的方案都需要管理私钥、保管私钥,我就是不想保管这个,我在这个地方故意降低了安全性,但我也确实获得了便利:不需要管理私钥。

然后,我把它用于中等安全要求的场景,就很合适,便利与安全有一个平衡。

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

https://tanronggui.xyz/t/827768

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

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

© 2021 V2EX