PRNG is not seeded

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
20 messages Options
Reply | Threaded
Open this post in threaded view
|

PRNG is not seeded

Scott Neugroschl-2

Hi,

 

I’m using PRNGD to seed my random numbers (I’m on a system without /dev/random and /dev/urandom).   I occasionally get the dreaded “PRNG is not seeded” error.

 

I know this is caused by a lack of available entropy in the system; but what can I do to address this?  Is it just a matter of waiting until enough entropy has been collected?  Is there any kind of workaround?

 

Thanks

 

ScottN

 


--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: PRNG is not seeded

OpenSSL - User mailing list

>I know this is caused by a lack of available entropy in the system; but what can I do to address this?  Is it just a matter of waiting until enough entropy has been collected?  Is there any kind of workaround?

 

Assuming you don’t have another source of randomness that you can add in, then you should wait.  IF you don’t, you run the risk that your random numbers (session keys, RSA or other long-term keys, etc) could be guessed by an attacker.

 


--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: PRNG is not seeded

FooCrypt
In reply to this post by Scott Neugroschl-2
Hi Scott

I don’t know your OS or environment, have you tried the ‘openssl rand’ functionality as a random source to seed your entropy issues ?

openssl rand 102400 > some named pipe file that you can call as your random source.

perhaps rather than pseudo random, try a hardware device ?



> On 30 May 2018, at 8:58 AM, Scott Neugroschl <[hidden email]> wrote:
>
> Hi,
>  
> I’m using PRNGD to seed my random numbers (I’m on a system without /dev/random and /dev/urandom).   I occasionally get the dreaded “PRNG is not seeded” error.
>  
> I know this is caused by a lack of available entropy in the system; but what can I do to address this?  Is it just a matter of waiting until enough entropy has been collected?  Is there any kind of workaround?
>  
> Thanks
>  
> ScottN
>  
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: PRNG is not seeded

Michael Wojcik
> From: openssl-users [mailto:[hidden email]] On Behalf
> Of FooCrypt
> Sent: Tuesday, May 29, 2018 21:41
> To: [hidden email]
> Subject: Re: [openssl-users] PRNG is not seeded
>
> > On 30 May 2018, at 8:58 AM, Scott Neugroschl <[hidden email]>
> wrote:
> >
> > I’m using PRNGD to seed my random numbers (I’m on a system without
> > /dev/random and /dev/urandom).   I occasionally get the dreaded “PRNG is
> > not seeded” error.
>
> I don’t know your OS or environment, have you tried the ‘openssl rand’
> functionality as a random source to seed your entropy issues ?

Where would openssl rand be getting its entropy from, in this case? You have a circular dependency: openssl needs entropy, so it tries to get it from PRNGD; and you're asking openssl to put entropy into PRNGD.

> perhaps rather than pseudo random, try a hardware device ?

Now, this is a case where you might use openssl rand, in conjunction with engine, to get entropy from another source. That could be a useful hack if you can't easily change PRNGD or the application to read entropy from the device.

For example, I think I successfully used openssl with the pkcs11 engine to get entropy from a NitroKey device a couple of years back, when I was playing around with cheap HSMs.

Whether something like the NitroKey (which is an inexpensive USB-attached HSM in a thumbdrive form factor) would be useful in this case is something Scott would have to determine.

If it is, it'd be cleaner if he could change the application to load the pkcs11 engine and use its RNG directly, or at least get entropy from it to seed OpenSSL's PRNG.

> > I know this is caused by a lack of available entropy in the system; but what
> > can I do to address this?  Is it just a matter of waiting until enough entropy
> > has been collected?  Is there any kind of workaround?

Depends on what sources PRNGD uses (I haven't looked), what the device is, what the application is... If the device has sensors you can read, you might be able to gather some entropy by reading noise from them (though this is somewhat fraught - you don't want to overestimate the amount of entropy, and both sensors and sensor APIs are often vulnerable to attack).

Sometimes applications ask users to generate some entropy by asking them to  bang on the keyboard or wiggle the mouse, or that sort of thing. Again, it really depends on what your device and application are.

This topic is discussed at some length in the technical literature; see for example section 3 of RFC 4086.

