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;
Content-Type: text/plain;
        charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\))
Subject: Re: [Cryptography] [RFC] random: add new pseudorandom number
 generator
From:   Jon Callas <jon@callas.org>
In-Reply-To: <CACXcFm=40HCSvhkagsFn0WFnjrjbhk+Ah7Y=3tfFf5xxOW6A8g@mail.gmail.com>
Date:   Sun, 3 Oct 2021 14:28:36 -0700
Cc:     Jon Callas <jon@callas.org>,
        Linux Crypto Mailing List <linux-crypto@vger.kernel.org>,
        Cryptography <cryptography@metzdowd.com>,
        Ted Ts'o <tytso@mit.edu>
Content-Transfer-Encoding: quoted-printable
Message-Id: <AA432273-13B7-4592-8137-3EB566850A59@callas.org>
References: <CACXcFm=-E_wnDdRPztKJwDo8hvt6ENf84D90iFUXReuw2s0kuQ@mail.gmail.com>
 <378733E4-D976-4E2D-BE14-AD900C901CE8@callas.org>
 <CACXcFm=40HCSvhkagsFn0WFnjrjbhk+Ah7Y=3tfFf5xxOW6A8g@mail.gmail.com>
To:     Sandy Harris <sandyinchina@gmail.com>
Precedence: bulk


> On Oct 3, 2021, at 00:04, Sandy Harris <sandyinchina@gmail.com> wrote:
>=20
> I'm using counter mode inside an Even-Mansour XOR-permutation-XOR
> structure which, among other things, makes it non-invertible.
>=20

And also takes care of other quibbles that were rattling around in my =
head.=20

>=20
> 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.

Then the constraints are even better. If that output isn't directly =
exposed, it can be a bit sloppier.=20

>=20
>> XTEA is an okay block cipher. Not great, okay. Probably good enough =
for a PRNG.
>=20
> With the Even-Mansour construction it seems good enough to me. [...]

Yeah, I was thinking it would be direct output. If it's direct output, =
then a ciphertext-only attack on the cipher is an attack on the PRNG. =
The way you're using it, it's a cheap way to provide another safety net. =
Remember, though, that E-M assumes a PRP, and many breaks on ciphers =
imply that it's not a PRP, and yet you don't care about any of that. =
Sounds fine to me.


>> But -- why wouldn't you use AES? An obvious answer is that you don't =
have it in hardware ...
>=20
> 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.

The speed aspect on low-end CPUs is what I was thinking of. Most =
importantly, you are doing something inside the whole box, so it doesn't =
even really need full pseudorandomness.=20

Overall, sounds fine to me.

	Jon