这是一个创建于 1081 天前的主题，其中的信息可能已经有所发展或是发生改变。
安全与便利总是难以兼顾，记忆密码或管理密码，加密或解密时输入密码等操作如果能彻底免除，会非常便利，但是安全性也自然会降低。
幸好，日常生活中有些场景本身就不要求很高的安全规格，只需要稍稍加点防护就足够了。
比如上传到网盘，只要不被轻易扫描、或者万一泄露文件时让人看着一堆乱码不乐意花时间精力去解密，就足够了。
因此，我想到了把密钥直接内嵌到密文里的方法，从此不需要记忆或管理密码，因为密码就在密文里，解密时也不需要填写密码，用脚本自动化提取密码就可以解密了，方便到极致！
当然，该方法只适用于大多数普通文件，不适用于真正的机密。
听起来不靠谱？（原理）
其实很靠谱，因为：
- 一般人根本想不到密码就在密文里
- 就算想到了，也不知道具体位置
- 如果我把一个密钥拆成 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
加密是一个有趣的话题，欢迎大家各抒己见。
 |
1
SuperMild OP 忘了说，加密方法是流行的 cryptography.Fernet, 并不是啥特殊格式，不需要用我的脚本也是能解密的。
|
 |
2
a1105288116 2022-01-12 13:02:34 +08:00 via iPhone
如果别人用同一个脚本是不是也能解开呢？
|
 |
3
1423 2022-01-12 13:09:49 +08:00 via iPhone  1
rar 可以添加备注。备注可以是密码
|
 |
4
polaa 2022-01-12 13:31:18 +08:00
无论什么场景 。。。。随便使用一个密钥进行加密不比你这靠谱？
|
 |
5
Mohanson 2022-01-12 13:37:34 +08:00
文件每个 byte 按位取反就可以了, 我都是这么干的...
|
|
6
SuperMild OP @a1105288116 那肯定的，但要考虑两点：1.极少人用我这个脚本 2.可以修改镶嵌方式。
@1423 但是查看 rar 备注很容易，猜我的镶嵌方式却很麻烦。查康 rar 备注是个很容易想到的做法，猜密钥镶嵌在密文里则是很可能想都没想到这个方向（只要不是被特殊针对） |
|
7
SuperMild OP |
 |
8
FakNoCNName 2022-01-12 14:19:33 +08:00
过不了网盘的哈希校验
|
 |
9
chengkai1853 2022-01-12 14:23:05 +08:00 4
你这不就类似于把密码写死在加密函数函数里面了嚒。既然小众，那意思就是要好好保存这个加解密脚本，如果脚本找不到了，咱也无法解开了。这和保存密钥貌似没有本质的区别吧？
|
 |
10
timethinker 2022-01-12 14:29:02 +08:00 18
加密 /解密 ✗
编码 /解码 ✔ |
|
11
SuperMild OP @FakNoCNName 据我理解，加密了，哈希值就变了。
你可能看错了，我这个是**真**加密啊，唯一与普通高强度加密不同的只是把密钥镶嵌进密文里而已。 @chengkai1853 对……被你一阵见血了，这确实是最大的问题。但也不算很严重的问题，由于明确用于保密等级低的文件，镶嵌方式可以弄得简单一点，只是记住镶嵌方式还是很容易的。不需要保存脚本，只需要记住镶嵌方式。 |
 |
12
joesonw 2022-01-12 14:35:08 +08:00
encryption by obstruction
|
 |
13
3dwelcome 2022-01-12 14:35:16 +08:00
|
|
14
SuperMild OP @qwe520liao 差别很大。
1. 对于同一个文件，加密后的密文，每次都不一样；编码后的“密文”，每次都是固定不变的。 2. 被人拿到一堆“密文”，如果这一堆都是编码弄出来的，很容易看出规律；而如果是加密，则很难从密文看出规律。 3. 自创编码方式，程序代码复杂，需要保护好程序，不能泄露，也不能丢失。而我用的是真加密，不用自己想如何编码，也不怕程序丢失。 这三点很关键啊。 |
|
15
SuperMild OP |
|
16
SuperMild OP @3dwelcome 这样也是个好办法，但我可能会想，生日也太简单太容易被猜了，电话号码显然也容易被猜，我会有这个纠结，会想用一个特殊点的种子，而一旦特殊，就很容易忘记，结果还是要管理。
但你这个方法确实是好，不纠结的人可以用。 |
 |