--
Michael Wojcik
Distinguished Engineer, Micro Focus



--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: PRNG is not seeded

FooCrypt

> On 30 May 2018, at 11:55 PM, Michael Wojcik <[hidden email]> wrote:
>
>> From: openssl-users [mailto:[hidden email]] On Behalf
>> Of FooCrypt
>> Sent: Tuesday, May 29, 2018 21:41
>> To: [hidden email]
>> Subject: Re: [openssl-users] PRNG is not seeded
>>
>>> On 30 May 2018, at 8:58 AM, Scott Neugroschl <[hidden email]>
>> wrote:
>>>
>>> I’m using PRNGD to seed my random numbers (I’m on a system without
>>> /dev/random and /dev/urandom).   I occasionally get the dreaded “PRNG is
>>> not seeded” error.
>>
>> I don’t know your OS or environment, have you tried the ‘openssl rand’
>> functionality as a random source to seed your entropy issues ?
>
> Where would openssl rand be getting its entropy from, in this case? You have a circular dependency: openssl needs entropy, so it tries to get it from PRNGD; and you're asking openssl to put entropy into PRNGD.
>

Usage: rand [options] num
where options are
-out file             - write to file
-engine e             - use engine e, possibly a hardware device.
-rand file:file:... - seed PRNG from files
-base64               - base64 encode output
-hex                  - hex encode output


RAND(1) describes the multiplicity of sources that can all be used together in some detail.

DESCRIPTION
       The rand command outputs num pseudo-random bytes after seeding the random number generator once.  As in other openssl command line tools, PRNG seeding uses the file
       $HOME/.rnd or .rnd in addition to the files given in the -rand option.  A new $HOME/.rnd or .rnd file will be written back if enough seeding was obtained from these sources.

ls -la ~/.rnd
        -rw-------  1 XXXXX  XXXXX  1024 30 May 10:45 .rnd

Make some .rnd’s

        dd if=/dev/[SOMEDEVICE] of=~/.rnd bs=1 count=1024

Make an engine

        Microphones work wonders and you can play with the sound, count, etc….etc….etc...

>> perhaps rather than pseudo random, try a hardware device ?
>
> Now, this is a case where you might use openssl rand, in conjunction with engine, to get entropy from another source. That could be a useful hack if you can't easily change PRNGD or the application to read entropy from the device.
>
> For example, I think I successfully used openssl with the pkcs11 engine to get entropy from a NitroKey device a couple of years back, when I was playing around with cheap HSMs.
>
> Whether something like the NitroKey (which is an inexpensive USB-attached HSM in a thumbdrive form factor) would be useful in this case is something Scott would have to determine.
>
> If it is, it'd be cleaner if he could change the application to load the pkcs11 engine and use its RNG directly, or at least get entropy from it to seed OpenSSL's PRNG.
>
>>> I know this is caused by a lack of available entropy in the system; but what
>>> can I do to address this?  Is it just a matter of waiting until enough entropy
>>> has been collected?  Is there any kind of workaround?
>
> Depends on what sources PRNGD uses (I haven't looked), what the device is, what the application is... If the device has sensors you can read, you might be able to gather some entropy by reading noise from them (though this is somewhat fraught - you don't want to overestimate the amount of entropy, and both sensors and sensor APIs are often vulnerable to attack).
>
> Sometimes applications ask users to generate some entropy by asking them to  bang on the keyboard or wiggle the mouse, or that sort of thing. Again, it really depends on what your device and application are.
>
> This topic is discussed at some length in the technical literature; see for example section 3 of RFC 4086.
>
> --
> Michael Wojcik
> Distinguished Engineer, Micro Focus
>
>
>
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: PRNG is not seeded

Michael Wojcik
> From: openssl-users [mailto:[hidden email]] On Behalf
> Of FooCrypt
> Sent: Wednesday, May 30, 2018 10:46
> To: [hidden email]
> Subject: Re: [openssl-users] PRNG is not seeded
>
> > On 30 May 2018, at 11:55 PM, Michael Wojcik
> <[hidden email]> wrote:
> >
> > Where would openssl rand be getting its entropy from, in this case? You
> have a circular dependency: openssl needs entropy, so it tries to get it from
> PRNGD; and you're asking openssl to put entropy into PRNGD.
> >
>
> Usage: rand [options] num

