On Thu, Feb 10, 2022 at 10:38:28PM +0800, Sandy Harris wrote:
> Add a pseudorandom generator based on the xtea cipher
>
> This will be used only within the kernel, mainly within the driver
> to rekey chacha or dump extra random data into the input pool.
>
> It needs a 64-bit output to match arch_get_random_long(), and
> the obvious way to get that is a 64-bit block cipher.
I'm not convinced the proposed use case is worth the complexity it
adds. Our current use for arch_get_random_[seed_] is to add extra
hardware-generated random which is cheap (compared to using external
sources such as virtio_rng or a USB attached hardware number
generator). If it doesn't exist, we fall back to using the CPU cycle
counter (if present) because it's cheap. But if none of this exists,
the source of entropy used to reseed the CRNG or the timing data into
input pool is supposed to be sufficient. So RDSEED, RDLONG, or the
TSC (using the x86 facilities for example) are a nice-to-have not a necessity.
The TEA code path is not going to be used much on 99% of the systems
out there, and even it is used, on those systems which don't have
RDSEED, RDLONG, etc., there's not going to be anything to initialize
the pseudo-random number generator, so I fear it will be considered
security theatre. Fundamentally, it's another CRNG that is supposed
to be only used for the kernel, and is it really worth it?
- Ted
