lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Message-ID: <CA+_SqcBkR_8Z9EUTpK-dEW4PN+9P5OgJnqYDHtOhG+P1LjotPA@mail.gmail.com> Date: Tue, 6 Aug 2019 13:43:27 -0700 From: Paul Crowley <paulcrowley@...gle.com> To: Eric Biggers <ebiggers@...nel.org> Cc: linux-fscrypt@...r.kernel.org, linux-ext4@...r.kernel.org, linux-f2fs-devel@...ts.sourceforge.net, linux-mtd@...ts.infradead.org, linux-fsdevel@...r.kernel.org, linux-crypto@...r.kernel.org, keyrings@...r.kernel.org, linux-api@...r.kernel.org, Satya Tangirala <satyat@...gle.com>, "Theodore Ts'o" <tytso@....edu>, Jaegeuk Kim <jaegeuk@...nel.org> Subject: Re: [PATCH v8 12/20] fscrypt: add an HKDF-SHA512 implementation On Mon, 5 Aug 2019 at 09:28, Eric Biggers <ebiggers@...nel.org> wrote: > > From: Eric Biggers <ebiggers@...gle.com> > > 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 <tytso@....edu> > Signed-off-by: Eric Biggers <ebiggers@...gle.com> Looks good, feel free to add: Reviewed-by: Paul Crowley <paulcrowley@...gle.com>
Powered by blists - more mailing lists