linux-kernel - Re: [PATCH v6] security/keys: rewrite all of big

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAHmME9pvZ-Q8qoUGjQjXX_DYNVv43C7MJRDzKZAAotM5UZircA@mail.gmail.com>
Date:   Wed, 20 Sep 2017 12:52:21 +0200
From:   "Jason A. Donenfeld" <Jason@...c4.com>
To:     Stephan Mueller <smueller@...onox.de>
Cc:     linux-security-module@...r.kernel.org, keyrings@...r.kernel.org,
        kernel-hardening@...ts.openwall.com,
        LKML <linux-kernel@...r.kernel.org>,
        David Howells <dhowells@...hat.com>,
        Eric Biggers <ebiggers3@...il.com>,
        Herbert Xu <herbert@...dor.apana.org.au>,
        Kirill Marinushkin <k.marinushkin@...il.com>,
        security@...nel.org, stable@...r.kernel.org
Subject: Re: [PATCH v6] security/keys: rewrite all of big_key crypto

On Wed, Sep 20, 2017 at 7:30 AM, Stephan Mueller <smueller@...onox.de> wrote:
> The use of GCM with the implementtion here is just as challenging. The
> implementation uses a NULL IV. GCM is a very brittle cipher where the
> construction of the IV is of special importance. SP800-38D section 8.2.1 and
> 8.2.2 outlines the generation methods of the IV. A collision of keys/IVs is
> fatal. I understand that keys are generated anew each time which makes that
> issue less critical here. However, as user space may see the ciphertext, GCM
> should simply not be used.

This sounds incorrect to me.  Choosing a fresh, random, one-time-use
256-bit key and rolling with a zero nonce is a totally legitimate way
of using GCM. There's no possible reuse of the key stream this way.
However, on the off chance that you know what you're talking about,
could you outline the cryptographic attack you have in mind, or if
that's too difficult, simply link to the relevant paper on eprint?