If your system is too small to be able to persist 32 bytes, it's probably too small to perform any amount of meaningful cryptography anyway.
There are absolutely devices with exclusively RO media with plenty of processing power to perform meaningful crypto (e.g., embedded devices with 802.11 wifi). So:
> If your system is too small to be able to persist 32 bytes, it's probably too small to perform any amount of meaningful cryptography anyway.
This sentence is not based in reality.
Don't most microcontrollers have some EEPROM that could be used for this? I'm assuming even 4 bytes would help a lot. I am pretty sure STM32's with hardware crypto have EEPROM good for a million write cycles.
Linux has lots and lots of hardware specific drivers. This shouldn't be any different.
The current way of gathering initial entropy should not be the default, it should be a fallback. If a device have neither persistent storage (32 bytes for crying out loud) nor a hardware random generator, they should be treated like second class citizen, with only best effort random numbers.
Right now, everyone is a second class citizen. Kind of insane, don't you think?
> it's not as trivial as you paint it
It is, under one (extremely hard to fulfil) condition: collaboration from hardware vendors. It's just 32 persistent bytes. Just bury them in a chip and memory map the damn thing! The driver can be reduced to an offset.
> I think jitterentropy is a better and more easily tested use of developer hours than implementing 1000s of SoC drivers
That one? https://fuchsia.dev/fuchsia-src/zircon/jitterentropy/config-...
It's one of the first links I found, I hope it is obsolete: they say the internal state of Jitterentropy is puny 64 bits number. What were they thinking, we need four times as much! That kind of thing is why people are tempted to shed the system's RNG, and ask users to wiggle their mouse instead.
> That one? https://fuchsia.dev/fuchsia-src/zircon/jitterentropy/config-....
> It's one of the first links I found, I hope it is obsolete: they say the internal state of Jitterentropy is puny 64 bits number
You skimmed too quickly and came to a judgement based on a misreading or misunderstanding of the concept. Obviously 64 bits is not sufficient.
The idea of the jitter entropy mechanism is that most modern CPUs have super high resolution clock or cycle counters available (even embedded boards), and instruction execution speed has mild variance.
You run a series of trials, each of which produces one or more bits of output (classically: 1). You run as many as you want, producing an infinite stream of weak entropy, until you have collected a satisfactory number of output bits. Trials can be run relatively quickly (many nanoseconds or a handful of milliseconds per trial).
For each trial, you perform some minimal workload intended to exacerbate CPU runtime variance (this might be where you saw "64 bits"), and extract some number of output bits (maybe 1) from one or more of: the low bits of the cyclecounter, nanosecond clock, or something similar of that nature.
Caveat: jitter is an even weaker entropy source than most non-HWRNG sources typically consumed by entropy gatherers. Your motto of "just 256 bits" assumes total independence and 8 bits per byte of entropy. It isn't met by most real-world entropy sources on server systems (expect 4-5 bits/byte) and especially not by jitter entropy. Empirically, jitter seems to come closer to 1 bit per byte minimum in SP800-90B evaluations on the raw output — it's a pretty weak entropy source.
Anyway: feel free to read more about the concept at any of the sources. The Fuschia writeup you linked is a good one if you read it more closely; there's also:
* From the original (2013) proponent, Stephan Mueller: description: http://www.chronox.de/jent.html and sources: https://github.com/smuellerDD/jitterentropy-library
* LWN's 2015 writeup of the concept as a Linux entropy source: https://lwn.net/Articles/642166/
* And this is all suddenly topical due to the latest nonsense from Linus (TFA, 2019), who still does not understand CSPRNGs. Anyway, Linus wrote and merged a version of jitter entropy quite recently: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin... This is a relatively happy outcome in that Linus didn't just break the ABI to be completely insecure by default.
Yes of course. This is easily obtained by hashing a much bigger input. The problem is determining how big the input should be. That is, how much entropy it actually holds. You can also hash piecemeal (H is whatever you think is secure):
H0 = H(I0)
H1 = H(I1 || H0)
H2 = H(I2 || H1)
H3 = H(I3 || H2)
> Anyway, Linus wrote and merged a version of jitter entropy quite recently. […] This is a relatively happy outcome in that Linus didn't just break the ABI to be completely insecure by default.
I'm genuinely relieved. This would have been the worst way to break userspace. Still, tiny embedded systems might need to persist (properly seeded) 32 bytes instead of relying on jitter entropy.
Well, those devices are flawed. Unless they have special hardware to generate random numbers? I mean, the ability to generate random number is such a basic feature. If your communication hardware doesn't have it, your communication hardware is crap, and that's the end of it.
I maintain what I said: if a system is big enough to do crypto, it is big enough to persist 32 bytes. When you can process a 64-byte Chacha20 block in RAM, you can spare 32 bytes of EEPROM or flash. I think this is reasonable enough to be "grounded in reality".
That said, of course many devices out there are so badly designed that even though they're powerful enough to process elliptic curves (and I presume the entire Linux kernel), they don't even have enough persistent memory to store 256 bits of entropy, and they don't have a reliable, fast way to generate 256 bits of entropy. Stupidity is a thing, I know.
Acknowledging such stupidly designed devices is of course very important. We do what we can with what we have. But let's not go the C standard route, and use that stupidity as an excuse to never use persistent state or random generation instructions. Let's use the capabilities of our platforms, dammit.
For instance, that stupid WiFi router is not an excuse to not persist state on a freaking desktop. (Or laptop. Or palmtop. Or R-Pi. Or virtualised server. Etc.)