Acquire Entropy for embedded platform
jb-openssl at wisemo.com
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 gmail.com
>> <mailto:chitrang.srivastava at gmail.com>> 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?
Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com
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