Spare me, please.

> RAND(1) describes the multiplicity of sources that can all be used together in
> some detail.

And why do you think this solves the problem?

>        The rand command outputs num pseudo-random bytes after seeding the
> random number generator once.

So all the entropy you can get from the output of "openssl rand" is whatever OpenSSL was able to gather when it seeded the PRNG. Which is exactly the problem Scott was trying to solve.

> Make some .rnd’s

YOU STILL HAVE TO FIND ENTROPY TO PUT IN THEM. All you're doing is pushing the problem around the plate.

>
>       dd if=/dev/[SOMEDEVICE] of=~/.rnd bs=1 count=1024

Where [SOMEDEVICE] is your magical unicorn entropy device?

> Make an engine

I already mentioned the engine interface in my previous response. And if this is an option for Scott, it would be much better to use the engine in his application, rather than going through the rigamarole of running "openssl rand" to grab some entropy from it. The command-line utility is useful iff he can't change the application.

>       Microphones work wonders

No, they really don't. Look at the literature. (And, again, I mentioned sensors in my previous response.)

> and you can play with the sound, count,
> etc….etc….etc...

Cargo-cult entropy gathering. It may be fine under a given threat model, but we have no idea what Scott's is. As general advice it's poor.

--
Michael Wojcik
Distinguished Engineer, Micro Focus



--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: PRNG is not seeded

Scott Neugroschl-2
In reply to this post by Michael Wojcik
>>> I’m using PRNGD to seed my random numbers (I’m on a system without
>>> /dev/random and /dev/urandom).   I occasionally get the dreaded “PRNG is
>>> not seeded” error.
>>
>> I don’t know your OS or environment, have you tried the ‘openssl rand’
>> functionality as a random source to seed your entropy issues ?
>
>Where would openssl rand be getting its entropy from, in this case? You have a circular dependency: openssl needs entropy, so it tries to get it from PRNGD; and you're asking openssl to put entropy into PRNGD.
>
>> perhaps rather than pseudo random, try a hardware device ?
>
>Now, this is a case where you might use openssl rand, in conjunction with engine, to get entropy from another source. That could be a useful hack if you can't easily change PRNGD or the application to read entropy from the device.
>
>For example, I think I successfully used openssl with the pkcs11 engine to get entropy from a NitroKey device a couple of years back, when I was playing around with cheap HSMs.
>
>Whether something like the NitroKey (which is an inexpensive USB-attached HSM in a thumbdrive form factor) would be useful in this case is something Scott would have to determine.
>
>If it is, it'd be cleaner if he could change the application to load the pkcs11 engine and use its RNG directly, or at least get entropy from it to seed OpenSSL's PRNG.
>
>>> I know this is caused by a lack of available entropy in the system;
>>> but what can I do to address this?  Is it just a matter of waiting
>>> until enough entropy has been collected?  Is there any kind of workaround?
>
>Depends on what sources PRNGD uses (I haven't looked), what the device is, what the application is... If the device has sensors you can read, you might be able to gather some entropy by reading noise from them (though this is somewhat fraught - you don't want to overestimate the amount of entropy, and both sensors and sensor APIs are often vulnerable to attack).
>
>Sometimes applications ask users to generate some entropy by asking them to  bang on the keyboard or wiggle the mouse, or that sort of thing. Again, it really depends on what your device and application are.
>
>This topic is discussed at some length in the technical literature; see for example section 3 of RFC 4086.
>

The platform in question is an HPE NonStop.


--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: PRNG is not seeded

FooCrypt
In reply to this post by Michael Wojcik

> On 31 May 2018, at 1:35 AM, Michael Wojcik <[hidden email]> wrote:
>
>> From: openssl-users [mailto:[hidden email]] On Behalf
>> Of FooCrypt
>> Sent: Wednesday, May 30, 2018 10:46
>> To: [hidden email]
>> Subject: Re: [openssl-users] PRNG is not seeded
>>
>>> On 30 May 2018, at 11:55 PM, Michael Wojcik
>> <[hidden email]> wrote:
>>>
>>> Where would openssl rand be getting its entropy from, in this case? You
>> have a circular dependency: openssl needs entropy, so it tries to get it from
>> PRNGD; and you're asking openssl to put entropy into PRNGD.
>>>
>>
>> Usage: rand [options] num
>
> Spare me, please.
>
>> RAND(1) describes the multiplicity of sources that can all be used together in
>> some detail.
>
> And why do you think this solves the problem?

