Jtdylktuy

This is a follow-up question to

HKDF: ikm, salt and info values

Based on the feedback, I have now decided to implement my key derivation for AES-GCM-256 file encryption roughly as follows:

Everything up to scrypt is run once, the HKDF-expand part is repeated for every file to be encrypted. The random salt and info values get stored (unencrypted) with the encrypted file.

My questions:

1. Do you see any serious flaws?




2. What is your opinion about the various bitlengths? In particular: Does it make any sense at all to blow up everything to 512 bits temporarily when, in the end, I use only 256 bits for the data protection key?

There is no real reason for the info values to be 512 bits long. The only requirement for them is to be unique, and for that, even 128 bits of randomness is enough (at least assuming that you won't be encrypting more than $2^{64}$ files with the same key). The same goes for the salt, too. Of course, using longer values won't really hurt security, it just makes your encrypted files a bit larger.

I see no problem with using 512-bit intermediate values, even if you're only generating a 256-bit key at the end. In fact, I'd consider replacing SHA-256 in the first step with SHA-512, if only to standardize on a single hash function. I believe SHA-512 is even somewhat faster on modern 64-bit CPUs, although that's unlikely to make any significant difference in practice compared to I/O and other overhead costs.

Also, as long as you're using a distinct IV/nonce for each file, you don't also need a distinct key. So you could just use the master key (truncated to whatever length you need) directly as the AES-GCM key, and dispense with HKDF entirely. Or you could keep using HKDF-Expand (e.g. if you need to derive other key material from the master key for some reason), but only call it once with a fixed info string (say, "AES-256-GCM-key" or something else reasonably distinct and informative) to derive the encryption key.

You could even consider deriving your GCM IVs from the master key using HKDF, with an info string like "AES-256-GCM-IV-<counter>", where <counter> is an incremental counter to make all the info strings for a given master key unique. (You could also append e.g. the file name and the current time to the info string too, just in case the master key somehow got reused.) You won't need to store this info string anywhere, since you can just store the IV derived using it instead. The primary advantage to using this method, instead of just using random IVs, is that it protects you from the (small but non-zero) risk of system RNG failure. Of course, if you want, you can also still include a bunch of random bits in the info string used to derive the IVs, too.

Note that, per NIST SP 800-38D section 8.3, you should not encrypt more than $2^{32}$ files with GCM mode using the same key and random IVs. This is to keep the risk of IV collision sufficiently small. If you do find yourself needing to encrypt more files than that at once, probably the easiest way to sidestep the limit is just to re-derive a new master key from the hashed password with a different salt. That means re-running scrypt, but doing that every $2^{32}$ files is probably not a significant performance issue.

A more significant limit, in practice, is the SP 800-38D section 5.2.1.1 also limits the length of files encrypted with AES-GCM to less than $2^{39}-256$ bits = 64 GiB (minus 32 bytes, to be exact). If you ever need to encrypt a file longer than that with GCM, you'll need to break it into shorter segments and combine them with something like the CHAIN construction from this paper.

As for other issues, one potential concern is that using the same master key derived from the same salt for multiple files, and storing the salt unencrypted in the file itself, makes it possible to see if two files have been encrypted by the same user at the same time. That might be an unwanted information leak.

Unfortunately there's no easy way to fix that, unless you can store the salt somewhere else (where?), use a different salt for each file (which makes encryption slower, since you'd need to re-run scrypt for each file) or omit the salt entirely (which is not recommended, as it makes your scheme vulnerable to attacks using precomputed password &lrarr; scrypt(password) tables). Still, at the very least, you should clearly inform your users of it, and maybe provide an option to use a new salt for each file, at the cost of performance.

Generally you should be fine with having a minimum size of 128 bits and a maximum size of 256 bits for parameters such as salts. Although you should halve the security parameter because of the birthday problem, I think most cryptographers would still choose 256 bits salts as maximum.

It is unlikely that the birthday problem can be used to enhance the security beyond the, say 192 bit security it offers after about $2^{64}$ files. So you would have a very large margin with 256 bits. Salts are sometimes even set to 64 bits - for instance in the OpenSSL command line for encryption - but like anything of 64 bits, that may be on the low side by now.

WRT the security of the construction rather than the salt size

Beware that advertising a security strength of 256 bits for password based encryption is rather insincere. Passwords commonly have a security strength far below 64 bits. Even a strong key strengthening function such as scrypt will not add significant strength to this.

Such issues may be partially resolved by using public key encryption where the public key is used for encryption and the private decryption key may be kept in an less accessible location until it is used. That private key may need to be wrapped as well, possibly with a scheme such as specified in the question. OpenPGP is an (old) format that could be described this way.