Acquire Entropy for embedded platform
rgm at htt-consult.com
Fri Aug 16 12:22:17 UTC 2019
On 8/16/19 5:44 AM, Dr Paul Dale wrote:
> I investigated HAVEGE fairly deeply a couple of years ago. I am
> completely in agreement with the basis of this source, however the
> sticking point was the “expansion” phase. Essentially, every bit of
> entropy gathered is turned into (just under) thirty two bits of
> “entropy”. This is logically and physically impossible. As a source,
> it appears reasonable to the usual tests (i.e. dieharder), although
> TestU01 <https://en.wikipedia.org/wiki/TestU01> does pick up on it
> being less than ideal.
> I would, however, recommend Stephan Müller's CPU Jitter
> <https://www.chronox.de/jent/doc/CPU-Jitter-NPTRNG.html>. The
> gathering is well researched and performed, no hidden tricks are
> present and the bits produces are equiprobable.
Thanks. I will take a look at CPU Jitter. Entropy can be an issue on
some of my armv7 boards. I run CentOS on them, so all I need to find
are rpms for something to test it out...
> Dr Paul Dale | Distinguished Architect | Cryptographic Foundations
> Phone +61 7 3031 7217
> Oracle Australia
>> On 16 Aug 2019, at 7:31 pm, Robert Moskowitz <rgm at htt-consult.com
>> <mailto:rgm at htt-consult.com>> wrote:
>> On 8/16/19 5:26 AM, Chitrang Srivastava wrote:
>>> I am working on an embedded platform and now ported openssl 1.1.1b
>>> TLS 1.2/1.3 is working fine.
>>> While analysing random number , Rand pool initialization calls where
>>> I am returning like this ,
>>> size_t *rand_pool_acquire_entropy*(RAND_POOL *pool)
>>> return rand_pool_entropy_available(pool);
>>> As noticed that *rand_unix.c* has an implementation wcih samples 2
>>> bits of RTC, would that give enough entropy or any other
>>> recommendation to have enough entropy for embedded platforms?
>> Check out: https://issihosts.com/haveged
>> I talk about it here:
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the openssl-users