On 31/05/2018 19:14, Jochen Bern wrote:
On 05/31/2018 03:03 PM, openssl-users-requ...@openssl.org distributed:
Date: Thu, 31 May 2018 18:45:02 +1000
From: FooCrypt <open...@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.g...@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
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
