Coming up in this year’s CCS is a paper with the provocative subtitle `/dev/random`

is not Robust,

and thanks to widespread availability of online preprints, it’s already scored quite a bit of online attention, e.g. at Bruce Schneier’s blog and on Hacker News.

I’m going to pass over the alleged attacks on the Linux kernel CSPRNG, which are adequately covered in both of the above discussions; suffice it to say that in this paper robust

is a precisely defined theoretical security property, and there’s a solid case that it’s stronger than necessary to guarantee *practical* security. What I’m interested in is the simple and very efficient PRNG construction that is provably robust,

advertised in the abstract. CSPRNG-robustness (as defined here) may not be *necessary* for practical security, but if you can have it essentially for free, *why wouldn’t you* adopt it? Unfortunately it turns out that there’s a major palmed card in their definition of a CSPRNG with input,

and another one in the construction itself, rendering the algorithm useless in practice.

The first problem is that the definition of a CSPRNG with input includes a setup

phase that produces a *random seed which is not known to the adversary*. Despite consistently calling this item a public parameter,

the text of the paper makes it clear that it must not be known to the adversary, and they consider this both essential and unproblematic:

Unfortunately, it is well known that no deterministic extractor is capable to simultaneously extract good randomness from *all* efficiently samplable high-entropy distributions (e.g. consider nearly full entropy distribution $I$ which is random, except the first bit of $\mathrm{Extract}(I)$ is zero).

… [Therefore], we chose … to assume the existence of the `setup`

procedure … this will allow one to consider a *seeded* extractor … which can now extract entropy from *all* high-entropy distributions. As a warning, this nice extra generality comes at a price that the [seed] is not passed to the [adversarial] distribution sampler …

But this is impossible to achieve in real life. If the seed is generated on the device that will use it, we have a chicken-and-egg problem, because initial startup is precisely when environmental randomness is least available; the authors should have been aware of actual, catastrophic exploits of systems with little or no access to randomness on first boot, e.g. Mining your Ps and Qs.

If the seed is *not* generated on the device that will use it, then the adversary can probably learn it; in particular, if the seed for all devices of a particular model is embedded in a firmware image that anyone can download off the manufacturer’s website, you have accomplished precisely nothing.

The second problem is in the technical details of their proposed CSPRNG construction, which I will now quote verbatim.

Let $\mathbf{\text{G}}:\{0,1{\}}^{m}\to \{0,1{\}}^{n+l}$ be a (deterministic) pseudorandom generator where $m<n$. We use the notation $[y{]}_{1}^{m}$ to denote the first $m$ bits of $y\in \{0,1{\}}^{n}$. Our construction of PRNG with input has parameters $n$ (state length), $l$ (output length), and $p=n$ (sample length), and is defined as follows:

- $\mathrm{setup}:$ Output $\mathrm{\text{seed}}=(X,{X}^{\prime})\leftarrow \{0,1{\}}^{2n}$.
- ${S}^{\prime}=\mathrm{refresh}(S,I):$ Given $\mathrm{\text{seed}}=(X,{X}^{\prime})$, current state $S\in \{0,1{\}}^{n}$, and a sample $I\in \{0,1{\}}^{n}$, output ${S}^{\prime}=S\cdot X+I$, where all operations are over ${\mathbb{\text{\mathbb{F}}}}_{{2}^{n}}$.
- $({S}^{\prime},R)=\mathrm{next}(S):$ Given $\mathrm{\text{seed}}=(X,{X}^{\prime})$ and a state $S\in \{0,1{\}}^{n}$, first compute $U=[{X}^{\prime}\cdot S{]}_{1}^{m}$. Then output $({S}^{\prime},R)=\mathbf{\text{G}}(U)$.

It’s a blink-and-you-miss-it sort of thing: by all operations are over ${\mathbb{\text{\mathbb{F}}}}_{{2}^{n}}$

they are specifying that both the refresh

and next

steps make use of arithmetic over finite, nonprime fields (more usually referred to as $\mathrm{GF}({2}^{n})$ in crypto literature). $n$ has to be large—section 6.1 of the paper suggests specific fields with $n$ = 489, 579, and 705. The known techniques for this kind of arithmetic are all very slow, require large look-up tables (and therefore permit side-channel attacks), or cannot be used for a software implementation. [1] [2] This makes them impractical for a cryptographic component of an operating system that cannot rely on special-purpose hardware.

Both problems arise from the same source, namely wanting to build the algorithm around a keyed hash so that the entropy extractor is fully general, and then taking a mathematical construct with convenient *theoretical* but inconvenient *practical* properties as that hash. If we back down to the use of an *unkeyed*, but computationally secure, hash as the entropy extractor, we’d have to redo the analysis, but I think it ought to be possible to arrange that, *without* any secret unknown to the adversary, it is still computationally infeasible for the adversary to bias the entropy pool; and we could then pick that hash for its practical utility.

… Oddly enough, this hypothetical construction looks an awful lot like the existing Linux CSPRNG.