[Cryptography] [RNG] on RNGs, VM state, rollback, etc.

[Viktor Dukhovni]

On Sat, Oct 19, 2013 at 05:22:55PM -0400, Jeffrey I. Schiller wrote:

> That is a value judgment, one where you let security be more important
> than anything else. That is a mistake.
> 
> There are plenty of applications where it is better to have things
> work then to have them not work in the name of security. Consider an
> embedded controller running a critical resource (like your heart
> pacemaker). It is better to have it fail by using poor entropy then to
> fail completely and leave you dead.

Indeed.

Some years back a few brave users of Postfix attempted to use the
GnuTLS OpenSSL API compatibility layer to run Postfix over GnuTLS.

It was found that the GnuTLS library would call exit() if it did
not find an entropy on startup instead of returning an error to
the application.  This approach was deemed safer by GnuTLS.  When
this was discovered, Postfix dropped support for the GnuTLS OpenSSL
emulation.  From the TLS_README file:

    NOTE: Do not use Gnu TLS.  It will spontaneously terminate a
    Postfix daemon process with exit status code 2, instead of
    allowing Postfix to 1) report the error to the maillog file,
    and to 2) provide plaintext service where this is appropriate.

I don't know whether this has changed since, but I concur that the
security/availability tradeoff is not always clear-cut.

As for RNG use, Postfix does not use the RNG at boot time.  The
tlsmgr(8) process is started when TLS is first used, in addition
to periodic seeding from /dev/urandom, it keeps its own persistent
seed file across restarts.  Each SMTP server or client process gets
initial and periodic seed material from tlsmgr(8) and stirs a few
bits of randomness between connections.  If /dev/urandom were
configurable to block at boot time, that would likely be tolerable
in most cases, as the first use of TLS with SMTP will likely happen
late enough for enough entropy to have been accumulated for tlsmgr(8)
to get (IIRC) 32 bytes of seed material.

-- 
	Viktor.