17
Building 2022-01-12 14:49:31 +08:00 via iPhone
谁管你密码是谁谁谁生日放什么地方什么高级密钥算法，直接暴力破解完事……
|
|
18
SuperMild OP @Building 我这个是能防暴力破解的，你看看我说的对不对：
1. 我用的是 32 bytes 的随机密钥，这么长的密钥，而且每次加密都采用不一样的密钥，这个暴力破解要多长时间？ 2. 我把密钥分成几段镶嵌进密文里了，也就是说，即使知道密钥，直接去解这个密文也是解不开的，还需要知道密钥的镶嵌方式，把密钥与密文分离开，才能获得真正的密文。 |
 |
19
vophan1ee 2022-01-12 15:04:38 +08:00
你这就是一种自己知道的编码呗，也谈不上什么加密，我把文件所有位都 +1 ，只要别人不知道，效果就是一样的
|
 |
20
jupiter157 2022-01-12 15:12:25 +08:00 via iPhone
怎么区分加密人和其他人？那就是密钥信息，这个密钥不一定是字符串，也可能是规则，如怎么组合、怎么编码、在哪个位置找到密码、密码本是什么。规则的好处是没发穷举，但本质上和字符串密码没有不同。
|
|
21
SuperMild OP @vophan1ee 上面有人说过取反、编码、以及你说的+N ，安全程度应该比我这个方法稍差一点点。
改 bit 有个很大的问题：破解者只需要截取一小段（不需要整个文件）就可以暴力尝试各种改 bit 方式，由于截取很短的密文即可，破解速度可以很快。 简而言之，我现在这个方法在安全性与便利性之间平衡得比较好。 |
 |
22
Greenm 2022-01-12 15:20:55 +08:00 4
你对加密和编码的理解不对：
1. 对于同一个文件，加密后的密文，每次都不一样；编码后的“密文”，每次都是固定不变的。 > 对于加密算法来说，同样的密钥和算法对同样的输入，都一定能得到同样的输出内容，这就是正经的加密算法。编码其实也是一样的。 所以这并不能算做加密与编码的区别。 其实编码和加密的主要区别就是加密 /编码的算法是不是怕第三方知道。 如果第三方知道了算法就能从密文解出明文，这样的我们就倾向于是编码，否则就是加密。 可以参考古典加密算法，他们的共同点都是不能泄露加密算法，一旦泄露就失去加密效果，所以古典加密在现代计算机密码学范畴内，基本不能算做加密算法了，只能叫做编码。 楼主你的更倾向于编码，换句话说，非标准 base64/base72 等等编码对于不知道算法的人来说也可以起到加密的效果。 |
|
23
SuperMild OP @jupiter157 区分加密人和其他人？这个问题没看懂。
镶嵌规则可以很简单，而破解的人一般只会想到暴力破解之类的。 想象一下，你拿到一个密文，不知道加密方法，会不会想 “密钥可能分成了 N 段，并且调换了其中几段的位置，镶嵌在密文中的 N 个位置里”，不会这样想，就算想到了这个，也不乐意花精力去破解。 但是，一般人却很有可能会尝试暴力破解（网上暴力破解工具一大堆，可见用户不会少）。而我这个恰好最不怕的就是暴力破解。 |
|
24
SuperMild OP @Greenm 你说的这些，我知道，但日常使用的加密方法，都加盐。我的意思是“日常使用的常见且有效加密算法，并且采用常见且有效的工作流程（比如加盐），同一个文件每次加密后的密文是不一样的”，我只是懒得说这么长。
我的加密算法是可以泄露的（并且我已经在第一条回复那里泄露了），但我的密码（即 镶嵌方式）是不可以泄露的。 镶嵌方式是密码，而不是算法。 |
 |
25
imn1 2022-01-12 15:51:42 +08:00
我没能理解好使用场景，包括标题所说的防止网盘扫描
因为现在好像都有更好的方案，你这个略嫌麻烦 |
 |
