预计有 100MB 的数据要进行加密，通过某种传输方式传输到客户端后，再进行解密。推荐使用什么算法？

[ReputationZh]

1. 数据格式是 tar.gz
2. 不采用解压密码方式

主要是想对文件加密，而且不想让文件大小变大太多且不涉及传输。
加密的理由主要是，这个文件被他人获取到，增加破解难度，不会轻易观察到数据的组成方式，去篡改这个文件。

[shuax]

aes

[Yorwba]

HTTPS

[murmur]

解压密码为什么不要，数据加密跟解压密码有区别么，说一下

[janus77]

先说你是数据流还是文件

[libook]

如果目的只是为了防范传输过程中被监听，那么 TLS/SSL 就是专门为这个场景服务的，比如用 HTTPS 、SSH 或者 FTP over TLS 。

如果连对方接受端都不信任，那么就可以把文件加密然后让接收方自行选择实际解密，这块目前被认为是安全的算法都可以用，对称加密、非对称加密，这些可以去网上看看相关介绍，决定用哪种算法就可以考虑用 OpenSSL 等工具来做文件的加解密。

[ReputationZh]

@janus77 文件

[ReputationZh]

@murmur 容易被破解

[felixcode]

借楼问下，有没有用 AES256 且可以做成自解密(类似于自解压）包的工具。

[ReputationZh]

@libook 主要是想对文件加密，而且不想让文件大小变大太多且不涉及通信。

加密的理由主要是，这个文件被他人获取到，增加破解难度，不会轻易观察到数据的组成方式，去篡改这个文件。

[whileFalse]

谁跟你说解压密码容易被破解的？

[Greatshu]

usbkey

[czkwg8]

解压密码够长都可以破个几百年的了

[luyao1993]

你要考虑的应该不是用什么算法，而是密钥如何传输。

[Wincer]

解压缩同样可以使用 AES 算法加密，这两者并不冲突。

[52icarus]

1. Server->Client : base64(8bytes random challenge)
2. Client->Server : base64(8bytes handshake client key)
3. Server: Gen a 8bytes handshake server key
4. Server->Client : base64(DH-Exchange(server key))
5. Server/Client secret := DH-Secret(client key/server key)
6. Client->Server : base64(HMAC(challenge, secret))
7. Client->Server : DES(secret, base64(token))

用非对称加密协商一个密钥,然后对文件进行对称加密传输就行了.业务层处理

[52icarus]

而且我觉得你理解错了 3 楼解压密码的方案,其实这个方案是可行的. 解压密码加密后, 是看不到真实的文件结构了的.

[meepo3927]

解压密码怎么破解？

[sillydaddy]

压缩加密软件(比如 7zip)，选择 AES256 加密，如果设置一个数字+英文字符格式的密码，密码长度只需要 46 位，就可以达到宇宙级别的强度。

如果嫌麻烦，密码设短一些，比如 12 位，可以让破解的人付出 10 元的计算代价，然后密码长度每加一位，破解需要付出的代价就增加 56 倍。你可以根据这 100MB 数据的价值，选择一个合适长度的密码。

[ReputationZh]

@52icarus 可能是惯性思维了，我记得 winrar 加密后，打开能看见内部文件。

[ReputationZh]

@sillydaddy 现在打算用 tar 和 openssl 来配置密码，到时候测试一下加密强度。

[xiaofan305]

rar 可以加密文件名文件结构，也就是不显示文件名和结构。

[Huelse]

对称加密文件，非对称加密对称密钥
简单点就 chacha20-poly1305

[qwerthhusn]

AES 啊，现在是个 CPU 都有硬解 AES 的，很快

[joApioVVx4M4X6Rf]

直接 xor 操作啊，数据流的第一个字节 xor 第二个字节 结果 xor 第三个字节，解密的时候同样搞一遍就行了

[autoxbc]

@felixcode #8 WinRAR 的加密算法就是 AES-256，也能制作自解压缩包，选择压缩方式为「存储」，实际上就是无压缩的 AES-256 加密

[ThinkZ]

在 VPN 环境下互传不可以吗？

[honeycomb]

@ReputationZh rar 允许加密文件名。此外，此类加密手段的密钥生成是用密码加随机盐，通过密钥生成函数迭代一定次数算出来的，因此破解起来很困难，要通过彩虹表之类的技术才能有效破解。

如果密码本身就很复杂，达到了上百 bit 程度的话，彩虹表也搞不定它。

[felixcode]

@autoxbc
谢谢，之前不知道，以为只是简单加密，刚查了下，应该是 5.0 版前是 AES-128, 5.0 开始是 AES-256 。

[w1573007]

压缩 2 次啊，都加密，而且是不同的密码，这又没啥成本

[vantis]

只要找对方要个非对称加密的公钥就好了=。=

[vantis]

具体来说 让对方选择一个非对称算法 算法强度可以让对方选 一般来说 RSA4096+差不多了 或者 ECC 也更强一点（不过 ECC 可能需要双方协商密钥）加密后由于私钥只有对方持有（或者 ECC 为你和对方持有不同的两把私钥）那么就可以传输了

[vantis]

再高效点可以参考 HTTPS 的实现 即文本用对称算法加密 而将加密用的对称密钥用以上非对称方式传递（给对方的叫电子信封 内容有两块 一块为非对称加密过的对称密钥 一块是对称密钥加密过的数据）

[icyalala]

文件用简单的对称加密处理就好了，密钥或密码用非对称加密传输，原理和 SSL 差不多。
关键的问题在于，客户端的逆向你无论如何还是防不住。

[legiorange]

可以参考 https://onionshare.org

[crypton]

@ReputationZh 可以选择隐藏文件名

[flynaj]

现成的 7z.rar.zip 都可以。开源的 7z,zip 。

[HuLiY]

gpg4win 了解一下

[gBurnX]

1.没必要 https，对于加密来说，性价比太低，而且这种架构，不容易做优化，服务器相关配件采购的性价比低。

2.建议老版本 RAR + 复杂 16 位密码 + 加密文件内容（看不到文件列表），这就够了。别用 7zip，7zip 的优势在于高压缩率，用来处理加密，算力性价比太低。

3.用 RAR 要注意授权问题，RAR 可不是可以随意商用的开源产品。

[jim9606]

没搞懂你想干什么，是不是要给一个随客户端软件分发的数据文件做混淆，避免被逆向提取内容？还是只是防止被恶意篡改？

如果是前者应该用加密算法，后者的话应该用签名算法，可以考虑用 PGP 软件来做，可以同时实现这两点。将 PGP 公钥硬编码进客户端中，数据文件发布前用 PGP 私钥加密签名。

[nuk]

AES-256-GCM

[muzuiget]

带密码的压缩文件，本身就是加密了压缩文件内部的数据区，内部加密可以用任何加密算法，加密时选择“同时加密文件列表”就行，何必还多此一举再找别的方法，

[xuegy]

你直接给客户端开一个 shadowsocks 呗，又不一定是要用来当梯子，完美实现你的需求。

[deepdark]

复杂一点的压缩密码就好，或者加密完了再用 gpg 加密一次

[shilyx]

楼主考虑的对，很多留言者没考虑到需求点在哪

有人说 tls，那是对过程加密。过程上的监听者就是个假想敌，如果有人想从链路上截获你的数据的话，你基本拒绝不了。技术上拒绝，生理上也拒绝不了，多说无益。几乎没有人在链路上截获你。
但不是说不用 tls，有条件还是要上。

解压密码，最简单的是调用 7z.exe 解压，密码很容易在使用中被抓到。就算你继承了动态库、静态库，关键调用还是很容易被分析出来。如果是源码级魔改并融合 7z，那工作量是直线上升。
就算解决了加密问题，100M 的文件常规思路还是解压到临时目录来使用，很容易被发现的。全加载到内存，按数据结构组织后轻松上 500M 。

楼主的需求可以总结为：
1 、文件到了终端，依然作为一个格式不明的加密文件存在
2 、加密文件支持随机读取，不一定要读取就全部解密

推荐基于 aes 搞一个自己的加密算法。
aes 仅仅是对 16 字节的输入给出 16 字节的输出而已，距离直接应用还有一段距离。需要选择一种模式，简单的 ecb 或好一些的 cbc，密码用二进制，加密文件格式分好段，做好 padding 和校验。这一切自己完成的话，光凭一个文件，几乎是破解不了。

[wakzz]

AES

[linbingcheng]

SSL

[zhaohao]

那就用 PGP 了，你用对方公钥加密文件，对方私钥解密。

[meloncc]

sm2+sm4

[dream10201]

国家下一代战机原理图？

[Slartibartfast]

记得之前有人说解压密码特别好破解，随手扔了一个加密后的 rar 给他约定父子局。

从此他就再也没出现过。

[yy77]

https://www.openpgp.org/ 应该就是应对这种需求的。

[no1xsyzy]

完整点： https://www.crypto101.io/
轻松点： https://www.bilibili.com/video/BV1BW41137oL

[DoctorCat]

不想用密码就用非对称加密好了，不想自研算法就用 SSH 建立管道传输就好了，实现了数据压缩、端到端明文，传输过程被加密。

[3dwelcome]

@shilyx "推荐基于 aes 搞一个自己的加密算法。"
AES 是最好破的，因为都是调用通用的 C 库，编译后代码都大同小异，可识别度很高。
很容易在调用函数的时候，各种参数被反汇编出来。

[libook]

@ReputationZh 我把你回复我的信息拆分成两个独立的需求：
1. 不让其他人看到文件内容：压缩包的加密功能就可以用，不想用压缩包的加密可以自己用 OpenSSL 给文件加密，具体教程可以去网上搜。算法的选择看你要多么强的安全等级，以及能接受多么复杂的使用过程和多么长的加解密时间，这个也可以去搜各种加密算法的对比。
2. 不让人篡改文件的内容（或者知道文件有没有被篡改过）：可以用哈希或基于非对称加密的签名算法，哈希简单来讲就是算个 SHA1 、SHA2 、SM3 等，如果文件被篡改，这个值是会发生变化的；用哪一种取决于你需要多强的安全等级，同样，安全的等级越强，计算需要的时间越长。签名算法也可以使用 OpenSSL 来实现，具体可以去搜一下教程。

如果你两个都需要，可以两个都做

[653513754]

@52icarus vx 好像是这种流程

[libook]

主流的加密算法强度已经足够好了，没有被发现漏洞所以只能暴力破解，而暴力破解基本上就是搞一个常用密码的字典，然后一个个试，都不行的话就任意组合字符尝试，你只要确保你的密码不包含任何常见字符串且位数足够长就行了。

安全上有个说法是打破物理隔离没法谈安全，如果你读取文件的设备上已经被装了各种监视程序来打探你读取文件的细节，那么基于计算机软件的任何安全措施都没有用，最底线就是要做到物理隔离，确保最终使用的设备环境是安全的。

然后这个问题可能是个 XY problem，为什么不用解压缩密码，为什么格式必须是 tar.gz ，以及使用场景的细节是怎样的；这些说详细了大家可能可以提供更好的方案。

[shawndev]

openpgp，提前交换公钥后通过数字信封格式加密封装。

[newmlp]

aes 加密文件，rsa 传输加密密钥

[beijiaoff]

lz 你给了用户密码，对用户来说岂不是没有加密的状态了。

是不是需要的实际是另外一种需求，没有密码，谁都可以运行，但没办法知道内部数据组成方式。

[after1990s]

@felixcode 现成的 opengpg

[alfchin]

@ReputationZh 加密码的时候勾选加密目录结构还是啥的，人家就什么都看不见了