Re: [Cryptography] [RFC] random: add new pseudorandom number generator

> On Oct 3, 2021, at 00:04, Sandy Harris <[email protected]> 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