Re: Acquire Entropy for embedded platform

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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 does pick up on it being less than ideal.

I would, however, recommend Stephan Müller's CPU Jitter.  The gathering is well researched and performed, no hidden tricks are present and the bits produces are equiprobable.


Pauli
-- 
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@xxxxxxxxxxxxxxx> wrote:



On 8/16/19 5:26 AM, Chitrang Srivastava wrote:
Hi,

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:    http://www.htt-consult.com/CentOS7-armv7.html#RANDOMNESS




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux