根据ownCloud 文档,如果启用加密,文件大小可能比未加密形式大 35%。
根据我对加密的理解,文件大小应该或多或少相同(可能在末尾填充一些 0 位以使其成为密钥大小的倍数)。
这是不正确的吗?如果不是,为什么?
根据ownCloud 文档,如果启用加密,文件大小可能比未加密形式大 35%。
根据我对加密的理解,文件大小应该或多或少相同(可能在末尾填充一些 0 位以使其成为密钥大小的倍数)。
这是不正确的吗?如果不是,为什么?
最有可能的是,加密文件是 base64 编码的,这将占文件增加的 33.3%(您将三个字节的数据编码为四个字节的 base64 数据)。每 64 个字符插入一个新行以使其更易于阅读(就像 openssl、GPG、PGP 中的 ASCII Armor 所做的那样)将使大小增加 65/64。
结合这两种效果,新文件的大小为 (4/3)*(65/64) = 原始文件大小的 135.4%,或者文件大小增加了 35.4%。
我已经在这里完成了这个答案中的计算。
尽管加密不需要显着更改文件大小,但您是正确的。如果存在标头、初始化向量/nonce、一些填充以使其成为完整块和/或 MAC 以检查完整性,它可能会添加几个数据块,尽管这些更改对于大文件来说是微不足道的(例如,添加四个块到 1 MB 的 AES 编码文件将使文件大 0.006%)。
但是,为了不增加文件大小,您需要将加密数据作为任意二进制文件存储和传递。任意二进制文件通常通过电子邮件被阻止以防止传播计算机病毒,并且通常难以在十六进制编辑器之外打开。Base64 编码文件比未知文件类型的二进制文件更容易传递,并且是一种更便携的格式。
如果文件正在被压缩,那么您可能会看到这种差异。
压缩算法在非随机数据上效果最好。加密旨在从信息中产生随机性。信息通常很容易压缩,因为它有模式。但是,如果您对其进行加密,您通常会擦除任何模式(和信息)。
示例:2.75GB 的电子邮件存档文件可以轻松压缩到 <.5GB。但是,如果这些电子邮件档案被加密,那么压缩版本将更接近 2.75GB。
通常,% 标记表示文件在加密后可能是 Base64 编码的,并且还可能在每个块上获得一些校验和以防止损坏。Base64 将 8 位的字符编码为 6 位的字符,这意味着由于渲染整个文件需要更多的字符,相关文件会变大 30%。添加每块校验和,您最多可以达到 35%。
通常,加密本身会增加一些开销。通常,开销是页眉+页脚、最终加密的密钥、参数、盐、校验和,还有一个块大小减 1,因为如果加密数据不能与块大小均分,则必须填充最多块大小 - 1。
但是上一句中的所有这些数据都会为每个文件添加静态数据量,无论其大小如何,即使它是 1 GB 或 100 GB 大。
以 % 表示的数据放大表示它是一个重新编码过程,如 base64 或类似的东西。