Well its HP’s problem, not openssl’s

>
>>       The rand command outputs num pseudo-random bytes after seeding the
>> random number generator once.
>
> So all the entropy you can get from the output of "openssl rand" is whatever OpenSSL was able to gather when it seeded the PRNG. Which is exactly the problem Scott was trying to solve.
>
>> Make some .rnd’s
>
> YOU STILL HAVE TO FIND ENTROPY TO PUT IN THEM. All you're doing is pushing the problem around the plate.

generate them on another host

>
>>
>>      dd if=/dev/[SOMEDEVICE] of=~/.rnd bs=1 count=1024
>
> Where [SOMEDEVICE] is your magical unicorn entropy device?

well its not /dev/random, its a HPE NonStop with no entropy that stops the application.


>
>> Make an engine
>
> I already mentioned the engine interface in my previous response. And if this is an option for Scott, it would be much better to use the engine in his application, rather than going through the rigamarole of running "openssl rand" to grab some entropy from it. The command-line utility is useful iff he can't change the application.

HPE NonStops don’t have DTrace

>
>>      Microphones work wonders
>
> No, they really don't. Look at the literature. (And, again, I mentioned sensors in my previous response.)
>
>> and you can play with the sound, count,
>> etc….etc….etc...
>
> Cargo-cult entropy gathering. It may be fine under a given threat model, but we have no idea what Scott's is. As general advice it's poor.

Probably financial sector, with PCI compliance and they can;t afford /dev/random or /dev/urandom


>
> --
> Michael Wojcik
> Distinguished Engineer, Micro Focus
>
>
>
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: PRNG is not seeded

Richard Levitte - VMS Whacker-2
In reply to this post by Scott Neugroschl-2
In message <[hidden email]> on Wed, 30 May 2018 15:37:47 +0000, Scott Neugroschl <[hidden email]> said:

scott_n> The platform in question is an HPE NonStop.

NonStop isn't the only platform with this sort of problem...  I'd
suggest asking in places dedicated to NonStop if they know of good
enough ways to gather enough entropy, such as comp.sys.tandem,
perhaps?

Either way, trying to use OpenSSL's PRNGD to seed OpenSSL's PRNGD is
an exercise in futility.

Cheers,
Richard

--
Richard Levitte         [hidden email]
OpenSSL Project         http://www.openssl.org/~levitte/
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: PRNG is not seeded

Scott Neugroschl-2

> Either way, trying to use OpenSSL's PRNGD to seed OpenSSL's PRNGD is an exercise in futility.

Oh, I agree on that.  


--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: PRNG is not seeded

Chris Gray-4
In reply to this post by FooCrypt
I've also encountered this quite often, and I have a feeling that on
today's connected devices there may be a lot of entropy "in the air"
(quite literally) which is not being captured. Does any one know of
research in this area?

> Hi Scott
>
> I don’t know your OS or environment, have you tried the ‘openssl
> rand’ functionality as a random source to seed your entropy issues ?
>
> openssl rand 102400 > some named pipe file that you can call as your
> random source.
>
> perhaps rather than pseudo random, try a hardware device ?
>
>
>
>> On 30 May 2018, at 8:58 AM, Scott Neugroschl <[hidden email]> wrote:
>>
>> Hi,
>>
>> I’m using PRNGD to seed my random numbers (I’m on a system without
>> /dev/random and /dev/urandom).   I occasionally get the dreaded “PRNG
>> is not seeded” error.
>>
>> I know this is caused by a lack of available entropy in the system; but
>> what can I do to address this?  Is it just a matter of waiting until
>> enough entropy has been collected?  Is there any kind of workaround?
>>
>> Thanks
>>
>> ScottN
>>
>> --
>> openssl-users mailing list
>> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>


--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: PRNG is not seeded

