0

I am thinking of an application for storing/managing files of arbitrary types (e.g. PDF, JPEG, PNG, text).

Files are stored encrypted in the file system. Additional data ("metadata") is stored (unencrypted) in an unencrypted database.

A random 256 bit encryption key is generated for each file (file encryption key = FEK). The FEK is encrypted using a master key and stored in database. AES in GCM mode (using a random IV) is used for encrypting file.

Encrypted FEK, IV, actual MIME type (e.g. application/pdf) and size in bytes are stored as metadata (-> unencrypted stored in database).

I wonder if storing MIME type (and size) will affect security (thinking of file formats with common/fixed/static leading/trailing byte sequences such as PDF, XML and JSON)?

1 Answer 1

1

I wonder if storing MIME type (and size) will affect security (thinking of file formats with common/fixed/static leading/trailing byte sequences such as PDF, XML and JSON)?

No. For some very old and broken ciphers, sure, that would have been a problem. That kind of "crib" (a "known plaintext" attack where you know some bytes of plaintext e.g. the magic number, or you know the structure of the message such as where certain repeated blocks are or the way curly braces are used) was important to old-school cryptanalysis (I'm talking, like, WW2 and earlier here).

Modern ciphers, used correctly, are all secure against known plaintext and message structure attacks. The "used correctly" part matters - for example, ECB mode can allow breaks of messages with known plaintext - but for AES-GCM with a unique key+nonce pair, used correctly, I could know the plaintext of every single byte of an encrypted message except one, and have literally no computationally feasible way to tell what that missing byte is. The much lower info exposure level of things like MIME types and sizes is a nonissue.

With that said, it is an info disclosure (just, not one that will cause a cryptographic break). Why do you need to store that data? The length is discernible from looking at the ciphertext (GCM makes AES into essentially a stream cipher) so it's arguably not hidden anyhow (unless you pad before encrypting), but the file type seems like something somebody might prefer to hide...

Also, be aware that GCM has a problem with very long messages. If you might ever encrypt hundreds of gigabytes with any particular FEK, you need to either use a different mode or implement re-keying.


Obligatory advice: Don't roll your own! That applies to ciphers, of course, and to implementations and constructions, but also to cryptosystems (at least in the case that you have any suitable advantage). Use a well-tested and well-reviewed library that abstracts all the cryptographic primitives instead. One popular choice is NaCl (and its various "libsodium" variants). With libraries like that, you can just ask it to generate a key and encrypt a message, and it takes care of all the complicated bits. That's much safer than what you're attempting here, where you specify and might have to actually call the cipher primitives directly.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .