文件加密后体积膨胀

最近在做自己的相册，所以打算做点私密空间的功能，很多东西向调研清楚一点。

有一种方式 其实可以尝试 就是 base64 然后自定义编码库 也算是一种加密了

我记得可以生成一个长密钥，然后非对称加密这个长密钥，实际文件内容用长密钥对称加密，这样体积就不会变大很多了

@815979670 base64 感觉体积太大了，如果用户发现 10g 的视频被我移动到安全文件夹后，体积增加 1/3, 用户肯定会反感的。

@edis0n0 您说的大概是 rc4 这种加密方案？ 密文和原文一致 ?

@jeesk #5 不是，我记得 TLS 就是我说的这种方式设计的，太久没研究这块忘记了

只是加密文件头那分分钟被人爆出来…
其实如果私人的话最简单的是 zip 加密… 算法 rc4 或者 aes 都可以
你要做的只是确保用户输入主密码后你能补起到足够长以防爆破就可以

AES 是等长加密，并不会导致体积膨胀，最多相差一个块的长度，也就是不超过 16 字节，再加上 16 字节的 IV ，总共不到 32 字节。如果分段加密，也就每段增加不到 32 字节

估计你把 base64 当密文本身了（ base64 编码后体积膨胀大概三分之一），原始密文是 latin1 （平时说的二进制、乱码），你存 latin1 就行

加密文件大小不会变大。 你肯定是代码写错了

只要求 CCA 安全性的时候公钥加密的码率是 1 ，而且普遍通行的加密算法都是这样做的。

自己设计一个一个文件格式，加密后压缩，用自己的解码器来解码

AES 加密并不会导致文件体积变大很多啊

对称加密，如果输入和加密算法的块大小对齐，不会增加体积，没有对齐，则会 padding 。增加的体积都是按字节算的，不会很大。

aes 并不会导致加密后内容变大很多，顶多增加一个 16 字节对齐

1. 加密后看到很多，你不会看的是加密后的 base64 吧，二进制形式不会加很多的。
2. 修改文件头文件尾的方式其实不太安全，如果双击打开确实基本是打不开的，但用分析工具比如 trid ，还是很容易识别的，除非你把这种类型的文件的结构都破坏掉，只破坏文件头通常是不够安全的。

padding 可能会引入一些数据吧，但应该不会很大。

自己设计一个加密方案，比如每多少字节反转一下，0 到 x-1 保持不变，x 到 2x-1 0 、1 反转

你可以试试 aes-256-cbc https://www.npmjs.com/package/@ckvv/mimi 文件大小变化不大

@xy90321 哈哈。ok ， 明白。


@eason1874 @shiji
@dingwen07 @cppc

是我搞错了，我把密文和二进制搞混了

@lisxour 是的， 如果只是破坏文件头还不如不加密。

@xtinput 这样对比 aes 速度会慢还是快点？