FooCrypt
Are you a Dr Who fan ?

Place a teaspoon of fine grade white sand onto the skin of a snare drum

Place an isolating isoscrope above the snare drum that can measure the fractional movements of the grains of sand based on the ambient noise.

Do something that moves the sand so you can measure the factorial movements based on different events.

There was a documentary on the ABC about it all a few years back, someone at ANU or somewhere else in Oz was woking on the research.


> On 31 May 2018, at 6:07 PM, [hidden email] wrote:
>
> I've also encountered this quite often, and I have a feeling that on
> today's connected devices there may be a lot of entropy "in the air"
> (quite literally) which is not being captured. Does any one know of
> research in this area?
>
>> Hi Scott
>>
>> I don’t know your OS or environment, have you tried the ‘openssl
>> rand’ functionality as a random source to seed your entropy issues ?
>>
>> openssl rand 102400 > some named pipe file that you can call as your
>> random source.
>>
>> perhaps rather than pseudo random, try a hardware device ?
>>
>>
>>
>>> On 30 May 2018, at 8:58 AM, Scott Neugroschl <[hidden email]> wrote:
>>>
>>> Hi,
>>>
>>> I’m using PRNGD to seed my random numbers (I’m on a system without
>>> /dev/random and /dev/urandom).   I occasionally get the dreaded “PRNG
>>> is not seeded” error.
>>>
>>> I know this is caused by a lack of available entropy in the system; but
>>> what can I do to address this?  Is it just a matter of waiting until
>>> enough entropy has been collected?  Is there any kind of workaround?
>>>
>>> Thanks
>>>
>>> ScottN
>>>
>>> --
>>> openssl-users mailing list
>>> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>>
>> --
>> openssl-users mailing list
>> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>>
>
>
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: PRNG is not seeded

Jochen Bern
In reply to this post by Scott Neugroschl-2
On 05/31/2018 03:03 PM, [hidden email] distributed:
> Date: Thu, 31 May 2018 18:45:02 +1000
> From: FooCrypt <[hidden email]>
>
> Place a teaspoon of fine grade white sand onto the skin of a snare drum

Macroscopic hardware TRNGs are a *tad* yesteryear

https://en.wikipedia.org/wiki/Lavarand

because observing *quantum* random events doesn't require large devices

https://en.wikipedia.org/wiki/Hardware_random_number_generator

(not to mention being IIUC harder to influence by an attacker so as to
make them lose randomness). Nonetheless, if you don't have the hardware
(builtin TPM?) and cannot easily connect one to the given platform (as I
suspect for the OP's architecture) ...

For general computing platforms, I've taken to installing (and, of
course, running and monitoring) haveged as a standard - on hosts *and*
VMs. It can run in an AIS-31 test mode if you want to check out the
entropy it collects.

https://wiki.archlinux.org/index.php/Haveged

>> On 31 May 2018, at 6:07 PM, [hidden email] wrote:
>> I've also encountered this quite often, and I have a feeling that on
>> today's connected devices there may be a lot of entropy "in the air"
>> (quite literally) which is not being captured. Does any one know of
>> research in this area?

Not specifically for mobile phones or WiFi interfaces, if that's what
you're referring to with "in the air". However, squeezing available
entropy out of various less-than-predictable hardware and OS states is
what *all* non-hardware entropy gatherers ultimately do, from the Linux
kernel's /dev/random mechanisms to haveged to what-have-you.

Regards,
--
Jochen Bern
Systemingenieur

www.binect.de
www.facebook.de/binect


--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

