Speading up key generation

NIIBE Yutaka gniibe at fsij.org
Mon May 9 03:34:22 CEST 2016


On 05/07/2016 07:20 PM, Rick van Rein wrote:
> I do like the idea of harvesting CPU-internal data, but do not feel free
> of worries about this implementation style.  There should be a more
> accurate model of its entropy before I'd trust it.  But once it has
> this, the principle might expand to include much more probably switches,
> such as through multiple processes or threading.
[...]
> I'm curious if anyone has different opinions on this!

If there is no other sources, it is good to use haveged.  I think that
haveged implementations depends on CPU and something like High
Precision Event Timer (HPET), but user would just use haveged with no
HPET system, or even on a VM.

While harvesting CPU-internal data is convenient, it would be
controversial.  It would be easier for attackers to maliciously
control the key generation when it's not external source.

I use my own TRNG for my key generation.

    Let's Make "NeuG USB Device" by STM32 Nucleo F103, together:
    http://www.fsij.org/gnuk/neug-on-stm32-nucleo-f103.html
-- 



More information about the Gnupg-users mailing list