26
jfcai 2022-01-12 15:51:57 +08:00
镶嵌方式得记住并且不能泄露，密钥也是得记住并且不能泄露。好象区别不大呀。
|
 |
27
Zhancha 2022-01-12 15:57:53 +08:00 3
很不错的思路。
但解密工具里面放了排序方式，其实换种说法，解密工具里面的这个排序方式才是真正的密钥。 所以与你提出的密钥放在密文中有所冲突。 |
|
28
SuperMild OP |
|
29
SuperMild OP |
|
30
imn1 2022-01-12 16:16:24 +08:00 2
@SuperMild #28
那按你这样说的话，你这个方便在一体化自动操作，而不是加密 现在手机有扫码解密，密码箱、保密箱等等，电脑也有拖放密钥文件自动解密，或者从指定路径自动匹配密钥文件解密的工具……等等，基本上都不需要记密码的 我自己也有个脚本，下载文件到特定路径就自动解密（存放路径就相当于密钥），同理也可以做成上传，只是我没有上传需求，就没写了 |
|
32
SuperMild OP 我这个方法，还有一个重要原因就是我总是担心密钥会丢，比如硬盘突然坏掉，网盘里的文件也有可能损坏（没遇到过的人可能不理解，我遇到过所以特别没安全感）。
所以我把密钥与密文放在一起，不用保管密钥，不担心弄丢。 |
|
33
joesonw 2022-01-12 16:32:21 +08:00
应该是, 一种不需要密码的 混淆 方法（用于防止网盘扫描等场景). 这样别人就不会有疑问了,
|
 |
34
yukiww233 2022-01-12 16:43:01 +08:00 4
alias encrypt="zip -P xxxxxx"
alias decrypt="unzip -P xxxxxx" 不如把脚本换成这个 |
 |
35
v2tudnew 2022-01-12 16:44:52 +08:00 2
“把钥匙放在门前地毯下”。
|
 |
36
takato 2022-01-12 16:45:24 +08:00
如果只是为了隐藏信息的话，这类需求记得有个专门的方法：Steganography 。
|
|
37
Greenm 2022-01-12 16:48:00 +08:00 1
@SuperMild #23 你可能对加密和哈希算法的认识和区别也不够清楚， 加盐的是哈希单向算法，加密算法有解密算法的哪有加盐一说？ 哈希算法在这帖里提到的任何场景都不适用。建议你可以再去看下相关原理，这点我不愿意浪费时间解释了。
正规的加密算法，密钥文件+明文+算法 => 密文，拿到密文和公开算法没有密钥是无法解开的。 而你的编码方法导致你的密文和密钥在一起，总是成对出现，导致拿到文件就等于拿到了密文和密钥，只要算法公开就等于没加密。这和编码一模一样啊。 |
|
38
Greenm 2022-01-12 16:52:40 +08:00
噢你说镶嵌方法才是密码 /密钥文件是吧，那不就是换汤不换药吗，跟手势解锁有啥区别，你的密钥根本没存在文件里，还是你自己得记住 /存放在别处。 这跟你描述的已经不符了。
而且整体的加密方式强度如何，是需要考量的，你的这个镶嵌方法能够抗住 7 天高运算量的爆破吗？ 是不是还不如普通的强密码？ |
|
39
SuperMild OP |
 |
40
xinghen57 2022-01-12 17:05:46 +08:00 via iPhone
无意义的尝试，终归会因成本大于收益放弃。
重要的东西别放网盘，这才是真理。 |
 |
