这是一个创建于 1082 天前的主题，其中的信息可能已经有所发展或是发生改变。
安全与便利总是难以兼顾，记忆密码或管理密码，加密或解密时输入密码等操作如果能彻底免除，会非常便利，但是安全性也自然会降低。
幸好，日常生活中有些场景本身就不要求很高的安全规格，只需要稍稍加点防护就足够了。
比如上传到网盘，只要不被轻易扫描、或者万一泄露文件时让人看着一堆乱码不乐意花时间精力去解密，就足够了。
因此，我想到了把密钥直接内嵌到密文里的方法，从此不需要记忆或管理密码，因为密码就在密文里，解密时也不需要填写密码，用脚本自动化提取密码就可以解密了，方便到极致！
当然，该方法只适用于大多数普通文件，不适用于真正的机密。
听起来不靠谱？（原理）
其实很靠谱，因为：
- 一般人根本想不到密码就在密文里
- 就算想到了，也不知道具体位置
- 如果我把一个密钥拆成 3 段，分别镶嵌在不同位置，就更难猜了
- 如果我把密钥拆成 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 文件的编辑也很直观。
第 1 条附言 · 2022-01-12 15:32:47 +08:00
加密是一个有趣的话题，欢迎大家各抒己见。
 |
101
SuperMild OP @cache 你说“等效于把记一个密码变成了记一种编码方式”，
我说 “等效于把记一个复杂密码变成了记一个更简单的密码” 上面也有不少人像你一样说是编码方式，但当我问他们为什么镶嵌方式不是一个密码而是一个编码方式时，他们都不理我了，你能给我说说为什么不是变成一个更简单的密码吗？ |
 |
102
krixaar 2022-01-13 09:04:19 +08:00
只看了标题懒得继续看内容了，之前玩过随机一个字节给文件做 XOR 然后把这个字节附到文件内容最后面的所谓“加密”，问题只是没有任何使用场景……
|
 |
103
neptuno 2022-01-13 09:23:24 +08:00
理论上就是一种编码方式（重要的人用不到，不重要的不需要用你这方法），不过还是谢谢分享
|
|
104
SuperMild OP 是编码还是加密，如果只说结论不讲理由，讨论起来很无趣啊，如果能把理由说出来，是不是更有意义呢？
我先说说我的理由：编码的特征很明显，一对一、一对多、或者多对一，并且通常以一对一映射为主，一个单词编码后就总是一样的字符。同一个文件编码后，通常结果是固定不变的。 如果拿到 10 个采用同一种编码方式处理过的文件，对照着看就很容易看出“有规律”（不是看出规律的具体细节）。 但如果是加密，采用流行的安全的流程处理后，对同一个文件加密也可以让每次加密后的结果都是不一样的无规律的。如果拿到 10 个采用同一种加密算法处理过的文件，对照着看也毫无规律。 而我的这个加密方式，一个破解者拿到一堆加密后的文件对照着看，是看不出有规律的，因此这个破解者会认为这是加密，不是编码。 |
 |
