Random Numbers Turn Out to Be a Whole Damn Subsystem
I expected to spend an afternoon on random numbers. I spent a lot longer than an afternoon on random numbers, because it turns out trustworthy entropy is genuinely its own subsystem, not a library call.
I went into this expecting a fairly boring afternoon: get a random-number source working, wire it up, move on to something more interesting. That is not how it went, and in hindsight I should have seen it coming, because "random numbers you can actually trust" is a much bigger commitment than "random numbers that look random."
Why this needed its own subsystem instead of a library call
A single, central SecureRandom authority sits behind a proper DRBG — a deterministic random bit generator seeded from real entropy, not a quick call to whatever the standard library happens to expose. Consumers throughout Ceylon don't read raw entropy themselves; they go through SecureRandom, get output for a specific typed purpose, and never touch the underlying entropy pool directly.
Readiness is an explicit, checked state, not an assumption. If the entropy source isn't ready, or isn't trustworthy yet, the system fails closed — consumers that need randomness they can actually stand behind do not get handed something that merely looks plausible instead. That's a deliberately harder requirement than most systems bother enforcing, and it's exactly why this turned into its own subsystem instead of a two-line wrapper.
Purpose typing, and why reboot behavior needed its own rule
Different consumers get typed purposes rather than one undifferentiated "give me a random number" call, so the system has an honest, checkable record of what a given piece of randomness was actually used for. And reboot and state-loss behavior needed explicit rules of their own — what's allowed to persist across a restart, what must not persist, and what has to be freshly reseeded before anything is allowed to trust it again.
Built hardware-neutral, tested against a virtual source
The whole authority is architected to be hardware-neutral rather than tied to one specific entropy source, and for actual development and testing it currently runs against a virtual entropy source rather than a specific physical hardware RNG — consistent with the whole "reference machine first" discipline that's shown up throughout this journal since the QEMU entry. This isn't the part of the system I'm going to publish specifics of key material, internal state, or anything genuinely security-sensitive about — that's a hard line for obvious reasons, same as not naming the microkernel.
What I will say is: I did not expect "random numbers" to turn into one of the more architecturally serious subsystems on the whole platform. It did. And it's not even the last surprise entropy-adjacent work had for me this summer — the actual debugging story is next, and it's a genuinely good one.
Originally published on The Weekend Report: https://theweekendersproject.com/report/random-numbers-turn-out-to-be-a-whole-damn-subsystem