41
vangjing 2022-01-12 17:09:34 +08:00 1
上面一堆人谈是加密解决还是编码解码，忘了自己要达成什么目的
“日常生活中有些场景本身就不要求很高的安全规格，只需要稍稍加点防护就足够了。 比如上传到网盘，只要不被轻易扫描、或者万一泄露文件时让人看着一堆乱码不乐意花时间精力去解密，就足够了。” 我的方法很简单，文件名[密码].7z ，密码可以是真正的密码，也可以是密码的一部分，看文件保密程度。 |
|
42
SuperMild OP @Greenm 我很好奇，如果让你写一个暴力破解算法，你有什么思路？
网上已有的别人写好的暴力破解程序，是绝对破解不了我这个密文的，因为需要先把真正的密文分离出来。 另外，我们的分歧可能集中在一点：镶嵌方式是加密算法，还是密码？ 我的看法是，镶嵌方式是密码，而不是算法。理由是：如果我做的是编码，那么一个人拿了 10 个按同一种编码方式处理过的文件，是能轻易看出规律来的，这 10 个文件可以相互印证。 但如果我做的是加密，拿到 10 个按同一种加密方式处理过的文件，也是无法相互印证的，看不出规律来。 |
|
43
SuperMild OP |
 |
44
eason1874 2022-01-12 17:29:09 +08:00 1
我用 AES 分组密码模式，IV 放在文件开头，然后把 IV 反转编码成 Base64 再取 UTF-8 字节作为密钥，然后加密，效果也一样，不用记密码，不知道代码的人只看密文也不知道怎么解
只靠代码保密来加密，相当于只有一个密钥，代码就是密钥本身。如果要保存代码，那跟把密钥写死在代码里没分别。如果不保存代码，靠记代码思路，那跟记一个密钥明文没分别 |
 |
45
fregie 2022-01-12 17:31:06 +08:00
别讨论了，就是等效于编码。
不知道编码方式没办法解码，知道编码方式无成本解码。 你说你能看出相同方式编码文件的规律，如果是适用于任何编码方式的话，我觉得你的大脑计算能力已经超出人类的的范畴了。 |
|
46
SuperMild OP @fregie 你说 不知道**编码方式**没办法解码，知道编码方式无成本解码。
我说 不知道**密码**没办法解码，知道密码无成本解码。 都说得通，你能说说你认为镶嵌方式是加密算法而不是密码的理由吗？ 另外，你能说出一种编码方式是不容易被看出有规律的吗？（我是指看出有规律，而不是指看出这个规律的细节） |
|
47
SuperMild OP @fregie 补充说明一下为什么我认为能不能“看出有规律”是重要的，因为看出有规律，就可以初步判断采用了编码而不是加密，接下来的解密方式就不一样了。
对于加密过的文件，通常会考虑彩虹表之类的暴力破解。而对于编码，则会尝试各种常见的 bit 操作，或者找其中的相同区块，编码处理通常会产生很多相同区块。 |
|
48
xinghen57 2022-01-12 17:56:34 +08:00 via iPhone 1
@SuperMild 首先，我不是搞密码的，所以不会从纯技术角度考虑这事。其他如下：
成本我能想到的有这么几方面： 1 、如何保证自己使用的系统整体环境安全？或者能确定只在自己信任的系统下使用？ 2 、文件加解密开销。 3 、定期更换密钥、储存位置的记录、应用等开销。 不想网盘扫描，不必这么麻烦。 不想让人看的，你是指网盘内容被泄露？这在网盘行业是大新闻，没哪家公司会主动做的。当然配合有关部门除外。 我个人理解，数据从产生后存储、传输到传播，除非全部安全可控，不然基于木桶原理，总会取决于最短板。 你这种方式，存网盘是整个流程最薄弱的环节。 这环境脱离你的掌控，如果真存在私人网盘内容被可以泄露的情况，你存的内容被破解只是时间问题和你本身重要性问题。 或者你的解密算法强到在密码领域无人能破解？ 与其专注于加密算法，我更倾向使用行业认可的加密算法，把精力放在存储、传输传播等方面。 因此，综合对比下，我觉得你这方式就不合适了。 你这么做，只有成本。这既不能带来收入的增加，也不能提高效率。有的只是幸存者偏差下的安全。 |
|
49
FakNoCNName 2022-01-12 17:59:47 +08:00
|
 |
50
crab 2022-01-12 18:06:21 +08:00
之前把移动硬盘的 XX 视频异或文件头防止误触发直接播放。
|
 |