105
cache 2022-01-13 09:43:26 +08:00  2
现代密码学的一个巨大进步就是公开加密算法，所有秘密保存在秘钥上
而你这种方式，密文里包含了秘钥，所有秘密都在加密方式上，那就是一种只依赖于固定算法的编码方式。 这就好比你家大门用了一把非常高级的锁，但你把钥匙藏在门口的地毯下面，那我们讨论安全性的时候跟你用什么锁是没关系的，就是一个藏钥匙的技巧。 另外你为什么觉得这是一种更简单的密码？ 记这么一套解密方式，也不会比记一个 4 位数密码更简单吧？而且你这一开源，变成所有用户共享一个密码，最基本的安全性都没了 |
|
106
SuperMild OP 我再换一个角度讲，如果只是简单地把密码写在文件名里，用文件名作为密码用 AES 加密一个文件，那是加密，不是编码，这应该没有异议吧？
现在我把密码，以明文方式直接连接在密文开头，这与写在文件名没有本质差别吧？还是加密。 那我再把密码插在密文中间，为什么就那么多人说是编码，不是加密了呢？ |
|
107
SuperMild OP @cache 把钥匙藏在门口的地毯下面，当然毫无安全性可言。
但我做的是把钥匙截断几块，每一块看起来就是一块普通的石头，混进门前的石头堆里。 这安全性就比直接放在地毯下高很多，而且就算公开了方法，用户也可以通过改变石头堆里的摆放位置，从而避免共享密码。 一个 4 数的密码，被破解软件秒破；但我这个方法，用流行的破解软件去暴力破解是绝无可能破解的，因为破解者拿到的都不是真正的密文（里面混了密钥）。 |
|
108
SuperMild OP @cache 我现在只需要记住：密钥在密文的第 15 个字符起算，取出密钥后把密钥的前 15 个字符放到末尾。
我觉得记这个很容易，并且我不需要记得很清晰，就算记不清第 15 还是第 14 ，我也能轻松试出来，密钥永远和密文在一起，这让我很安心。而破解者由于不知道密钥就在里面，也毫无头绪如何排列，因此破解很难（选对破解方向就很难）。 而简单密码很容易被破解，常用密码又容易被牵连，如果复杂不常用的密码，又需要管理。 而且我也知道、并且也强调声明多次，不适用于真正的机密，主要用于防网盘扫描。故意降低了安全性（但还是比简单密码更安全），获得了便利性。 |
 |
109
fregie 2022-01-13 10:03:45 +08:00
@SuperMild 请你首先定义加密和编码的区别。
如果一种加密的密钥始终是固定的不能修改，那么这能称之为加密吗？和编码又有什么本质区别？ "知道**密码**没办法解码” 问题是你把密码已经写进内容里了，怎么会不知道？只是**人**没意识到罢了，或者说还没因为不知道编码方式所以不知道密码。 |
 |
110
bung 2022-01-13 10:14:27 +08:00
一种自定义的文件格式。。。
|
 |
111
evgm 2022-01-13 10:16:12 +08:00
只有一台电脑的话，可以根据硬件生成个电脑指纹做密码，然后用脚本自动加密解密
|
|
112
SuperMild OP @fregie 如果用文件名做密码，或者把密码写着文件名里，然后用公认的加密算法来加密这个文件，这是加密，没有异议吧？
现在我把密码，以明文方式直接连接在密文开头，这与写在文件名没有本质差别，还是加密。 那我再把密码插在密文中间，应该还是加密才对啊。 加密与编码的区别，我的看法在大概 104 楼那里写了。 |
|
114
SuperMild OP 如果我用公认加密算法加密一个文件，然后把密码写在文件名，并且花钱全网做广告告诉大家密码就是 123 ，那么这个文件虽然密码公开了，虽然密码很简单，但还是归类为加密，不能归类为编码吧？
那我改成告诉大家密码在密文里，为什么就变成编码了呢？ |
|
115
SuperMild OP 只要密码可以轻易获取，那么一个加密算法就会变成一个编码算法…… 这个说法我不同意。
|
 |
116
glfpes 2022-01-13 10:46:24 +08:00
写了一个脱裤子放屁的东西，被人指出来就嘴硬。
|
|
117
fregie 2022-01-13 11:03:16 +08:00
"用文件名做密码，或者把密码写着文件名里，然后用公认的加密算法来加密这个文件"
这不是加密啊！加密无非也是用密钥加上一定算法编码正文而已，当你的密钥是固定公开的，何来加密？ |
|
118
SuperMild OP |
 |
