加密的FEK、IV、实际MIME类型和未加密的文件大小元数据是否会影响加密文件的安全性？

Question

我正在考虑一个用于存储/管理任意类型文件(例如PDF、JPEG、PNG、text)的应用程序。

文件被加密存储在文件系统中。附加数据(“元数据”)存储在未加密的数据库中(未加密)。

为每个文件(文件加密密钥= FEK)生成随机256位加密密钥。FEK使用主密钥进行加密，并存储在数据库中。在GCM模式下(使用随机IV)的AES用于加密文件。

加密的FEK、IV、实际MIME类型(例如application/pdf)和大小以字节为单位存储为元数据(->未加密存储在数据库中)。

我想知道存储MIME类型(和大小)是否会影响安全性(考虑使用公共/固定/静态前导/尾随字节序列(如PDF、XML和JSON)的文件格式)？

Answer 1

我想知道存储MIME类型(和大小)是否会影响安全性(考虑使用公共/固定/静态前导/尾随字节序列(如PDF、XML和JSON)的文件格式)？

不是的。当然，对于一些非常古老的破译密码来说，这将是一个问题。这种"crib“(一种”已知明文“攻击，您知道一些明文字节，例如魔术数字，或者您知道消息的结构，例如某些重复块的位置或使用花括号的方式)对于传统的密码分析(我正在谈论，比如，WW2和更早的时候)非常重要。

正确使用的现代密码都能抵御已知的明文和消息结构攻击。“正确使用”部分很重要--例如，欧洲央行模式可以允许以已知明文中断消息--但对于具有唯一key+nonce对的AES-GCM，正确使用，我可以知道加密消息的每个字节的明文，但实际上没有计算上可行的方法来判断丢失的字节是什么。低得多的信息暴露水平的事情，如MIME类型和大小是一个没有问题。

尽管如此，这是一个信息披露(只是，不是一个将导致密码中断)。你为什么要存储这些数据？长度可以通过查看密文(GCM将AES从本质上变成流密码)来识别，因此它可以说是不隐藏的(除非您在加密之前垫上)，但是文件类型似乎是某些人可能更喜欢隐藏的东西…

此外，请注意，GCM与非常长的消息有问题。如果您可能使用任何特定的FEK加密数百to，则需要使用不同的模式或实现重键。

强制性建议:不要自食其力！当然，这也适用于密码器、实现和构造，但也适用于密码系统(至少在您有任何适当优势的情况下)。使用一个经过良好测试并经过良好审查的库来抽象所有的密码原语。一个流行的选择是NaCl (以及它的各种“various”变体)。有了这样的库，您可以只要求它生成一个密钥并加密一个消息，它处理所有复杂的比特。这比您在这里尝试的要安全得多，在这里您指定了密码原语，并且可能需要直接调用密码原语。