51
momocraft 2022-01-12 18:10:52 +08:00
wq
|
|
52
SuperMild OP @xinghen57
你说的很有道理，我基本同意（只是关于成本与收益部分不太同意）。 其实我做这个，主要是用来处理临时文件的，因为现在不怎么用 U 盘，而且在外出差之类的时候使用 U 盘、移动硬盘也容易弄丢，我就加密后上传到网盘，大概几天之内等我本地备份好，或者改用冷储存之后，就删除网盘里的临时文件。 网盘泄露我是亲自见证过的，不是我的资料泄露，是某网盘发生了大型泄露，我按照网上流传的方法去看了很多陌生人的照片、视频。 而且，我怀疑他们内部也会有人工抽检，会有人去看用户的资料，比如 OCR 扫描图片发现敏感词时，会不会有人工抽检复核？（这个只是怀疑，没有依据） 但如果采用我的方法加密了，这个加密过程很轻松，既能防止被扫描，万一网盘泄露也没有人专门针对一份加密文件去破解，可以说我的目的达到了，成本也不高。 |
|
53
SuperMild OP @FakNoCNName 原来如此，但我这个不用于分享，而且我把密钥插进密文里，理论上已经变成另一个文件了，大概能防住一点吧。
|
|
54
momocraft 2022-01-12 18:16:36 +08:00
在网盘这个用途上
用自己生辰 hash 当密码同样不需要管理, 而且 (在不泄漏具体 hash 函数时) 不怕暴力破解 更重要是不用骗自己 |
 |
55
ganbuliao 2022-01-12 18:19:56 +08:00 1
理论上来说，是编解码器吧，自己用是没有人知道的编解码器。开源了用的人少就是，小众编解码器。用的人多了，新的文件格式。
|
|
56
SuperMild OP |
|
57
timethinker 2022-01-12 18:27:43 +08:00 2
我还记得之前 github 收费的时候，就有人尝试使用公开仓库来当作网盘使用，甚至还为此开发除了一套自动化的脚本程序，push/pull 的时候自动本地加密 /解密。使用过程中无感，只需要配置一个密钥即可，当然那个时候的限速还没有现在这么严重。Windows 平台也有很多在驱动层实现的透明加密软件。
所以如果只是想要文件在落地的时候进行加密，防止其他人直接绕过系统得到原始数据，完全可以采用一些比较成熟的方案，而且安全性是比较高的。记得很久以前在学习安全这一块的时候，给我印象最深的一句话就是“不要自己去发明加密系统，除非你是从事这个行业的专家”。 当然了，如果只是为了绕过一些自动化的扫描，也完全可以使用压缩软件+密码的形式。不管做什么，明智的做法应当是尽快找到一种正确的方式好让自己别把时间浪费在本不应该浪费的事情上面。 |
|
58
SuperMild OP @ganbuliao “理论上来说，是编解码器”，你这里说的理论，具体是什么理论呢？
我真的认为镶嵌方式是密码，而不是加密算法，上面有不少人说我的是编码，但也没人说出很硬的道理来。 第一步，用 cryptography.Fernet 加密，这一步是加密大家应该都同意 第二步，把密钥插入密文的某个位置，这一步，为什么就让整个过程变成编码了呢？ 我的看法是，第二步只是把一个长的、复杂的密码换成一个短的简单的密码。 采用简单密码的加密，还是加密啊。 |
 |
59
des 2022-01-12 18:38:38 +08:00 via iPhone
无法理解……你这样玩，不变相脚本等于密码？
真想不用密码，建议 gpg 软件公开容易获取，安装也方便，加密完全不需要用到密码 |
|
60
SuperMild OP @qwe520liao “不要自己去发明加密系统” 这个道理我懂，如果我搞了这一套，然后我声称这一套很安全，是强加密，那我才是你说的那种情况。
但我知道这套方法的有缺点，并且强调了不适用于真正的机密，很明显不是自己发明加密了。 我是故意降低一点安全性，换取更高的便利性。 成熟的方案我也知道，但成熟的方案都需要管理私钥、保管私钥，我就是不想保管这个，我在这个地方故意降低了安全性，但我也确实获得了便利：不需要管理私钥。 然后，我把它用于中等安全要求的场景，就很合适，便利与安全有一个平衡。 |
|
61
SuperMild OP |
 |
