@Greenm 我很好奇，如果让你写一个暴力破解算法，你有什么思路？

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



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

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

但如果我做的是加密，拿到 10 个按同一种加密方式处理过的文件，也是无法相互印证的，看不出规律来。

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

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

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

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

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

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

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

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


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

@imn1 更好的方案是什么？

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

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

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

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

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

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

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

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

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

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

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

@Building 我这个是能防暴力破解的，你看看我说的对不对：

1. 我用的是 32 bytes 的随机密钥，这么长的密钥，而且每次加密都采用不一样的密钥，这个暴力破解要多长时间？

2. 我把密钥分成几段镶嵌进密文里了，也就是说，即使知道密钥，直接去解这个密文也是解不开的，还需要知道密钥的镶嵌方式，把密钥与密文分离开，才能获得真正的密文。

@3dwelcome 这样也是个好办法，但我可能会想，生日也太简单太容易被猜了，电话号码显然也容易被猜，我会有这个纠结，会想用一个特殊点的种子，而一旦特殊，就很容易忘记，结果还是要管理。

但你这个方法确实是好，不纠结的人可以用。

@joesonw 我正文两次强调 “不适用于真正的机密”，标题也说明了主要用途。

日常大多数文件这样处理已经足够安全了（吧？）

@qwe520liao 差别很大。

1. 对于同一个文件，加密后的密文，每次都不一样；编码后的“密文”，每次都是固定不变的。
2. 被人拿到一堆“密文”，如果这一堆都是编码弄出来的，很容易看出规律；而如果是加密，则很难从密文看出规律。
3. 自创编码方式，程序代码复杂，需要保护好程序，不能泄露，也不能丢失。而我用的是真加密，不用自己想如何编码，也不怕程序丢失。

这三点很关键啊。

@FakNoCNName 据我理解，加密了，哈希值就变了。

你可能看错了，我这个是**真**加密啊，唯一与普通高强度加密不同的只是把密钥镶嵌进密文里而已。


@chengkai1853 对……被你一阵见血了，这确实是最大的问题。但也不算很严重的问题，由于明确用于保密等级低的文件，镶嵌方式可以弄得简单一点，只是记住镶嵌方式还是很容易的。不需要保存脚本，只需要记住镶嵌方式。

@polaa 随便使用一个密钥，有 3 个问题：

1. 就要考虑密钥放在哪里。
2. 备份密钥时要考虑如何保护私钥。
3. 还需要记住哪些文件用了这个“低安全级别”密钥，哪些文件用了用了“高安全级别”（即平时用来加密重要文件）的密钥。

而采用我这个方案，一切都不需要考虑，一个命令就加密 /解密，密码永远不用管理。


@Mohanson 这也是个好办法，但缺点是花样比较少，上面有人提到别人使用同一个脚本来加密的情况，我这个可以非常方便地改变镶嵌方式，轻松地防止与别人使用一样的方式。

@a1105288116 那肯定的，但要考虑两点：1.极少人用我这个脚本 2.可以修改镶嵌方式。

@1423 但是查看 rar 备注很容易，猜我的镶嵌方式却很麻烦。查康 rar 备注是个很容易想到的做法，猜密钥镶嵌在密文里则是很可能想都没想到这个方向（只要不是被特殊针对）

忘了说，加密方法是流行的 cryptography.Fernet, 并不是啥特殊格式，不需要用我的脚本也是能解密的。

我做过一个小软件，完全符合你的需求（简直一模一样）

https://github.com/users/ahui2016/projects/1

虽然这个项目我已经停止维护了，但应该还能用的，最后一次更新是去年 7 月。以后我很可能还会做类似的软件，毕竟我自己也有这个需求。

@emberzhang 更改数据库位置的功能做好了，还新增了一个随机显示格言 /座右铭的功能。