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

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

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

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

@qwe520liao 差别很大。

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

这三点很关键啊。

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

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


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

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

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

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


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