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?
$\begingroup$
$\endgroup$
16
-
$\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 NickCommented Jan 13, 2016 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$– HalenCommented Jan 13, 2016 at 0:55
-
2$\begingroup$ yes a unique salt makes the KDF output different for the same password $\endgroup$– Richie FrameCommented Jan 13, 2016 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 FrameCommented Jan 13, 2016 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 FrameCommented Jan 13, 2016 at 3:41
|
Show 11 more comments
1 Answer
$\begingroup$
$\endgroup$
9
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.
answered Jan 13, 2016 at 6:32
-
$\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$– HalenCommented Jan 13, 2016 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$ Commented Jan 13, 2016 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$– HalenCommented Jan 13, 2016 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$ Commented Jan 13, 2016 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$ Commented Jan 13, 2016 at 16:41