Re: [openssl-users] PRNG is not seeded
> 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
Re: [openssl-users] PRNG is not seeded
On 06/06/2018 09:12 PM, openssl-users-requ...@openssl.org digestributed: > Date: Wed, 6 Jun 2018 16:12:59 + > From: Michael Wojcik > >> 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 smime.p7s Description: S/MIME Cryptographic Signature -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] PRNG is not seeded
> From: openssl-users on behalf of Jakob > Bohm > 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
Re: [openssl-users] PRNG is not seeded
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
Re: [openssl-users] PRNG is not seeded
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
Re: [openssl-users] PRNG is not seeded
On 31/05/2018 19:14, Jochen Bern wrote: On 05/31/2018 03:03 PM, openssl-users-requ...@openssl.org distributed: Date: Thu, 31 May 2018 18:45:02 +1000 From: FooCrypt 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, chris.g...@kiffer.be 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
Re: [openssl-users] PRNG is not seeded
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, openssl-users-requ...@openssl.org distributed: >> Date: Thu, 31 May 2018 18:45:02 +1000 >> From: FooCrypt >> >> 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, chris.g...@kiffer.be 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
Re: [openssl-users] PRNG is not seeded
On 05/31/2018 03:03 PM, openssl-users-requ...@openssl.org distributed: > Date: Thu, 31 May 2018 18:45:02 +1000 > From: FooCrypt > > 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, chris.g...@kiffer.be 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 smime.p7s Description: S/MIME Cryptographic Signature -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] PRNG is not seeded
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, chris.g...@kiffer.be 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 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
Re: [openssl-users] PRNG is not seeded
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 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
Re: [openssl-users] PRNG is not seeded
> 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
Re: [openssl-users] PRNG is not seeded
In message on Wed, 30 May 2018 15:37:47 +, Scott Neugroschl 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 levi...@openssl.org OpenSSL Project http://www.openssl.org/~levitte/ -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] PRNG is not seeded
> On 31 May 2018, at 1:35 AM, Michael Wojcik > wrote: > >> From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf >> Of FooCrypt >> Sent: Wednesday, May 30, 2018 10:46 >> To: openssl-users@openssl.org >> Subject: Re: [openssl-users] PRNG is not seeded >> >>> On 30 May 2018, at 11:55 PM, Michael Wojcik >> 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
Re: [openssl-users] PRNG is not seeded
>>> 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
Re: [openssl-users] PRNG is not seeded
> From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf > Of FooCrypt > Sent: Wednesday, May 30, 2018 10:46 > To: openssl-users@openssl.org > Subject: Re: [openssl-users] PRNG is not seeded > > > On 30 May 2018, at 11:55 PM, Michael Wojcik > 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
Re: [openssl-users] PRNG is not seeded
> On 30 May 2018, at 11:55 PM, Michael Wojcik > wrote: > >> From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf >> Of FooCrypt >> Sent: Tuesday, May 29, 2018 21:41 >> To: openssl-users@openssl.org >> Subject: Re: [openssl-users] PRNG is not seeded >> >>> On 30 May 2018, at 8:58 AM, Scott Neugroschl >> 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 X X 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
Re: [openssl-users] PRNG is not seeded
> From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf > Of FooCrypt > Sent: Tuesday, May 29, 2018 21:41 > To: openssl-users@openssl.org > Subject: Re: [openssl-users] PRNG is not seeded > > > On 30 May 2018, at 8:58 AM, Scott Neugroschl > 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
Re: [openssl-users] PRNG is not seeded
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 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
Re: [openssl-users] PRNG is not seeded
>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