smime.p7s (5K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: PRNG is not seeded

Chris Gray-4
As it happens I am the proud owner of a made-in-UK Mathmos Lava Lamp and a
couple of their Space Projectors : however I don't use them as a RNG.

I am thinking more about the fact that there are a lot of devices which
 * have no hardware TRNG on board
 * do have one or more connections to wired or wireless internet and/or
wide-area networks and/or various other communications channels such as
BTLE or ZigBee
 * need to make a TLS/DTLS connection somewhere in order to be useful.

By "literally in the air" I mean the entropy that is flying around in
those radio channels or shared media; not the data which is being
transmitted, but the inter-arrival times / collisions / etc. generated by
a number of physically independent sources.

I am sceptical of using haveged on such devices; of course I should be
willing to test it and measure the results, but "measuring randomness" is
a tricky business so I would be happy to see the results of some research.
My own experiments in the past (with devices which had only a dial-up
connection to the mother ship) were singularly unsuccessful in generating
any useful degree of randomness.

Thanks anyway for the suggestions everyone.

> On 05/31/2018 03:03 PM, [hidden email] distributed:
>> Date: Thu, 31 May 2018 18:45:02 +1000
>> From: FooCrypt <[hidden email]>
>>
>> Place a teaspoon of fine grade white sand onto the skin of a snare drum
>
> Macroscopic hardware TRNGs are a *tad* yesteryear
>
> https://en.wikipedia.org/wiki/Lavarand
>
> because observing *quantum* random events doesn't require large devices
>
> https://en.wikipedia.org/wiki/Hardware_random_number_generator
>
> (not to mention being IIUC harder to influence by an attacker so as to
> make them lose randomness). Nonetheless, if you don't have the hardware
> (builtin TPM?) and cannot easily connect one to the given platform (as I
> suspect for the OP's architecture) ...
>
> For general computing platforms, I've taken to installing (and, of
> course, running and monitoring) haveged as a standard - on hosts *and*
> VMs. It can run in an AIS-31 test mode if you want to check out the
> entropy it collects.
>
> https://wiki.archlinux.org/index.php/Haveged
>
>>> On 31 May 2018, at 6:07 PM, [hidden email] wrote:
>>> I've also encountered this quite often, and I have a feeling that on
>>> today's connected devices there may be a lot of entropy "in the air"
>>> (quite literally) which is not being captured. Does any one know of
>>> research in this area?
>
> Not specifically for mobile phones or WiFi interfaces, if that's what
> you're referring to with "in the air". However, squeezing available
> entropy out of various less-than-predictable hardware and OS states is
> what *all* non-hardware entropy gatherers ultimately do, from the Linux
> kernel's /dev/random mechanisms to haveged to what-have-you.
>
> Regards,
> --
> Jochen Bern
> Systemingenieur
>
> www.binect.de
> www.facebook.de/binect
>
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>


--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: PRNG is not seeded

Jakob Bohm-7
In reply to this post by Jochen Bern
On 31/05/2018 19:14, Jochen Bern wrote:

> On 05/31/2018 03:03 PM, [hidden email] distributed:
>> Date: Thu, 31 May 2018 18:45:02 +1000
>> From: FooCrypt <[hidden email]>
>>
>> Place a teaspoon of fine grade white sand onto the skin of a snare drum
> Macroscopic hardware TRNGs are a *tad* yesteryear
>
> https://en.wikipedia.org/wiki/Lavarand
>
> because observing *quantum* random events doesn't require large devices
>
> https://en.wikipedia.org/wiki/Hardware_random_number_generator
>
> (not to mention being IIUC harder to influence by an attacker so as to
> make them lose randomness). Nonetheless, if you don't have the hardware
> (builtin TPM?) and cannot easily connect one to the given platform (as I
> suspect for the OP's architecture) ...
>
> For general computing platforms, I've taken to installing (and, of
> course, running and monitoring) haveged as a standard - on hosts *and*
> VMs. It can run in an AIS-31 test mode if you want to check out the
> entropy it collects.
>
> https://wiki.archlinux.org/index.php/Haveged
 From what I have seen, haveged seems highly bogus, with no significant
arguments as to how their method gathers anything other than a highly
indirect and obfuscated form of process statistics.  The wording used
in their design summaries suggests they confuse "not documented outside
the CPU design team" with "random and unpredictable".

Haveged might be able to indirectly apply statistics of internal states
in other processes, but that seems about it.

The best alternative I have tried so far is to use what little entropy
is available to connect to a trusted (self-owned) machine that serves
TRNG bits over a variant of the EGD protocol, then using those bits to
handle other randomness needs.  The key benefit here is that the trusted
TRNG machine will contribute a lot of entropy to its own TLS connection,
and the independence from any ability to mess with the architectural
limitations of the receiving machine.

>>> On 31 May 2018, at 6:07 PM, [hidden email] wrote:
>>> I've also encountered this quite often, and I have a feeling that on
>>> today's connected devices there may be a lot of entropy "in the air"
>>> (quite literally) which is not being captured. Does any one know of
>>> research in this area?
> Not specifically for mobile phones or WiFi interfaces, if that's what
> you're referring to with "in the air". However, squeezing available
> entropy out of various less-than-predictable hardware and OS states is
> what *all* non-hardware entropy gatherers ultimately do, from the Linux
> kernel's /dev/random mechanisms to haveged to what-have-you.
>
> Regards,
>
>

Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S.  http://www.wisemo.com
Transformervej 29, 2860 Soborg, 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

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: PRNG is not seeded

Michael Wojcik
Of course people have been harvesting entropy, or trying to, from network sources for decades. There's a famous paragraph regarding it in RFC 4086, which is an expanded version of a similar statement from RFC 1750 (1994):

    Other external events, such as network packet arrival times and
    lengths, can also be used, but only with great care.  In particular,
    the possibility of manipulation of such network traffic measurements
    by an adversary and the lack of history at system start-up must be
    carefully considered.  If this input is subject to manipulation, it
    must not be trusted as a source of entropy.

(RFC 4086, 3.5)

More generally: It's often possible to harvest quite a bit of information that can't be adequately predicted or statistically modeled by an attacker from network sources, and these days distilling CPRNG entropy from such inputs is straightforward thanks to the use of cryptographic compression functions. It's the edge cases that bite you. 4086 mentions attacker manipulation (flooding network sources with known data to flush entropy out of the pool) and start-up (if you don't have persistent storage of adequate seed material). Embedded devices may suffer from too little, or too predictable, network traffic in their limited reception area.

