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

[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 info -r mimi 可查看详细说明。
• 使用命令 ffe run -r mimi file.txt 即可加密 file.txt, 加密后的文件是 file.txt.mimi 。
• 使用命令 ffe run -r mimi file.txt.mimi 即可解密 file.txt.mimi, 解密后的文件是 file.txt （命令是一样的，根据文件的后缀名来自动选择加密 /解密）

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

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

[SuperMild]

@vophan1ee 上面有人说过取反、编码、以及你说的+N ，安全程度应该比我这个方法稍差一点点。

改 bit 有个很大的问题：破解者只需要截取一小段（不需要整个文件）就可以暴力尝试各种改 bit 方式，由于截取很短的密文即可，破解速度可以很快。

简而言之，我现在这个方法在安全性与便利性之间平衡得比较好。

[Greenm]

你对加密和编码的理解不对：

1. 对于同一个文件，加密后的密文，每次都不一样；编码后的“密文”，每次都是固定不变的。

> 对于加密算法来说，同样的密钥和算法对同样的输入，都一定能得到同样的输出内容，这就是正经的加密算法。编码其实也是一样的。 所以这并不能算做加密与编码的区别。

其实编码和加密的主要区别就是加密 /编码的算法是不是怕第三方知道。 如果第三方知道了算法就能从密文解出明文，这样的我们就倾向于是编码，否则就是加密。

可以参考古典加密算法，他们的共同点都是不能泄露加密算法，一旦泄露就失去加密效果，所以古典加密在现代计算机密码学范畴内，基本不能算做加密算法了，只能叫做编码。

楼主你的更倾向于编码，换句话说，非标准 base64/base72 等等编码对于不知道算法的人来说也可以起到加密的效果。

[SuperMild]

@jupiter157 区分加密人和其他人？这个问题没看懂。

镶嵌规则可以很简单，而破解的人一般只会想到暴力破解之类的。

想象一下，你拿到一个密文，不知道加密方法，会不会想 “密钥可能分成了 N 段，并且调换了其中几段的位置，镶嵌在密文中的 N 个位置里”，不会这样想，就算想到了这个，也不乐意花精力去破解。

但是，一般人却很有可能会尝试暴力破解（网上暴力破解工具一大堆，可见用户不会少）。而我这个恰好最不怕的就是暴力破解。

[SuperMild]

@Greenm 你说的这些，我知道，但日常使用的加密方法，都加盐。我的意思是“日常使用的常见且有效加密算法，并且采用常见且有效的工作流程（比如加盐），同一个文件每次加密后的密文是不一样的”，我只是懒得说这么长。

我的加密算法是可以泄露的（并且我已经在第一条回复那里泄露了），但我的密码（即 镶嵌方式）是不可以泄露的。

镶嵌方式是密码，而不是算法。

[imn1]

我没能理解好使用场景，包括标题所说的防止网盘扫描
因为现在好像都有更好的方案，你这个略嫌麻烦

[jfcai]

镶嵌方式得记住并且不能泄露，密钥也是得记住并且不能泄露。好象区别不大呀。

[Zhancha]

很不错的思路。

但解密工具里面放了排序方式，其实换种说法，解密工具里面的这个排序方式才是真正的密钥。

所以与你提出的密钥放在密文中有所冲突。

[SuperMild]

@imn1 更好的方案是什么？

我这个由于可以脚本自动化处理，我一般是把散落在不同文件夹里的文件定期自动收集打包、加密、上传，还蛮方便的。

[SuperMild]

@jfcai 密钥通常比较复杂，比如一个密码，至少也得 8 位吧？还不能用生日、电话号码之类的，为了不影响其他账号，不同的账号还需要不同的密码，就不好记。

我这个镶嵌方法可以很简单，很好记。


@Zhancha 啊这……我已经被逻辑绕晕了

[imn1]

@SuperMild #28
那按你这样说的话，你这个方便在一体化自动操作，而不是加密

现在手机有扫码解密，密码箱、保密箱等等，电脑也有拖放密钥文件自动解密，或者从指定路径自动匹配密钥文件解密的工具……等等，基本上都不需要记密码的

我自己也有个脚本，下载文件到特定路径就自动解密（存放路径就相当于密钥），同理也可以做成上传，只是我没有上传需求，就没写了

[SuperMild]

@imn1 谢谢！“下载文件到特定路径就自动解密”这招很不错。

[SuperMild]

我这个方法，还有一个重要原因就是我总是担心密钥会丢，比如硬盘突然坏掉，网盘里的文件也有可能损坏（没遇到过的人可能不理解，我遇到过所以特别没安全感）。

所以我把密钥与密文放在一起，不用保管密钥，不担心弄丢。

[joesonw]

应该是, 一种不需要密码的 混淆 方法（用于防止网盘扫描等场景). 这样别人就不会有疑问了,

[yukiww233]

alias encrypt="zip -P xxxxxx"
alias decrypt="unzip -P xxxxxx"
不如把脚本换成这个

[v2tudnew]

“把钥匙放在门前地毯下”。

[takato]

如果只是为了隐藏信息的话，这类需求记得有个专门的方法：Steganography 。

[Greenm]

@SuperMild #23 你可能对加密和哈希算法的认识和区别也不够清楚， 加盐的是哈希单向算法，加密算法有解密算法的哪有加盐一说？ 哈希算法在这帖里提到的任何场景都不适用。建议你可以再去看下相关原理，这点我不愿意浪费时间解释了。

正规的加密算法，密钥文件+明文+算法 => 密文，拿到密文和公开算法没有密钥是无法解开的。 而你的编码方法导致你的密文和密钥在一起，总是成对出现，导致拿到文件就等于拿到了密文和密钥，只要算法公开就等于没加密。这和编码一模一样啊。

[Greenm]

噢你说镶嵌方法才是密码 /密钥文件是吧，那不就是换汤不换药吗，跟手势解锁有啥区别，你的密钥根本没存在文件里，还是你自己得记住 /存放在别处。 这跟你描述的已经不符了。

而且整体的加密方式强度如何，是需要考量的，你的这个镶嵌方法能够抗住 7 天高运算量的爆破吗？ 是不是还不如普通的强密码？

[SuperMild]

@joesonw 有疑问也好，讨论一下可以增长见识，也有趣。

@yukiww233 大哥，密码要管理，也容易被暴力破解。我这个方法不需要管理密码，也不怕暴力破解。

@v2tudnew 不对，我这个钥匙被截成了 N 块，每一块看起来像普通的石头，混在门前的石头堆了。

[xinghen57]

无意义的尝试，终归会因成本大于收益放弃。
重要的东西别放网盘，这才是真理。