64
NeezerGu 2022-01-12 18:44:45 +08:00
成本太高了， 觉得国内的网盘不靠谱用国外的就是了。。
都信不过上 nas 就行 |
|
65
SuperMild OP |
|
66
des 2022-01-12 18:47:46 +08:00 via iPhone
加密脚本凭什么就不怕丢了？
你放哪里？放 github 吗？ |
|
67
timethinker 2022-01-12 18:49:16 +08:00
@SuperMild 思路值得鼓励，希望你可以一直对此保持热情。
|
|
68
des 2022-01-12 18:51:36 +08:00 via iPhone
还是想说丢了能重新写？那和记密码有什么区别？甚至把私钥 zip 加个密码都比你这安全
现有工具甚至还有直接挂载一系列功能，你这个有啥？ |
|
69
SuperMild OP |
|
70
des 2022-01-12 18:54:13 +08:00 via iPhone
要是为了备份，可以看看 Borg 。都是现成的，说不定正好满足你的需要
可以挂载，去重，多版本，文件切片 |
|
71
SuperMild OP |
|
72
des 2022-01-12 18:57:03 +08:00 via iPhone
@SuperMild 脚本不一样能丢？到时候你还能记得你写的啥？
多少人吐槽自己以前的代码看不懂，那还是有代码，真不信你能记得了。你要能记这个，记个密码，背个私钥算啥？ |
 |
73
Mutoo 2022-01-12 18:57:11 +08:00 via iPhone
这个和把钥匙放在家门口的花瓶底下有异曲同工之处。
|
 |
74
zhy0216 2022-01-12 19:00:22 +08:00
|
|
75
des 2022-01-12 19:01:00 +08:00 via iPhone
|
|
76
des 2022-01-12 19:03:12 +08:00 via iPhone
如果有一堆文件要加密呢？想要文件名加密呢？
|
|
77
des 2022-01-12 19:05:06 +08:00 via iPhone
当然这些都可以自己写，就看你觉得这能不能便利到你自己了
|
|
78
SuperMild OP |
|
79
des 2022-01-12 19:12:36 +08:00 via iPhone
那我只能说，但愿你多年后还记得吧。
|
|
80
SuperMild OP |
 |
82
wooyuntest 2022-01-12 19:30:20 +08:00
使用 gpg ，密钥使用 yubikey 等 gpg 智能卡管理。
|
|
83
xinghen57 2022-01-12 19:48:20 +08:00 via iPhone
@SuperMild 买个 vps ，做个 vpn 连家里 nas 。
8M 带宽腾讯轻量云 3 年不到 200 。 |
|
84
xinghen57 2022-01-12 19:53:51 +08:00 via iPhone
@SuperMild 网盘不可信。所以别存。
泄露只是一方面，你没法知道他们对加密内容的处理。 如果泄漏可以，做彩虹表卖钱有啥不可？如果有关部门有需求，很多你以为不会做的其实也会做的。 其实，大部分你觉得重要的都没那么重要。真正重要的，比如银行卡密码之类的东西。 换个思路，你用国外的如 Dropbox ，即便泄漏，如果没法对你产生影响，也无所谓。 |
 |
85
keith1126 2022-01-12 21:36:59 +08:00 1
这个帖子读下来，再次印证了密码学是一个不适合自己造轮子的领域。
|
 |
86
msg7086 2022-01-12 21:45:42 +08:00
试过用文件名本身作密码吗？
|
|
87
SuperMild OP |
|
88
msg7086 2022-01-12 22:09:00 +08:00
|
 |
