@qwe520liao “不要自己去发明加密系统” 这个道理我懂，如果我搞了这一套，然后我声称这一套很安全，是强加密，那我才是你说的那种情况。

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

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

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

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

@ganbuliao “理论上来说，是编解码器”，你这里说的理论，具体是什么理论呢？

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

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

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

采用简单密码的加密，还是加密啊。

@momocraft 用生日 hash 也很好，其实直接用生日日期也行，不需要 hash 。

但我这个方法也不见得很差吧，也没比生日 hash 差啊。

@FakNoCNName 原来如此，但我这个不用于分享，而且我把密钥插进密文里，理论上已经变成另一个文件了，大概能防住一点吧。

@xinghen57

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

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

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

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

但如果采用我的方法加密了，这个加密过程很轻松，既能防止被扫描，万一网盘泄露也没有人专门针对一份加密文件去破解，可以说我的目的达到了，成本也不高。

@fregie 补充说明一下为什么我认为能不能“看出有规律”是重要的，因为看出有规律，就可以初步判断采用了编码而不是加密，接下来的解密方式就不一样了。

对于加密过的文件，通常会考虑彩虹表之类的暴力破解。而对于编码，则会尝试各种常见的 bit 操作，或者找其中的相同区块，编码处理通常会产生很多相同区块。

@fregie 你说 不知道**编码方式**没办法解码，知道编码方式无成本解码。

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

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

另外，你能说出一种编码方式是不容易被看出有规律的吗？（我是指看出有规律，而不是指看出这个规律的细节）

@xinghen57 非常同意重要东西不放网盘，我现在主要用网盘来临时存放一些文件，然后我会定期保存到本地多个机械硬盘里，就把网上的删了。

但我不同意你说成本大，这个加密脚本很容易写的。

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

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