Re: Acquire Entropy for embedded platform

2019-08-16 Thread Robert Moskowitz 



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 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.


Thanks.  I will take a look at CPU Jitter.  Entropy can be an issue on 
some of my armv7 boards.  I run CentOS on them, so all I need to find 
are rpms for something to test it out...





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 > 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

Re: Acquire Entropy for embedded platform

2019-08-16 Thread Salz, Rich via openssl-users 
  *   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 the 
project working for companies, perhaps)

Re: Acquire Entropy for embedded platform

2019-08-16 Thread Jakob Bohm via openssl-users 

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 discrete designs if that's desired.

On 16/08/2019 12:53, Dr Paul Dale wrote:
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 difficult, if not impossible, to 
tell if the hardware RNG is good or not.  This doesn’t mean that they 
should not be used, it just means that using them involves another 
risk assessment.




On 16 Aug 2019, at 8:42 pm, Jakob Bohm via openssl-users 
mailto:openssl-users@openssl.org>> wrote:


[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 
 
> 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?





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

Re: Acquire Entropy for embedded platform

2019-08-16 Thread Dr Paul Dale 
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 difficult, if not impossible, to tell if the 
hardware RNG is good or not.  This doesn’t mean that they should not be used, 
it just means that using them involves another risk assessment.


Pauli
-- 
Dr Paul Dale | Distinguished Architect | Cryptographic Foundations 
Phone +61 7 3031 7217
Oracle Australia




> On 16 Aug 2019, at 8:42 pm, Jakob Bohm via openssl-users 
>  wrote:
> 
> [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 
>>> mailto:chitrang.srivast...@gmail.com>> 
>>> 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
>

Re: Acquire Entropy for embedded platform

2019-08-16 Thread Chitrang Srivastava 
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 sources.
> I dread the effort that this would entail.
>
> Pauli
> --
> Dr Paul Dale | Distinguished Architect | Cryptographic Foundations
> Phone +61 7 3031 7217
> Oracle Australia
>
>
>
>
> On 16 Aug 2019, at 8:28 pm, Chitrang Srivastava <
> chitrang.srivast...@gmail.com> wrote:
>
> 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 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  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
>>
>>
>>
>>
>

Re: Acquire Entropy for embedded platform

2019-08-16 Thread Jakob Bohm via openssl-users 

[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 
> 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

Re: Acquire Entropy for embedded platform

2019-08-16 Thread Dr Paul Dale 
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.

Pauli
-- 
Dr Paul Dale | Distinguished Architect | Cryptographic Foundations 
Phone +61 7 3031 7217
Oracle Australia




> On 16 Aug 2019, at 8:28 pm, Chitrang Srivastava 
>  wrote:
> 
> 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 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 > > 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 
>> 
>> 
>> 
>

Re: Acquire Entropy for embedded platform

2019-08-16 Thread Chitrang Srivastava 
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 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  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
>
>
>
>

Re: Acquire Entropy for embedded platform

2019-08-16 Thread Dr Paul Dale 
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  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 
> 
> 
>

Re: Acquire Entropy for embedded platform

2019-08-16 Thread Dr Paul Dale 
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.


Pauli
-- 
Dr Paul Dale | Distinguished Architect | Cryptographic Foundations 
Phone +61 7 3031 7217
Oracle Australia




> On 16 Aug 2019, at 7:26 pm, 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?
> 
> Thanks,
> 
> 
> 
> 
>

Re: Acquire Entropy for embedded platform

2019-08-16 Thread Robert Moskowitz 



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

Acquire Entropy for embedded platform

2019-08-16 Thread Chitrang Srivastava 
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,