[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@xxxxxxxxx
<mailto:chitrang.srivastava@xxxxxxxxx>> 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,
Enjoy
Jakob
--
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
