I'm not a cryptographic expert by far but I do understand that when it comes to cryptography it's best to stick with established standards.

I have to ensure confidentiality and integrity of a bunch of files (chunks of these files actually).

Getting inspiration from "serious" people, AES-GCM with distinct IVs and keys for each chunk seems the way to go since it provides both confidentiality and integrity, and is good performance-wise. It also seems a good practice to encrypt each chunk key with a Key Encryption Key that has to be renewed on a regular basis.

Here are my questions:

  • Did I get it right up to this point?
  • Are there specific ciphers for encrypting each chunk key with the KEK? Does it require to use an IV since there shouldn't be two identical chunk keys?
  • What are the good practice/standards to protect the KEK on a server without dedicated hardware such as an HSM?

PS: I'd be glad to take a look at any ressource available and accessible to non-experts on that topic.

  • 2
    $\begingroup$ Theorem: don't invent your own cryptography because you will get it wrong. Lemma: don't implement cryptography yourself because you will get it wrong. $\endgroup$ – Elias Feb 20 '18 at 6:46
  • 2
    $\begingroup$ Universal Law of cryptoSE: If you have to ask us for help you should definitely not do it. $\endgroup$ – Elias Feb 20 '18 at 6:47
  • 1
    $\begingroup$ Why, exactly, do you want to encrypt parts of files? $\endgroup$ – SAI Peregrinus Feb 20 '18 at 17:54
  • $\begingroup$ Something wrong with SSL/TLS that prevents you from using it (instead of trying to reinvent the wheel)? $\endgroup$ – e-sushi Mar 15 '18 at 16:50
  • $\begingroup$ @SAIPeregrinus: because the files are not stored "as is". Files' metadata are stored separately from the raw data which is sliced in chunks and stored "flat". $\endgroup$ – sgable Mar 16 '18 at 13:35

I'm looking at a very similar thing, where I need to encrypt data at rest, and the existing file structure that I'm trying to add encryption to is randomly accessed chunks / blocks of binary records.

The file IO I'm working with is performance sensitive, and the binary structure caters for allocating and freeing record space within these chunks. It is in an embedded environment, so the desktop storage encryption solutions can't be applied.

I looked at AES-GCM after seeing many recommendations for it. But the NIST guidelines for its use, which require unique IVs for a given key, make it challenging for storage encryption. Somewhere I read that AES-GCM is better suited to transport encryption.

I'm currently heading down the path of AES-CBC + AES-CMAC, due to less stringent requirements around key and IV re-use. Having a file key and chunk IVs from a CRNG seems to be acceptable. Again, I'm new to this as well, so I'm happy to be told otherwise. I'm just on here researching the process of deriving keys for encryption vs MAC generation from a common key.

I was tempted by OpenSSL's EVP_aes_256_cbc_hmac_sha256, but then the docs have a warning that it was only intended to be used internally by OpenSSL's SSL/TLS. It would be nice to find the "shrink wrapped" answer to take care of all this.

Key storage without an HSM can be challenging, especially if there is no user involved. In a desktop environment, a key derived from a passphrase (KDF) is the traditional solution. A "logon secured" encryption scheme can also be used (e.g. Microsoft's DSAPI). Without that, I think it becomes a chain of "where to keep the key that encrypts the key...", which I haven't yet seen a good answer for.

Securing keys with another layer of encryption is called key wrapping. I've seen code that uses AES to encrypt one key with another as a simplified version of this.


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.