[openssl-users] PRNG is not seeded

Jakob Bohm jb-openssl at wisemo.com
Sun Jun 3 23:23:20 UTC 2018


On 31/05/2018 19:14, Jochen Bern wrote:
> On 05/31/2018 03:03 PM, openssl-users-request at openssl.org distributed:
>> Date: Thu, 31 May 2018 18:45:02 +1000
>> From: FooCrypt <openssl at foocrypt.net>
>>
>> Place a teaspoon of fine grade white sand onto the skin of a snare drum
> Macroscopic hardware TRNGs are a *tad* yesteryear
>
> https://en.wikipedia.org/wiki/Lavarand
>
> because observing *quantum* random events doesn't require large devices
>
> https://en.wikipedia.org/wiki/Hardware_random_number_generator
>
> (not to mention being IIUC harder to influence by an attacker so as to
> make them lose randomness). Nonetheless, if you don't have the hardware
> (builtin TPM?) and cannot easily connect one to the given platform (as I
> suspect for the OP's architecture) ...
>
> For general computing platforms, I've taken to installing (and, of
> course, running and monitoring) haveged as a standard - on hosts *and*
> VMs. It can run in an AIS-31 test mode if you want to check out the
> entropy it collects.
>
> https://wiki.archlinux.org/index.php/Haveged
 From what I have seen, haveged seems highly bogus, with no significant
arguments as to how their method gathers anything other than a highly
indirect and obfuscated form of process statistics.  The wording used
in their design summaries suggests they confuse "not documented outside
the CPU design team" with "random and unpredictable".

Haveged might be able to indirectly apply statistics of internal states
in other processes, but that seems about it.

The best alternative I have tried so far is to use what little entropy
is available to connect to a trusted (self-owned) machine that serves
TRNG bits over a variant of the EGD protocol, then using those bits to
handle other randomness needs.  The key benefit here is that the trusted
TRNG machine will contribute a lot of entropy to its own TLS connection,
and the independence from any ability to mess with the architectural
limitations of the receiving machine.

>>> On 31 May 2018, at 6:07 PM, chris.gray at kiffer.be wrote:
>>> I've also encountered this quite often, and I have a feeling that on
>>> today's connected devices there may be a lot of entropy "in the air"
>>> (quite literally) which is not being captured. Does any one know of
>>> research in this area?
> Not specifically for mobile phones or WiFi interfaces, if that's what
> you're referring to with "in the air". However, squeezing available
> entropy out of various less-than-predictable hardware and OS states is
> what *all* non-hardware entropy gatherers ultimately do, from the Linux
> kernel's /dev/random mechanisms to haveged to what-have-you.
>
> Regards,
>
>

Enjoy

Jakob
-- 
Jakob Bohm, CIO, Partner, WiseMo A/S.  http://www.wisemo.com
Transformervej 29, 2860 Soborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded



More information about the openssl-users mailing list