[cryptography] Entropy improvement: haveged + rngd together?

Stephan Mueller smueller at chronox.de
Thu Nov 28 09:42:29 EST 2013


Am Donnerstag, 28. November 2013, 15:36:59 schrieb Fabio Pietrosanti:

Hi Fabio,

> Greetings,
> 
> following the answer on thread on the HAVEGE algorithm as an additional
> entropy source, at GlobaLeaks Project we are evaluating whenever not to
> add also "rngd" that's said to be able to use other "hardware entropy
> source" chipset ( Intel/AMD/VIA), available on the motherboard (Target
> OS: Linux)
> 
> I'd like to ask a couple of questions:
> - Will "haveged" and "rngd" works well together in additionally feeding
> the entropy pool, or they will conflict somehow?

They will not conflict as they use an IOCTL on /dev/random for injecting 
data. The code behind the IOCTL is able to handle even concurrent 
injections. So, multiple gatherers are ok.

Though, bear in mind that you may not want inject entropy from one noise 
source via multiple paths. E.g. the Intel RDRAND instruction IS picked up 
by /dev/random and should therefore not used by rngd.

> - Isn't Linux Kernel already using the internal cryptographic chip on
> it's own, if available?

Hardly. Intel RDRAND is currently the only chip used in /dev/random. Even 
though, the use is very limited (the output of /dev/random is XORed with 
an equally sized string from RDRAND).

Any other hardware RNGs have drivers -- drivers/char/hw_random/* -- but 
they export their interface only to user space via /dev/hw_random. This 
interface is automatically sourced by rngd and injected into /dev/random. 
So, you see that these hardware RNGs can only be used via user space, even 
though kernel drivers make them available.
> 
> The GlobaLeaks target is to avoid requiring any additional hardware to
> maintain the deployment process simple and the technical requirements
> cheap, so we're not focusing on external entropy source.
> 
> That entropy improvement is going to be used for the already existing
> PGP operations done on files.


Ciao
Stephan
-- 
| Cui bono? |


More information about the cryptography mailing list