You can get stronger guarantees from hardware entropy devices, which are cheap (in every sense: component cost, power consumption, size, ...). So there's not a lot of incentive to do more research into gathering entropy from external sources - it makes more sense to lean on device manufacturers, or use add-on devices.
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: PRNG is not seeded

Jakob Bohm-7
On 04/06/2018 15:56, Michael Wojcik wrote:

> Of course people have been harvesting entropy, or trying to, from network sources for decades. There's a famous paragraph regarding it in RFC 4086, which is an expanded version of a similar statement from RFC 1750 (1994):
>
>      Other external events, such as network packet arrival times and
>      lengths, can also be used, but only with great care.  In particular,
>      the possibility of manipulation of such network traffic measurements
>      by an adversary and the lack of history at system start-up must be
>      carefully considered.  If this input is subject to manipulation, it
>      must not be trusted as a source of entropy.
>
> (RFC 4086, 3.5)
>
> More generally: It's often possible to harvest quite a bit of information that can't be adequately predicted or statistically modeled by an attacker from network sources, and these days distilling CPRNG entropy from such inputs is straightforward thanks to the use of cryptographic compression functions. It's the edge cases that bite you. 4086 mentions attacker manipulation (flooding network sources with known data to flush entropy out of the pool) and start-up (if you don't have persistent storage of adequate seed material). Embedded devices may suffer from too little, or too predictable, network traffic in their limited reception area.
>
> You can get stronger guarantees from hardware entropy devices, which are cheap (in every sense: component cost, power consumption, size, ...). So there's not a lot of incentive to do more research into gathering entropy from external sources - it makes more sense to lean on device manufacturers, or use add-on devices.
Hence my solution of using a hardware TRNG shared over the
network with devices that lack the ability to have one added
locally.


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

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: PRNG is not seeded

Michael Wojcik
> From: openssl-users <[hidden email]> on behalf of Jakob Bohm <[hidden email]>
> Sent: Tuesday, June 5, 2018 02:46

> Hence my solution of using a hardware TRNG shared over the
> network with devices that lack the ability to have one added
> locally.

Yes, I think that's a good approach. It reduces the attack surface, since the client device can connect to the entropy-gathering device with considerable assurance (it can be configured with a pinned CA or PSK, etc), and at startup can use some entropy saved from the previous run. An attacker in a privileged position could try active attacks like a DoS against the connection to the entropy server, but a (more dangerous) passive attack looks very difficult.

