[Cryptography] RNG design principles

[John Gilmore]

> The seed is passed to the kernel via a UEFI configuration table,
> which is a standard mechanism for the firmware to expose information
> to the OS. This data is not visible outside of the kernel, unless it
> is explicitly exported.

The UEFI table seems as good a way as any to pass this info.

What are the specs for the "random" seed that is passed in?

It would be best if the interface distinguished the output of a True
Random Number Generator (TRNG) from the output of a keyed
cryptographic pseudo random number generator (PRNG).  [For the same
reason that RDRAND and RDSEED are two different opcodes.]

Is this table an appropriate way to pass a system-unique seed (that
doesn't change from reboot to reboot, but which makes this system
unique from every other system or VM that was installed with identical
OS software)?

Is this table also an appropriate way to pass a TRNG output that was
freshly generated just microseconds ago during the boot process?  If
a system had more than one of such values (e.g. a system-unique seed and
one or more local TRNG outputs) then how should that system configure
this UEFI table parameter?  Should it appear multiple times in the
table, should the table entries be concatenated, etc?

The patch itself

  https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/commit/?id=636259880a7e7d3446a707dddebc799da94bdd0b

says:
> Since UEFI configuration tables may also be consumed by kexec'd
> kernels, register a reboot notifier that updates the seed in the
> table.

The reboot notifier uses get_random_bytes() to overwrite the seed
shortly before a kexec.  The result is that even if the seed was
originally TRNG output, at this point it becomes a less useful PRNG
output.  It might be better to XOR the new random data into the prior
seed, so that if it was truly random it would not lose that property.

Or would it be better if the kernel destroyed the seed in RAM
immediately after consuming it?  That way, malware that arrives later
and escalates its privileges can't poke around main memory to see what
the initial seed was.  If so, the kernel should perhaps replace the
seed with fresh random data once it thinks it has plenty of locally
generated entropy (e.g. seconds or minutes later), and mark whether
that data is from a TRNG or PRNG.

	John