6
$\begingroup$

I'm going paperless, and I want to encrypt the documents that I scan. I'd like to use CommonCrypto to perform AES-XTS encryption on each file. I'm a software engineer, and I like the idea of being able to write my own wrapper around the library. However, I am not a crypto expert by any means. If I understand IVs and salting correctly, is it possible to use one long passphrase to generate a unique encryption key for each file? Also, is this general approach a good idea, or should I go in a different direction?

$\endgroup$
  • $\begingroup$ Short answer: yes, it's completely fine to do that... using salting and IVs correctly is a big part of what matters here. I see no reason that XTS would be any harder or more impractical than CBC... the only restriction is that you're not going to be encrypting many GBs of data with one key, which I can't imagine you are. One simple way to generate 256 bit keys (assuming you want to do that) is probably just to use HMAC-SHA256(passphrase,nonce), although HMAC wasn't designed for this, it's a working approach. $\endgroup$ – Iam Nick Jan 13 '16 at 0:50
  • $\begingroup$ I'll be encrypting lots of smaller files. Doesn't the salting let me take a passphrase and turn it into a unique encryption key for each file? Or am I understanding that wrong? $\endgroup$ – Halen Jan 13 '16 at 0:55
  • 2
    $\begingroup$ yes a unique salt makes the KDF output different for the same password $\endgroup$ – Richie Frame Jan 13 '16 at 0:57
  • 4
    $\begingroup$ you store the salt and IV with the file. However.. XTS mode does not use an IV but rather a disk sector number, and is not a preferred method for file encryption $\endgroup$ – Richie Frame Jan 13 '16 at 1:50
  • 1
    $\begingroup$ The current "standards" for file encryption are GCM and OCB mode. CBC and CTR are fine as long as you use them correctly and add a MAC. ANY mode can be bad if used incorrectly. Take a look at SIV mode, it is a nonce reuse resistant 2-pass mode, I have my own variant which looks like a hybrid between XTS and SIV (no security proofs) $\endgroup$ – Richie Frame Jan 13 '16 at 3:41
3
$\begingroup$

Yes, the principle to use a common password and a unique salt per file with a key derivation function is a good and acceptable practice, as you generate the salt randomly and with the right size. The uniqueness of the salt guarantees a different password per file (actually one password per salt, so: do not reuse a salt, use a csprng).

You forgot to mention (or to design) how you're are going to protect the cipher integrity. XTS mode does not provide this property, you should add a message authentication code (MAC) as HMAC.

It would be probably better and simpler to switch to another mode which provides confidentiality and integrity as GCM or OCB. The second reason for switching from XTS that is that mode is designed to be used in Full Disk Encryption context and encrypt disk sectors and not a whole file. some other reasons.

Don't forget to store the salt with the ciphertext and protect its integrity, too.

$\endgroup$
  • $\begingroup$ Thanks for the information. I'm using the CommonCrypto library, which unfortunately does not have GCM or OCB. Would CBC be sufficient? If I'm understanding correctly, the information I have so far is that I would store the salt, IV, and HMAC with the encrypted file. I don't need to protect those 3 values, because they don't leak information. Is that correct? $\endgroup$ – Halen Jan 13 '16 at 15:05
  • $\begingroup$ I'm not familiar with the library you're using, but the IV is usually part of the ciphertext (the first block). The CBC (with a random IV) does not leak information about the plaintext. If you are going to use an HMAC remember that you'll need another key, you could derive it from the same password but you need to differentiate it from the encryption key. NEVER use the same key to encrypt and hmac the same message. $\endgroup$ – ddddavidee Jan 13 '16 at 15:38
  • $\begingroup$ I don't think I'm going to use an HMAC. It looks like my process will be as follows: Choose a passphrase with high entropy > Generate a salt with a CSPRNG > generate an encryption key from the passphrase and salt > generate an IV > Encrypt the data > Append the salt and the IV to the cipher text. Does that have vulnerabilities that I need to address? $\endgroup$ – Halen Jan 13 '16 at 16:30
  • $\begingroup$ If you don't mind that an attacker could modify the ciphertext and observe the behavior of your software during the decryption (and modify one more time the ciphertext and so on), there should be no problem. If you want only to protect the confidentiality of your your files it is ok, but if you think that someone could play with your ciphertexts and your decryption function you could have a classical Oracle attack. $\endgroup$ – ddddavidee Jan 13 '16 at 16:40
  • $\begingroup$ If your problem is only to avoid someone reading your files if you forgot your USB drive at the coffee shop that would be ok. $\endgroup$ – ddddavidee Jan 13 '16 at 16:41

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.