预计有 100MB 的数据要进行加密,通过某种传输方式传输到客户端后,再进行解密。推荐使用什么算法?
- 数据格式是 tar.gz
- 不采用解压密码方式
如果连对方接受端都不信任,那么就可以把文件加密然后让接收方自行选择实际解密,这块目前被认为是安全的算法都可以用,对称加密、非对称加密,这些可以去网上看看相关介绍,决定用哪种算法就可以考虑用 OpenSSL 等工具来做文件的加解密。
加密的理由主要是,这个文件被他人获取到,增加破解难度,不会轻易观察到数据的组成方式,去篡改这个文件。
用非对称加密协商一个密钥,然后对文件进行对称加密传输就行了.业务层处理
如果嫌麻烦,密码设短一些,比如 12 位,可以让破解的人付出 10 元的计算代价,然后密码长度每加一位,破解需要付出的代价就增加 56 倍。你可以根据这 100MB 数据的价值,选择一个合适长度的密码。
如果密码本身就很复杂,达到了上百 bit 程度的话,彩虹表也搞不定它。
2.建议老版本 RAR + 复杂 16 位密码 + 加密文件内容(看不到文件列表),这就够了。别用 7zip,7zip 的优势在于高压缩率,用来处理加密,算力性价比太低。
3.用 RAR 要注意授权问题,RAR 可不是可以随意商用的开源产品。
如果是前者应该用加密算法,后者的话应该用签名算法,可以考虑用 PGP 软件来做,可以同时实现这两点。将 PGP 公钥硬编码进客户端中,数据文件发布前用 PGP 私钥加密签名。
有人说 tls,那是对过程加密。过程上的监听者就是个假想敌,如果有人想从链路上截获你的数据的话,你基本拒绝不了。技术上拒绝,生理上也拒绝不了,多说无益。几乎没有人在链路上截获你。
但不是说不用 tls,有条件还是要上。
解压密码,最简单的是调用 7z.exe 解压,密码很容易在使用中被抓到。就算你继承了动态库、静态库,关键调用还是很容易被分析出来。如果是源码级魔改并融合 7z,那工作量是直线上升。
就算解决了加密问题,100M 的文件常规思路还是解压到临时目录来使用,很容易被发现的。全加载到内存,按数据结构组织后轻松上 500M 。
主的需求可以总结为:
1 、文件到了终端,依然作为一个格式不明的加密文件存在
2 、加密文件支持随机读取,不一定要读取就全部解密
推荐基于 aes 搞一个自己的加密算法。
aes 仅仅是对 16 字节的输入给出 16 字节的输出而已,距离直接应用还有一段距离。需要选择一种模式,简单的 ecb 或好一些的 cbc,密码用二进制,加密文件格式分好段,做好 padding 和校验。这一切自己完成的话,光凭一个文件,几乎是破解不了。
从此他就再也没出现过。
如果你两个都需要,可以两个都做
安全上有个说法是打破物理隔离没法谈安全,如果你读取文件的设备上已经被装了各种监视程序来打探你读取文件的细节,那么基于计算机软件的任何安全措施都没有用,最底线就是要做到物理隔离,确保最终使用的设备环境是安全的。
然后这个问题可能是个 XY problem,为什么不用解压缩密码,为什么格式必须是 tar.gz ,以及使用场景的细节是怎样的;这些说详细了大家可能可以提供更好的方案。
是不是需要的实际是另外一种需求,没有密码,谁都可以运行,但没办法知道内部数据组成方式。