89
parametrix 2022-01-12 22:21:57 +08:00 2
这样做的话，真正的密钥实际上就是原密钥拆分的方法以及镶嵌的位置。我们可以把原密钥拆分的位置按顺序记录为一个 N 位数组，镶嵌的位置按顺序记录为另一个 N 位数组，这样就完全确定了一个 2N 位的新密钥。
所以实际上这是一个固定密钥的加密，考虑到被加密文件的大小，以及密钥长度，新密钥的熵可能很有限（一些组合数的求和），所以不如直接： openssl enc -aes-256-gcm -k fixedpassword |
|
90
SuperMild OP @parametrix 有一个重点：当破解者拿到一个加密文件时，在他眼中，这只是平平无奇的加密文件，他并未获得 “密钥就在密文中” 这个信息。
另一方面，我这套方法只是加一层防护，防扫描，不妨特殊针对，在这种情况下，我想获得“完全不用理会密码”的便利。结果，我获得了便利，也真能防住普通扫描，这就很好啊。 并不是任何时候都需要高强度加密的，也有稍稍加一层比较薄的防护就够的情形，我针对这种情形，故意降低安全性，换取了完全不用管密码的爽感。（也不用担心一个密码泄露就影响其他，也不用担心一个特殊密码会忘记，也不用管理密码，我知道密钥永远和密文在一起，这让我很安心，我有信心解密。同时，撒网捕鱼的破解者却不知道 “密钥就在密文中” 这个信息。） |
|
91
SuperMild OP @msg7086 明白，但我觉得不安稳，文件名被修改的问题不得不考虑，整个文件名就是密码其实也很常见，这个安全性太低了。
其实把密钥嵌进密文也非常常见，这个做法本身必然被很多人想到过，但好处是花样比较多，具体怎么镶嵌可以搞得步骤很简单却很难猜。同时，由于是自己的思路，总能记得个大概方向。 也就是说，安全性既不会太低，也兼顾了便利性。 |
 |
92
crazytec 2022-01-13 00:33:01 +08:00
为什么不直接用空文件+密钥延伸生成密钥？这样即使脚本丢了也不会丢失数据，同时也可以防止网盘之类的扫描
|
 |
93
Johndo3 2022-01-13 01:03:18 +08:00
echo "password" | sha256sum
|
 |
94
Adelell 2022-01-13 02:00:24 +08:00
楼主莫非是张同学本尊？
|
 |
95
Asvel 2022-01-13 02:50:50 +08:00
既然是靠记住镶嵌方式的话，用这种方法和用「镶嵌方式的描述」（比如那几行关键代码）直接做密码有什么区别，反正你记得住。
|
 |
96
VZEXEZVzzz 2022-01-13 03:57:40 +08:00 via iPhone
楼主脚本的核心概念就是方便吧，那为什么不 alias enc=任意一个固定密钥加密呢？
费功夫多写几行代码，多装几个类库的意义又何在呢？ 假如想推广给更多的人用，他们得克隆仓库，安装 Python ，安装依赖，有什么能够让人们觉得方便的点呢？怎么看都不如用各种操作系统都自带的加密工具包写个小脚本方便吧 |
 |
97
AX5N 2022-01-13 04:22:52 +08:00
这也太弱智了
实际上相当于用同一个密钥以 aes256 的方式加密了所有的文件，别人确实没办法破解 aes256 ，但是只要拿到你的密钥（你的脚本）就相当于破解了所有的文件。 我直接用现成的加密解密算法还可以省去维护代码的精力，直接用脑子记住一条密钥就行了。成本比你小，安全性还略高（因为我的密钥是记在脑子里，你的密钥是存在电脑上）。 |
 |
98
cache 2022-01-13 07:42:18 +08:00
你这不是加密，是重新编码
等效于把记一个密码变成了记一种编码方式 |
|
99
SuperMild OP |
|
100
SuperMild OP @VZEXEZVzzz 我不想管理密钥啊。太简单的密钥，包括上面有人说用生日，破解者只要稍稍升级一下扫描程序就可以破解，我怀疑现在网盘已经升级了，因为这个升级实在太轻松了。
而复杂的密钥，又要管理。我这个是完全不用管密钥的。 @AX5N “只要拿到你的密钥（你的脚本）”…… 你不能这样说啊，不管我用什么方法加密，只要被别人拿了密钥，当然可以破解我全部文件。如果你用这个理由来说，那正常的加密不也是一样“只要拿到你的密钥（你的脚本）”就被破解了？ 简单的密钥，或者常用的密钥是能记住，但我很不愿意用简单的密钥（因为太容易被升级版扫描程序破解了），而复杂密钥，很难记，我记住镶嵌方式非常容易。 也许有人记复杂密钥更轻松，但也有人记镶嵌方式更轻松，人与人不一样，你不能随便说谁更弱智吧？ |
Select Language