Received-SPF: pass (google.com: domain of linux-crypto-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
MIME-Version: 1.0
References: <CACXcFm=-E_wnDdRPztKJwDo8hvt6ENf84D90iFUXReuw2s0kuQ@mail.gmail.com>
 <378733E4-D976-4E2D-BE14-AD900C901CE8@callas.org>
In-Reply-To: <378733E4-D976-4E2D-BE14-AD900C901CE8@callas.org>
From:   Sandy Harris <sandyinchina@gmail.com>
Date:   Sun, 3 Oct 2021 15:04:56 +0800
Message-ID: <CACXcFm=40HCSvhkagsFn0WFnjrjbhk+Ah7Y=3tfFf5xxOW6A8g@mail.gmail.com>
Subject: Re: [Cryptography] [RFC] random: add new pseudorandom number generator
To:     Jon Callas <jon@callas.org>
Cc:     Linux Crypto Mailing List <linux-crypto@vger.kernel.org>,
        Cryptography <cryptography@metzdowd.com>,
        "Ted Ts'o" <tytso@mit.edu>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

Jon Callas <jon@callas.org> wrote:

> > On Sep 16, 2021, at 20:18, Sandy Harris <sandyinchina@gmail.com> wrote:
> >
> > I have a PRNG that I want to use within the Linux random(4) driver. It
> > looks remarkably strong to me, but analysis from others is needed.
>
> A good block cipher in counter mode makes a pretty-okay PRNG. I say prett=
y-okay only because I would like my PRNG not to be invertible.

I'm using counter mode inside an Even-Mansour XOR-permutation-XOR
structure which, among other things, makes it non-invertible.

> Iterated hash functions are better. However, they are slower, and a prope=
rty you want in a PRNG is that it's fast. I did a system PRNG that was inte=
ntionally faster than arc4random() and close to linear-congruential because=
 then there's no excuse for not using it. A mildly evil person would replac=
e both of those with a fast real PRNG. (Mildly evil because if some user kn=
ew the internals and was counting on it acting the way the internals specif=
ied, they might be disappointed.)

I'm doing this within the Linux random(4) driver which iterates chacha
to generate output. This prng will only generate values for internal
use, like rekeying chacha or dumping data into the input pool. In
fact, if an instruction like Intel RDRAND or a hardware rng exist the
code mostly uses those, only injecting xtea output once in a while to
avoid tructing the other source completely or falling back to xtea if
the other fails.

> XTEA is an okay block cipher. Not great, okay. Probably good enough for a=
 PRNG.

With the Even-Mansour construction it seems good enough to me. Code
includes this comment:

 * Even and Mansour proved proved a lower bound
 * for an XOR-permutation-XOR sequence.
 * S. Even, Y. Mansour, Asiacrypt 1991
 * A Construction of a Cipher From a Single Pseudorandom Permutation
 *
 * For an n-bit cipher and D known or chosen plaintexts,
 * time T to break it is bounded by DT >=3D 2^n.
 *
 * This applies even if the enemy knows the permutation,
 * for a block cipher even if he or she knows the key.
 * All the proof requires is that the permutation be
 * nonlinear.
 *
 * The main calling function does a full rekey (update
 * key, mask and counter) when xtea_iterations >=3D 127
 * We therefore have D ~=3D 2^7 and T >=3D 2^57 to break
 * each sequence of 127 outputs between rekeyings.
 *
 * Assuming proper keying and that the enemy cannot
 * peek into the running kernel, this can be
 * considered effectively unbreakable, even if
 * xtea itself were found to be flawed.

> But -- why wouldn't you use AES? An obvious answer is that you don't have=
 it in hardware ...

I wanted something that would be reasonably fast on anything Linux
runs on & wanted to avoid using kernel memory for the S-box & round
keys.