On Mon, 5 Aug 2019 at 09:28, Eric Biggers <[email protected]> wrote:
>
> From: Eric Biggers <[email protected]>
>
> Add an implementation of HKDF (RFC 5869) to fscrypt, for the purpose of
> deriving additional key material from the fscrypt master keys for v2
> encryption policies. HKDF is a key derivation function built on top of
> HMAC. We choose SHA-512 for the underlying unkeyed hash, and use an
> "hmac(sha512)" transform allocated from the crypto API.
>
> We'll be using this to replace the AES-ECB based KDF currently used to
> derive the per-file encryption keys. While the AES-ECB based KDF is
> believed to meet the original security requirements, it is nonstandard
> and has problems that don't exist in modern KDFs such as HKDF:
>
> 1. It's reversible. Given a derived key and nonce, an attacker can
> easily compute the master key. This is okay if the master key and
> derived keys are equally hard to compromise, but now we'd like to be
> more robust against threats such as a derived key being compromised
> through a timing attack, or a derived key for an in-use file being
> compromised after the master key has already been removed.
>
> 2. It doesn't evenly distribute the entropy from the master key; each 16
> input bytes only affects the corresponding 16 output bytes.
>
> 3. It isn't easily extensible to deriving other values or keys, such as
> a public hash for securely identifying the key, or per-mode keys.
> Per-mode keys will be immediately useful for Adiantum encryption, for
> which fscrypt currently uses the master key directly, introducing
> unnecessary usage constraints. Per-mode keys will also be useful for
> hardware inline encryption, which is currently being worked on.
>
> HKDF solves all the above problems.
>
> Reviewed-by: Theodore Ts'o <[email protected]>
> Signed-off-by: Eric Biggers <[email protected]>
Looks good, feel free to add:
Reviewed-by: Paul Crowley <[email protected]>