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

[Jon Callas]

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

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

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

> 
>> 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. [...]

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

Overall, sounds fine to me.

	Jon