seeding randomness in zee cloud

Dirk-Willem van Gulik dirkx at webweaving.org
Fri May 31 10:26:56 UTC 2013


Thanks to a badly-written mngt script - we've rencently noticed a freshly generated ssh-key on a new AWS instances to be indentical to one seen a few months prior. 

Careful analysis of some other logs showed that we've had similar clashes on another script just after startup generating a very short x509 CSR. It happens quite rarely though. But still.

I am surmising that perhaps the (micro-T) images do not have that much entropy on startup.

So I am wondering how to best make our images 'more random' -- and want to avoid the linux/openstack suggestion[1] of doing this through the boot-params [2] (as in our
case it is the operator of the machine we're protecting/guarding against accusations/temptations).

Now we happen to have very easy access to blocks of 1024bits of randomness from a remote server in already nicely PKI signed packages (as it is needed later for something else).

Is it safe to simply *add* those with:

	set -1
	# fetch randomness & check signature
	.. snipped...

	# Seed Software random generator
	#
	cat rnd > /dev/random

	# Activate software random generator as an additional source
	sysctl kern.random.sys.harvest.swi=1

Or does this cause a loss/reset of all entropy gathered by the hardware sofar ? Or is there a cleaner way to add a additional seed as a one-off with disturbing as little as possible (in the few seconds just after the network is brought up).
	
Thanks,

Dw.

FWIIW: this is the output of sysctl kern.random.

kern.random.yarrow.gengateinterval: 10
kern.random.yarrow.bins: 10
kern.random.yarrow.fastthresh: 192
kern.random.yarrow.slowthresh: 256
kern.random.yarrow.slowoverthresh: 2
kern.random.sys.seeded: 1
kern.random.sys.harvest.ethernet: 1
kern.random.sys.harvest.point_to_point: 1
kern.random.sys.harvest.interrupt: 1
kern.random.sys.harvest.swi: 0

1: http://blog.dustinkirkland.com/2012/10/entropy-or-lack-thereof-in-openstack.html
2: https://review.openstack.org/#/c/14550/


More information about the freebsd-hackers mailing list