4
$\begingroup$

Imagine I have four files I want to encrypt. I have master key, and from that master key I derive four keys, one for each file:

key1 = HMAC-SHA-2(masterKey, filename1)
key2 = HMAC-SHA-2(masterKey, filename2)
key3 = HMAC-SHA-2(masterKey, filename3)
key4 = HMAC-SHA-2(masterKey, filename4)

After that, I encrypt each file with AES, each with its own derived key (file1 encrypted with key 1, file2 encrypted with key2, etc).

Imagine Alice (owner of the master key) publishes every encrypted file publicly and only shares key3 with Bob.

  1. Is it then safe to assume that Bob will only be able to decrypt file three because he only has key3, and no one else will be able to encrypt the other files (except Alice)?

  2. Is Bob able to decrypt the other files, when he knows that his key was made by using HMAC-SHA-2(masterKey, filename3), even though he doesn't have the keys for the other files?

  3. If all four keys are handed out to one person (and that person also knows the four filenames) , is that person then able to derive the master key?

$\endgroup$
  • 1
    $\begingroup$ Why use the filename instead of a random per-file value? $\endgroup$ – CodesInChaos Jan 6 '15 at 14:44
  • $\begingroup$ @codesinchaos because I want to create a situation where Alice can share a key with Bob, if Bob provides Alice with the filename. This way, Alice only has to remember her master key (and does not neet to store/remember random values) $\endgroup$ – user3231622 Jan 6 '15 at 14:57
  • 3
    $\begingroup$ The standard solution would be to store the random value (which acts similar to an IV) at the beginning of the ciphertext. I would avoid coupling to external meta data, especially since filenames aren't unique. $\endgroup$ – CodesInChaos Jan 6 '15 at 15:27
  • $\begingroup$ Instead of a per-file derived key what about a per-user key. You could use masterkey and the user email to derive the key. Obviously all the files requested bye the user would be encrypted using the same key so perfect forward secrecy is lost $\endgroup$ – Gianluca Ghettini Jan 11 '15 at 8:40
3
$\begingroup$
  1. Yes, it's safe, as you can't calculate the secret key from the HMAC result. HMAC would be useless without this feature
  2. No, Bob will not be able to use his key to calculate the other keys, as long as you use a reasonable hash function (SHA-2 should fit)
  3. It's the same as 1., Bob doesn't get more information by more derived keys

But when Bob get the key for filename2 and Carlos for filename3, then it's important that Bob nor Carlos are able to affect the filenames.
Otherwise they could create a key for a encrypted file related to another person

$\endgroup$
3
$\begingroup$

As CodesInChaos pointed out, the major flaw with this is that filenames aren't unique. If you did this on a large scale, anyone who's been given a key for a filename could decrypt any file with that filename. Even if the contents of the file are different, and they weren't intended to be given access to that file.

Here's another solution that has one unique key, but doesn't require Alice to keep track of multiple keys. It has the downside of having to compute the hash of the file prior to encrypting it.

key1 = SHA-2(masterKey, SHA2(file contents of file1))
key2 = SHA-2(masterKey, SHA2(file contents of file2))
key3 = SHA-2(masterKey, SHA2(file contents of file3))
key4 = SHA-2(masterKey, SHA2(file contents of file4))

This would virtually guarantee that someone only can decrypt a file they were given the key for since the contents of the file serve as part of the hash used to generate the key.

$\endgroup$
  • $\begingroup$ Shouldn't the second HMAC-SHA2 be just a SHA2? If you're not keying it, you don't need to HMAC it. $\endgroup$ – cpast Jan 7 '15 at 0:54
  • $\begingroup$ @cpast you're right, I was just copying the question. I'll change the answer. $\endgroup$ – Steve Sether Jan 7 '15 at 18:10
  • 1
    $\begingroup$ The problem with this approach, obviously, is that once the files are encrypted it's impossible to re-derive the key. So the keys (or the content hashes) must be stored. Unless you're already storing content-hashes, you might as well just be using a random value. This can be faster (no need to hash potentially large files) and more secure in some use-cases (the same file could be encrypted using different keys for different parties). $\endgroup$ – Stephen Touset Jan 7 '15 at 18:50
  • $\begingroup$ @StephenTouset This is true. The use case doesn't work when Alice needs to access the encrypted file again, and doesn't keep an unencrypted file locally, or when the key is lost. If alice doesn't want to keep plaintext around, a simple solution might be Alice simply encrypts all her files locally with the master key, and decrypt+SHA2 if she needed to derive a key again. $\endgroup$ – Steve Sether Jan 7 '15 at 19:54

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.