And it's practical for real-world data centers; implementation and equipment costs are low.

It should even be possible to do this with one of those SOHO WIFi routers that have USB ports and media-sharing features, for use by smartphone apps and the like.
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: PRNG is not seeded

Jochen Bern
In reply to this post by Scott Neugroschl-2
On 06/06/2018 09:12 PM, [hidden email] digestributed:

> Date: Wed, 6 Jun 2018 16:12:59 +0000
> From: Michael Wojcik <[hidden email]>
>
>> Hence my solution of using a hardware TRNG shared over the
>> network with devices that lack the ability to have one added
>> locally.
>
> Yes, I think that's a good approach. It reduces the attack surface,
> since the client device can connect to the entropy-gathering device
> with considerable assurance (it can be configured with a pinned CA
> or PSK, etc), and at startup can use some entropy saved from the
> previous run. An attacker in a privileged position could try active
> attacks like a DoS against the connection to the entropy server, but
> a (more dangerous) passive attack looks very difficult.
Speaking of attack scenarios, I refreshed my info after this discussion
and wondered how likely it is that someone (in a Linux world) would want
to attack the entropy *sources* directly. A manipulated source's effect
on applications (that read from /dev/random) would be somewhat limited
due to the kernel folding in other sources as well (memento Linus'
statement about RDRAND), and due to the fact that *many* consumers read
from it (you cannot predict who gets which part of your manipulated
entropy).

For comparison, imagine someone attacking the kernel and manipulating
the /dev/random driver so that it feeds predictable sequences to the
targets (processes running executables "httpd", "gpg", etc.) but real
pool data to all other consumers. Presto, a subverted system that still
gets a clean bill of health from rngtest, ent, dieharder, or whatever
other analyzer you care to try ...

... by which I mean to ask, since I read a quest for suitable
entropy-distribution protocols between the lines here, maybe there is
something to be said in favor of signed-at-source chunks of entropy
being forwarded *through* the kernel unchanged, and leaving the
trust-based selection of sources and final folding to the individual
applications?

> And it's practical for real-world data centers; implementation and
> equipment costs are low.

[has been trying to acquire a better *NTP* source than public unsigned
servers in certain data centers for 8+ years] :-C

Regards,
--
Jochen Bern
Systemingenieur

www.binect.de
www.facebook.de/binect


--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

smime.p7s (5K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: PRNG is not seeded

Chris Gray-4
In reply to this post by Michael Wojcik
> Of course people have been harvesting entropy, or trying to, from network
> sources for decades. There's a famous paragraph regarding it in RFC 4086,
> which is an expanded version of a similar statement from RFC 1750 (1994):
>
>     Other external events, such as network packet arrival times and
>     lengths, can also be used, but only with great care.  In particular,
>     the possibility of manipulation of such network traffic measurements
>     by an adversary and the lack of history at system start-up must be
>     carefully considered.  If this input is subject to manipulation, it
>     must not be trusted as a source of entropy.
>
> (RFC 4086, 3.5)

Good point about the possibility of manipulation; it sounds a bit
far-fetched but so did a lot of other exploits before they became a
reality.

> More generally: It's often possible to harvest quite a bit of information
> that can't be adequately predicted or statistically modeled by an attacker
> from network sources, and these days distilling CPRNG entropy from such
> inputs is straightforward thanks to the use of cryptographic compression
> functions. It's the edge cases that bite you. 4086 mentions attacker
> manipulation (flooding network sources with known data to flush entropy
> out of the pool) and start-up (if you don't have persistent storage of
> adequate seed material). Embedded devices may suffer from too little, or
> too predictable, network traffic in their limited reception area.
>
> You can get stronger guarantees from hardware entropy devices, which are
> cheap (in every sense: component cost, power consumption, size, ...). So
> there's not a lot of incentive to do more research into gathering entropy
> from external sources - it makes more sense to lean on device
> manufacturers, or use add-on devices.

Or carry forward entropy across reboots, provided that can be done without
exposing another attack surface; or obtaining entropy from a trusted
source if you can figure out how to make a secure connection with that
source. My experience with "lean[ing] on device manufacturers" is not all
that positive.

> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>


--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users