Acquire Entropy for embedded platform

Jakob Bohm jb-openssl at
Fri Aug 16 10:42:02 UTC 2019

[Top posting for consistency]

More than OS dependency, this depends on the exact hardware on the platform:
CPU, support chips, peripheral chips.   Usually some of these can provide
much more randomness than the highly predictable time of day/year RTC clock.
  And if none do, there are simple RNG hardware designs that could be added
in a corner of the circuit, either on a plugin board or as part of a board
already customized to the application.

On 16/08/2019 11:33, Dr Paul Dale wrote:
> Two bits of RTC is nowhere near enough entropy.  I could break two 
> bits by hand in a few seconds — there are only four possibilities.
> The best outcome is an hardware random number generator.  These are 
> often not readily available.
> Next would be waiting for enough entropy from interrupts, timers and 
> the like.
> You didn’t specify what operating system/kernel you are using so 
> further advise is less than useful.
>> On 16 Aug 2019, at 7:26 pm, Chitrang Srivastava 
>> <chitrang.srivastava at 
>> <mailto:chitrang.srivastava at>> 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?
>> Thanks,


Jakob Bohm, CIO, Partner, WiseMo A/S.
Transformervej 29, 2860 Søborg, 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