119
kirisamemarisas 2022-01-13 11:12:25 +08:00
这个算法的保证安全的要点是“密码的位置及其组合规律”。找规律这种问题最大的弊端在于给予的样本数，当样本数充分大的时候，对于机器来说，寻找到规律应该是不难的（这块应该要结合深度学习那块？层主不熟悉那方面的技术。）。
当样本为数为 1 的时候，退化为暴力破解加密文件，当样本数足够多时，转化为深度学习的一种找规律课题。 |
|
121
kirisamemarisas 2022-01-13 11:15:36 +08:00
接上文（手滑发出去了）
因此，这个算法的适用人主要还是取决于使用者能够接受多少文件被放置到非私人场景吧。 给有想法自己实现这种算法的楼主点赞。 |
|
122
glfpes 2022-01-13 11:18:36 +08:00
整个密码九宫格让 OP 乐乐？ why so serious
守序 对称加密 /非对称加密才是有效的加密 中立 不知道领域知识的话，你们解不开 OP 的编码，这也是一种加密（梵语，base64 表示赞同） 混乱 猫叫也是加密 |
|
123
SuperMild OP |
|
124
SuperMild OP |
|
126
krixaar 2022-01-13 11:23:57 +08:00
怎么吵了这么多楼……
咬文嚼字的事儿不重要，重要的是这方法本来存在的目的是不记密码，但需要记流程，你自己发明的流程你当然印象深刻，我要是同时看到多个人的类似方法分享（好比刚才说的我自己之前用的 XOR ，你这个密钥分散，别人再来个密钥是文件名，甚至古典加密都用上），然后脑子抽了不同的时候用了不同的流程处理，到头来想不起来用哪个流程加密的（我要是脑子这么好使我就记住密码了），还得穷举，于是怕自己忘了用了哪个流程，得记加密流程，记下来的加密流程就得存在哪个地方，然后还得保证能记住放在了哪个地方，这个地方得能容灾，明文写下来是不是就不安全了，违背了加密的初衷，于是再想办法加密记下来的加密方法…… 我再给浇点油吧，你这加密就是混淆（ obfuscation ）🤣 |
|
127
SuperMild OP @glfpes 如果破解者拿到 10 份，梵语、base64 、或别的编码算法处理过的文件，这 10 份对照着看，可以看出有某种规律，可以判断是编码而不是算法。
但我这个方法处理过的文件，拿 10 份去对照着看，不能看出任何规律。 这就是我认为编码与加密的不同。 |
|
128
SuperMild OP @glfpes 你说 “你没必要问理由，你只应该承认这玩意就是个编码，然后结束讨论。”
从旁观者看来，你这种态度更像嘴硬。 如果你不喜欢交流，大可拉黑我，这很正常。但你不能对我说：你闭嘴。这很幼稚，因为你明知道你这样很不礼貌，你也没这个权力。 |
 |
129
2i2Re2PLMaDnghL 2022-01-13 11:38:08 +08:00
算力不支持网盘自动破解加密
|
|
130
SuperMild OP @2i2Re2PLMaDnghL 如果只针对短密码、生日、电话号码、常见密码去尝试，算力是足够的，请看隔壁贴的讨论 https://v2ex.com/t/827977 百度网盘会不断升级扫描系统。
|
 |
131
Asvel 2022-01-13 12:32:32 +08:00
@SuperMild 几行关键代码只是举例子，这个记不准那就「 len_of_key=43,len_of_head=15 」，还是记不准那就 md5("43,15")，总不能说只有逻辑记得住其他啥也记不住吧。
重点不在于记住什么，而是你这个加密方法依赖的仍然同样是“记住”，那这个记住的内容本质就是口令（ password ）。 |
|
132
2i2Re2PLMaDnghL 2022-01-13 12:35:15 +08:00
@SuperMild 我记得算出来按现在的网盘上传量，如果对每个文件进行 8 位以内纯数字尝试（包括不同的算法和配置），估计消耗算力在每天 300 亿美元来着？
问题不是实际算力不足，问题是这个预算根本不在合理范围内。杀头的生意有人做，赔本的生意没人做。 |
|
133
SuperMild OP @Asvel 你说本质是记住一个口令，这点我同意，只是每个人的记忆特点不一样。
如果说我做的事是选择了一种适合我的“选择密码并且记住密码”的方式，这样说我完全同意。 也可以说我提供了一种“选择弱口令并且记住弱口令”的方法，我觉得我这种弱口令，比生日、电话号码稍强一点。 记“len_of_key=43,len_of_head=15”这个当然可以，但必须是我真的写了一个这样的脚本，这句代码才会有意义，才会变得容易记而不是一句随手写的代码，因此，本质上还是需要做写脚本镶嵌密钥这件事，这是记忆的基础。 |
|
134
SuperMild OP @2i2Re2PLMaDnghL 想到了一个类比
假设我有一个女朋友，假设她的生日是 8 月 27 日，我基于这个假设去记忆 8.27 这个日期，我觉得不好记。 而如果我真的有一个女朋友，她的生日真的是 8.27 ，并且我还陪她过过生日，那我就会觉得这个日期好记多了。 这是我的记忆特点，也许别人不一样。 |
|
135
SuperMild OP @2i2Re2PLMaDnghL 如果一个扫描系统不断积极地升级改善，那么我就有理由相信，当它发现一些用户总是上传加密文件上来时，会特别“关照”这些用户，因为这是“可疑”用户，数量也不多，特别关照他们不需要太高成本。
一个不断积极地升级改善的扫描系统，其背后的开发人员显然有奖惩机制，才会让他们积极工作，而既然有奖惩，他们自然会在成本可控的前提下想方设法建立功劳。 |
|
136
fregie 2022-01-13 14:13:34 +08:00
@SuperMild "镶嵌方式是可以有很多种变化"
这当然不算加密，如果你没公开你的镶嵌方式，那就是其他人因为不知道编码方式而不能解码的编码，如果你公开了你的镶嵌方式，那么其他人可以随时解码。 反观加密，任何加密算法本身的逻辑和算法都是公开，但是每个人在这个前提下，因为可以用只有自己知道的密钥而完成加密不让别人知道。 如果你打算通过不公开编码方式而达到加密的效果，是可行的，但并不代表你这种算法就是属于加密算法了。 说白了你这就属于“把编码方式作为密钥不公开而达到加密效果的编码” 关键就在于你公不公开你的逻辑，不公开自己用的话，就没必要在这里跟大家分享了，公开的话，它就不能加密了。 |
|
137
SuperMild OP @fregie 你和我的主要分歧，与上面一些人一样，主要集中于一个问题：镶嵌方式是一种编码方式，还是一个密码。
你说 “如果没公开镶嵌方式，其他人因不知道**编码方式**而不能解码” 但我可以说 “如果没有公开镶嵌方式，其他人因不知道**密码**而不能解密”，我们只是各执一词，你并没有提供更多理由来支持“镶嵌方式不属于密码，而属于编码方式”这个说法。 我的加密算法也是公开的（ cryptography.Fernet ），我把密钥镶嵌在密文里，比如分三段，依次镶嵌在原密文的第 3 、5 、7 个位置，等效于一个密码：Split-3-into-357 。我只是把原来复杂的密钥转换为这样一个简单的密码，加密过程用的依然是公认的加密算法。 ---- 重点：加密后的密文，即使被拿到多份一起对比，依然看起来是无规律的加密，而不是有规律的编码。（这点很重要，请务必重视）---- 另外，你还没正面回答这个问题：如果我宣布密码可能是我的生日、也可能是我的电话号码，也可能是 123 abc 之类的简单密码，这种情况下，密钥不是固定的，那你认为算不算加密呢？ （因为这个假设的情形与我把密钥插进密文，本质上是一样的。如果你觉得在这个假设里，你很难说出“那不属于加密，而是属于编码”，那么，也许我的这个方法，也并非那么轻易就能被断定为编码吧） |
|
138
SuperMild OP @fregie 我又想到了一个理由来支持我的说法
上面有人说，用生日日期来做种子，生成密钥后拿去用。貌似大家都不会质疑这是编码还是加密。 那我现在只是类似于用镶嵌方式做种子，用这个种子可以找出真正的密钥。 |
|
139
SuperMild OP 我认为最终判断这是一种编码还是加密，对于结果我不是很在乎，但我希望有人认同这至少需要讨论之后才能渐渐弄清楚，而不是一眼就能看出来的事情。
我觉得一部分人下判断太快了，看起来好像判断与结果很重要，输赢很重要，讨论过程不重要。而我更看着讨论过程。 |
|
140
fregie 2022-01-13 16:17:42 +08:00 1
@SuperMild 可以的，只要你永远不公开你的脚本，永远也没人能破解的出来，但是也永远只能你一个人用，这能算是加密。但是这有什么意义呢，不公开的话何必在这里讨论呢？难道要让大家都自己写一个脚本来自己加解密吗？随便找一种别的加密算法保存一个密钥永远不公开不是一样的。
|
 |
142
hanguofu 2022-01-13 21:59:23 +08:00 via Android
我也觉得楼主的方法其实就是用另一种方式记下密钥。谢谢分享！
|
|
143
2i2Re2PLMaDnghL 2022-01-13 22:23:34 +08:00
@SuperMild 那么，资本家到底是出于什么目的去扫描这些用户的呢？
杀头的生意有人做，赔本的生意没人做。 |
 |
144
WuSiYu 2022-01-14 06:25:00 +08:00 via iPhone
其实和普通加密且把秘钥硬编码在程序里没区别，如果要“加密”后没次都不一样的话，加密时随便加点额外的随机数据就行了
|
|
145
SuperMild OP @WuSiYu 把密钥硬写在程序里，就要保管密钥，或者要担心这个程序丢失。
而我这个做法，最主要的目的之一是完全不管密钥，我写的这个程序也不怕丢失，我只需要记得密钥镶嵌方式即可，而镶嵌方式比密码好记很多（举个例子：密钥在密文的第 15 个字符起算，取出密钥后把密钥的前 15 个字符放到末尾。只要我记得这个大概的逻辑，就算忘记了具体是 15 ，也能轻松破解，但陌生人拿到我的密文，就极难破解。） 也就是说，密钥永远和密文在一起，我记得镶嵌方式的大概逻辑，我就有信心破解它，从此我只需要用这个程序加密、解密，过程中不需要输入密码，也不需要管理密钥，便利且安心。 |
 |
146
lisongeee 2022-01-14 10:30:41 +08:00
我都是直接用 zip 加密，然后把密码写在文件名上
|
|
147
SuperMild OP |
 |
148
llh880808 2022-01-14 18:14:06 +08:00
用楼上 zip 加密+文件名的方案稍加优化, 比如文件名逆序作为密码, 或者文件名的一部分作为密码, 或者固定前缀+文件名才是密码, 这个前缀可以很短很好记, 这样的方案安全性不会输给你吧, 而且便利性更好
|
|
149
SuperMild OP @llh880808 文件名太容易不小心修改了，而且也有必须修改文件名的场景。
举个例子，我自己在上传文件到对象储存时，由于对象储存对“用文件名的开头来检索”进行了优化，我会让上传程序自动添加一些前缀到文件名。 有时也会添加标签到文件名帮助搜索。另外我也有别的情况会改文件名，就不一一列举了。 |
 |
150
lucybenz 2022-01-17 09:38:51 +08:00
思路可行，1 、创建一种自解压的压缩格式，然后使用密码压缩，压缩时把密码按特定规则附加到压缩文件中；
2 、分享给他人时，对方使用自解压，需要输入密码； 3 、你自用时使用专用解压软件，无需输入密码自动解压，你也可以随时用自己的专用软件读取压缩包密码，分享给他人； |
 |
151
yesterday17 2022-01-18 00:21:52 +08:00
镶嵌从个人角度来看确实是更倾向于编码，但编码又何尝不是一种古典密码呢（笑）
|
|
152
SuperMild OP @yesterday17 用生日日期作为种子算出密钥，这一步不是加密，但用这个密钥加密没人质疑是编码。
而我把密钥镶嵌到密文里，这一步当然不是加密，但从整体上看，有两个特征： 1. 比用生日日期 /电话号码作为种子更安全 2. 仅从密文看，多份密文无法相互对照，没有普通编码的缺点，对于解密者来说只能当作普通加密来破解。 |
 |
153
gugu33 2022-01-27 05:54:14 +08:00 via iPhone
加密和编码同源而异途罢了。 原文变密文，通俗讲就是给原文套壳。op 新造个轮子自用不公开，在别人眼里这文件就是个未知格式。算法就是你的脚本，密码就是 15 ，没有这两样当然不好破。不过你现在公开了脚本思路了，密码也不可能用太复杂的， 我想度盘扫描模块程序员也已经关注到了
|
Select Language