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
* Honestly, I’d like to add CPU Jitter to OpenSSL as one of its default
entropy sources.
* I dread the effort that this would entail.
Open an issue and maybe someone with an older platform will work on doing it.
I don’t think the project has any need to support such things. (Members of
Not just dedicated black box rngs in verious chips (such as
multifunction I/O chips or the old Intel BIOS chip), but also
general hardware that happens to have plenty of inherent
randomness due to its design or implementation.
The simple easy to add RNG circuits include some completely
open
I agree. Using internal hardware in the processor for entropy depends on
everything. Each processor needs to be independently quantified and not doing
so becomes a risk assessment.
As for hardware sources, they are essentially black boxes and could contain
anything. It is extremely
from the git repo of cpu jitter i see few files only so may be easy to
compile at least.
Yeah it can be added to openssl source with macro to enable it.
On Fri, Aug 16, 2019 at 4:05 PM Dr Paul Dale wrote:
> Honestly, I’d like to add CPU Jitter to OpenSSL as one of its default
> entropy
[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
Thanks Pauli,
I did checked CPU Jitter and it looks promising. It has openssl engine
support too.
So i guess I have to add this add provide OS specific calls and it should
work.
Will keep you posted.
Thanks,
On Fri, Aug 16, 2019 at 3:15 PM Dr Paul Dale wrote:
> I investigated HAVEGE fairly
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
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,
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
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
11 matches
Mail list logo
