[cryptography] Entropy improvement: haveged + rngd together?
smueller at chronox.de
Thu Nov 28 09:42:29 EST 2013
Am Donnerstag, 28. November 2013, 15:36:59 schrieb Fabio Pietrosanti:
> 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.
| Cui bono? |
More information about the cryptography