From: Eric Biggers <ebiggers3@gmail.com>
To: "Jason A. Donenfeld" <Jason@zx2c4.com>
Cc: David Howells <dhowells@redhat.com>,
Theodore Ts'o <tytso@mit.edu>,
Linux Crypto Mailing List <linux-crypto@vger.kernel.org>,
LKML <linux-kernel@vger.kernel.org>,
kernel-hardening@lists.openwall.com,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
David Miller <davem@davemloft.net>,
Herbert Xu <herbert@gondor.apana.org.au>,
Stephan Mueller <smueller@chronox.de>
Subject: Re: [kernel-hardening] Re: [PATCH v3 04/13] crypto/rng: ensure that the RNG is ready before using
Date: Tue, 6 Jun 2017 10:26:43 -0700 [thread overview]
Message-ID: <20170606172643.GC88445@gmail.com> (raw)
In-Reply-To: <CAHmME9rTpe4FM2+VSxZB48JDPCNTpSWzHx2DW1om7DW_1PvttQ@mail.gmail.com>
Hi Jason,
On Tue, Jun 06, 2017 at 05:23:04PM +0200, Jason A. Donenfeld wrote:
> Hey again Eric,
>
> One thing led to another and I wound up just rewriting all the crypto
> in big_keys.c. I'll include this for v4:
>
> https://git.zx2c4.com/linux-dev/commit/?h=jd/rng-blocker&id=886ff283b9808aecb14aa8e397da8496a9635aed
>
> Not only was the use of crypto/rng inappropriate, but the decision to
> go with aes-ecb is shocking. Seeing that this author had no other
> commits in the tree, and that all subsequent commits that mentioned
> his name were cleaning up his mess, I just went ahead and removed both
> the crypto/rng misusage and changed from aes-ecb to aes-gcm.
>
> Anyway, I'll wait for some more reviews on v3, and then this can be
> reviewed for v4.
>
> Regards,
> Jason
I agree that the use of ECB mode in big_key is broken, and thanks for trying to
fix it! I think using GCM is good, but please leave a very conspicuous comment
where the nonce is being set to 0, noting that it's safe only because a unique
key is used to encrypt every big_key *and* the big_keys are not updatable (via
an .update method in the key_type), resulting in each GCM key being used for
only a single encryption.
Also, I think you should send this to the keyrings mailing list and maintainer
so it can be discussed and merged separately from your RNG changes.
Eric
next prev parent reply other threads:[~2017-06-06 17:26 UTC|newest]
Thread overview: 41+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-06-06 0:50 [PATCH v3 00/13] Unseeded In-Kernel Randomness Fixes Jason A. Donenfeld
2017-06-06 0:50 ` [PATCH v3 01/13] random: add synchronous API for the urandom pool Jason A. Donenfeld
2017-06-06 0:50 ` [PATCH v3 02/13] random: add get_random_{bytes,u32,u64,int,long,once}_wait family Jason A. Donenfeld
2017-06-06 5:11 ` Jeffrey Walton
2017-06-06 12:21 ` Jason A. Donenfeld
2017-06-06 0:50 ` [PATCH v3 03/13] random: invalidate batched entropy after crng init Jason A. Donenfeld
2017-06-07 17:42 ` kbuild test robot
2017-06-07 18:16 ` Jason A. Donenfeld
2017-06-06 0:50 ` [PATCH v3 04/13] crypto/rng: ensure that the RNG is ready before using Jason A. Donenfeld
2017-06-06 3:00 ` Theodore Ts'o
2017-06-06 3:56 ` Jason A. Donenfeld
2017-06-06 4:44 ` [kernel-hardening] " Eric Biggers
2017-06-06 12:34 ` Jason A. Donenfeld
2017-06-06 15:23 ` Jason A. Donenfeld
2017-06-06 17:26 ` Eric Biggers [this message]
2017-06-06 17:30 ` Jason A. Donenfeld
2017-06-06 17:03 ` Theodore Ts'o
2017-06-06 17:28 ` Jason A. Donenfeld
2017-06-06 17:57 ` Stephan Müller
2017-06-06 18:01 ` Jason A. Donenfeld
2017-06-06 22:19 ` Henrique de Moraes Holschuh
2017-06-06 23:14 ` Theodore Ts'o
2017-06-07 5:00 ` Stephan Müller
2017-06-07 14:42 ` Henrique de Moraes Holschuh
2017-06-07 21:27 ` [kernel-hardening] " Theodore Ts'o
2017-06-07 17:00 ` Daniel Micay
2017-06-07 17:26 ` Mark Rutland
2017-06-08 3:59 ` Daniel Micay
2017-06-07 17:37 ` Mark Rutland
2017-06-08 12:02 ` Kevin Easton
2017-06-06 0:51 ` [PATCH v3 05/13] security/keys: ensure RNG is seeded before use Jason A. Donenfeld
2017-06-06 0:51 ` [PATCH v3 06/13] iscsi: " Jason A. Donenfeld
2017-06-06 0:51 ` [PATCH v3 07/13] ceph: ensure RNG is seeded before using Jason A. Donenfeld
2017-06-06 0:51 ` [PATCH v3 08/13] cifs: use get_random_u32 for 32-bit lock random Jason A. Donenfeld
2017-06-06 0:51 ` [PATCH v3 09/13] rhashtable: use get_random_u32 for hash_rnd Jason A. Donenfeld
2017-06-06 0:51 ` [PATCH v3 10/13] net/neighbor: use get_random_u32 for 32-bit hash random Jason A. Donenfeld
2017-06-06 0:51 ` [PATCH v3 11/13] net/route: use get_random_int for random counter Jason A. Donenfeld
2017-06-06 0:51 ` [PATCH v3 12/13] bluetooth/smp: ensure RNG is properly seeded before ECDH use Jason A. Donenfeld
2017-06-06 0:51 ` [PATCH v3 13/13] random: warn when kernel uses unseeded randomness Jason A. Donenfeld
2017-06-06 10:08 ` [PATCH v3 05/13] security/keys: ensure RNG is seeded before use David Howells
2017-06-06 12:23 ` Jason A. Donenfeld
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20170606172643.GC88445@gmail.com \
--to=ebiggers3@gmail.com \
--cc=Jason@zx2c4.com \
--cc=davem@davemloft.net \
--cc=dhowells@redhat.com \
--cc=gregkh@linuxfoundation.org \
--cc=herbert@gondor.apana.org.au \
--cc=kernel-hardening@lists.openwall.com \
--cc=linux-crypto@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=smueller@chronox.de \
--cc=tytso@mit.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).