[Cryptography] Security of Ubuntu RNG pollinate?

John Gilmore gnu at toad.com
Mon Nov 21 16:01:19 EST 2016

Dustin Kirkland wrote a randomness client and server for feeding
Ubuntu virtual machines that don't have good randomness sources, which
is now a standard feature in Ubuntu since 14.04 Cloud instances.  See:


This now runs on the first boot of the virtual machine, before the
scripts that create the machine's SSH host keys, for example.  The
idea is to improve the unpredictability of those keys.  In theory this
is a good idea.

I am wondering just how hard this would be for NSA or another passive
attacker to break.

I looked briefly at the client code.  The client, pollinate, is a
shell wrapper around curl (which does an http or https access).  The
protocol is an HTTP or HTTPS POST access, passing "challenge=" and a
sha512 hash of (by default) 64 bytes of "random"(*) data as a nonce.
It passes a User-Agent value that includes the exact software versions
of pollinate, curl, and cloud-init, as well as identifying the Ubuntu
release, Linux kernel version, and CPU type.  The result of the access
is a sha512 hash of whatever was passed, and some random data.  The
client checks that the hash matches, then hashes the entire response
as well as some debug and microsecond packet timing info, and writes
that hash of the response to /dev/urandom.  The code is shipped with
the certificate of host "entropy.ubuntu.com" and by default makes an
HTTPS access to it, checking via the certificate that it hasn't been

My initial concern is that the entire transaction is visible to

Since the entire problem is that the host has little or no actual
randomness, the "random" nonce is not only probably not random, but
actually lets NSA validate their guess about the initial state of the
kernel RNG.  Similarly, the User-Agent string lets NSA determine
exactly what software is running in the system.  Example:

  User-Agent: pollinate/4.23-0ubuntu1~14.04 curl/7.35.0-1ubuntu2.9 cloud-init/ Ubuntu/14.04.5/LTS GNU/Linux/3.16.0-77-generic/i686 AMD/Athlon(tm)/64/X2/Dual/Core/Processor/3800+

Is there really any point in passing this detailed system info, EXCEPT
to help an attacker, rather than just using curl's standard User-Agent
("curl/7.35.0")?  A recent change *also* adds the platform uptime and
idle time "to help detect abuse"!  See:


Do we agree that if the transaction used plaintext HTTP, and if NSA
happened to be capturing those packets, then NSA would be able to read
the non-random nonce and the truly random response, and then model the
effect of the pollination on the kernel RNG, thus knowing how to
predict future "random" numbers from that kernel?

(The transaction uses TCP, which uses kernel randomness to produce
the client's initial sequence number, thus giving NSA another check
against their model of the kernel's random pool.)

However, the transaction uses "secure" HTTPS.  But since this HTTPS
connection has no reliable source of randomness to draw upon, an
eavesdropper can break Diffie-Hellman by guessing the non-random
"random" value retained by the client in the HTTPS negotiation.  (The
server's nonce in response is available to both the client and the
eavesdropper.)  Thus I suspect that an eavesdropper can look inside
the poorly secured HTTPS transaction and see the plaintext.  And thus
the eavesdropper can predict future "random" numbers from the client's
kernel -- like those used to generate the host's private key for SSH.

What am I missing?

An additional security issue is that this command is apparently run
just once, at system startup, in a just-installed machine that's
running a bare Ubuntu release.  It tells the eavesdropper exactly what
release is running, and also tells them the IP address of a brand-new
virtual machine that has never yet seen any security updates since the
release was cut.  Merely monitoring the IP addresses of accesses to
entropy.ubuntu.com will notify any intelligence agency of great target
machines to deploy a zero-day or already-fixed attack against.  If
they spend the effort to crack the HTTPS transaction, they also find
out its exact configuration, but probably the IP address is good
enough for most nefarious purposes.

(Of course, the passage of time after the access to entropy.ubuntu.com
will increase the likelihood of known security holes becoming patched.
And passage of time will also increase the likelihood that the kernel
random number generator's state will evolve in ways that increase the
search space enough to make it infeasible to model the kernel RNG
state.  But how much time?  Minutes, days, weeks, years?  I don't
think anyone except NSA has tried to calibrate this against actual
virtual machines.  Know any grad students looking for a security

I think that pollinate only runs by default in the Cloud Ubuntu
images, so it won't report to NSA that you have just installed a
brand-new unpatched desktop or server Ubuntu release.  However there
are other default Internet accesses in brand-new machines, e.g. for
timezone lookups, the initial apt-get update, or Firefox's initial
access to the Google web blacklist database that gives you an initial
Google cookie before your Firefox window has even finished painting on
the screen, that probably do make them pretty easy to identify, if you
know where to wiretap.

Can anyone confirm or deny these suspicions of mine?

And how would one improve the pollinate protocol or implementation, if
possible, to improve its resilience against these attacks?


More information about the cryptography mailing list