Re: Start up entropy gathering

2019-06-13 Thread Kurt Roeckx
On Thu, Jun 13, 2019 at 05:06:16PM +1000, Dr Paul Dale wrote:
> 
> The second suggestion is broadly similar but requires a file containing 
> entropy that persists across reboots.  This alternative requires a more 
> management: the entropy file once read needs to be rewritten immediately (and 
> ideally on shutdown as well).  It also introduces a new attack vector against 
> the entropy storage.  It also isn’t possible to skip the entropy file 
> read/rewrite sequence because it is impossible to determine if /dev/urandom 
> has actually been seeded.  I’ve not attempted to code this, persistent files 
> containing seed material potentially introduce other problems.

This is what init systems have always done. I see no need to also
do it. They have a policy not to credit that the entropy from that
file, I see no reason why we should override that policy.


Kurt



Start up entropy gathering

2019-06-13 Thread Dr Paul Dale
Topic: The OpenSSL 3.0.0 release will include mitigation for the low entropy on 
boot and first boot problems.
Comment: PR#9084 removed such mitigation due to the negative side effects.

This vote has passed (two for, four abstain, none against):


The discussion now needs to turn to how this can be done.

The mitigation is for older Linux kernels only (and perhaps old Unix machines 
of other flavours).  So no Windows, getentropy(3), ….


I have a suggestion.  Two kind of.

Use a volatile mechanism for communicating between processes — a file in /tmp, 
a block of shared memory or whatever.
On system boot, the first instance of libcrypto that attempts to read 
/dev/urandom, first locks the shared resource and reads one byte from 
/dev/random.  It uses the shared resource to indicate that the read was 
successful and continues seeding from /dev/urandom.
Other instances of libcrypto start up, see that the shared resource is properly 
initialised and go straight to using /dev/urandom.
On system shutdown/reboot, the communication mechanism disappears and the 
entire process will repeat on the next boot.
There are some fine details but this is the gist of it.

This is more difficult to describe than code: see #9152 
.


Notes:

1. Reading the byte from /dev/random avoid problems on systems that cannot 
select(2) on /dev/random.

2. Early start up of /libcrypto will block until entropy is available (and 
consume eight bits of same).  Later starts have the overhead of the locking and 
resource access.  Importantly, no entropy will be drained from the system pool 
after start up.



The second suggestion is broadly similar but requires a file containing entropy 
that persists across reboots.  This alternative requires a more management: the 
entropy file once read needs to be rewritten immediately (and ideally on 
shutdown as well).  It also introduces a new attack vector against the entropy 
storage.  It also isn’t possible to skip the entropy file read/rewrite sequence 
because it is impossible to determine if /dev/urandom has actually been seeded. 
 I’ve not attempted to code this, persistent files containing seed material 
potentially introduce other problems.


Pauli
-- 
Dr Paul Dale | Cryptographer | Network Security & Encryption 
Phone +61 7 3031 7217
Oracle Australia