[Cryptography] OpenSSL CSPRNG work

Natanael natanael.l at gmail.com
Sun Jul 2 14:11:43 EDT 2017


Den 2 juli 2017 19:40 skrev "Florian Weimer" <fw at deneb.enyo.de>:


I'm leaning towards AES-128 in CTR mode with a per-process key, a
global counter, and per-thread counters and output blocks (so around
20 bytes of TLS storage, instead of >176 bytes if we stored an AES key
schedule for every thread).  We'd probably put the per-process key in
non-dumpable memory.  Fork safety is somewhat easier for us than for
others because we can directly invalidate the per-process key from the
fork implementation.  (Clone safety is more complicated.)  Seeding is
still tricky, of course.  [...]
Proper reseeding after fork will be complicated if getrandom is not
available; we'll probably do something theoretically unsound in that
case (and tell people to use a fixed kernel if they dislike this), or
use a MAP_SHARED mapping to maintain counters shared across processes.


Seems reasonable enough at a first glance.

Most *sane* VM:s / hypervisors / other virtualizating load distribution
mechanisms that can fork / clone software instances should have API:s for
provisioning unique entropy to every instance as soon as its created /
forked. I believe this is often implemented via a kernel driver in the
guest OS, and where possible you should tap into this to as quickly as
possible replace all cloned seeds.

Every time a new instance of *anything* that needs unique private entropy
is spawned, it needs to aquire this entropy in some safe way before
continuing with anything security sensitive.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20170702/a35e6104/attachment.html>


More information about the cryptography mailing list