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

Jon Callas jon at callas.org
Sun Oct 3 17:28:36 EDT 2021

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


More information about the cryptography mailing list