Secure usage of /dev/random vs /dev/urandom

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Secure usage of /dev/random vs /dev/urandom

Dave Thompson-2

At the ATS summit last week, there was some confusion regarding appropriate use of /dev/random vs /dev/urandom .  Depending on the usage, exploits associated with getting this wrong can be severe.  I'll sleep better, not letting this drop before attempting to explain which is an appropriate source. ;-)

From a linux perspective, the difference between these two sources of random data is that one is an entropy tracking source (/dev/random) which will block reads while the entropy pool is low, versus /dev/urandom which will always return a timely response regardless of the state of the entropy pool. When random numbers come from a deterministic pseudo-random number generator algorithm, the only real thing that is actually random is that which is collected in the entropy pool.

The linux entropy tracked source does come at a cost.   I have measured upwards of 2 seconds per byte.  Depending on the application, one might be waiting ~2 minutes to get keying material, which often imposes design constraints.  Naturally, if one doesn't need high quality random, don't use an low entropy blocking source.    /dev/urandom returns requested material almost immediately.  For purposes of TLS session-ticket-encryption-key generation (which is the context the question came up), one *absolutely* must know their PRNG is properly seeded.  A 128-bit cipher operating at 128-bit cipher strength requires a key that had 2^128 different possibilities.  If one doesn't pay attention to the entropy level seeding their PRNG, one has no idea.

Check the OS that the code is running on.  On linux a 'man 4 random', is quite explicit in that long-lived GPG/SSL/SSH keys should *not* use /dev/urandom. Different OS may have different constraints. 

---

Further excerpts from the linux 'man 4 random':

"When read, the /dev/random device will only return  random  bytes  within the  estimated  number of bits of noise in the entropy pool.  /dev/random should be suitable for uses that need very high quality  randomness  such as one-time pad or key generation.  When the entropy pool is empty, reads from /dev/random will block until additional environmental noise is gathered.

A  read  from  the  /dev/urandom  device  will not block waiting for more entropy.  As a result, if there is not sufficient entropy in the  entropy pool, the returned values are theoretically vulnerable to a cryptographic attack on the algorithms used by the driver.  Knowledge of how to do this is not available in the current non-classified literature, but it is theoretically possible that such an attack may exist.  If this is a  concern in your application, use /dev/random instead."

---

Dave Thompson

Reply | Threaded
Open this post in threaded view
|

Re: Secure usage of /dev/random vs /dev/urandom

Eric Friedrich (efriedri)
Dave-
  Thanks for the explanation. I wasn’t at the summit, so am likely missing some context. 

Doesn’t ATS rely on openssl to manage random number generation?

—Eric


On Oct 30, 2017, at 6:21 PM, Dave Thompson <[hidden email]> wrote:

At the ATS summit last week, there was some confusion regarding appropriate use of /dev/random vs /dev/urandom .  Depending on the usage, exploits associated with getting this wrong can be severe.  I'll sleep better, not letting this drop before attempting to explain which is an appropriate source. ;-)

From a linux perspective, the difference between these two sources of random data is that one is an entropy tracking source (/dev/random) which will block reads while the entropy pool is low, versus /dev/urandom which will always return a timely response regardless of the state of the entropy pool. When random numbers come from a deterministic pseudo-random number generator algorithm, the only real thing that is actually random is that which is collected in the entropy pool.

The linux entropy tracked source does come at a cost.   I have measured upwards of 2 seconds per byte.  Depending on the application, one might be waiting ~2 minutes to get keying material, which often imposes design constraints.  Naturally, if one doesn't need high quality random, don't use an low entropy blocking source.    /dev/urandom returns requested material almost immediately.  For purposes of TLS session-ticket-encryption-key generation (which is the context the question came up), one *absolutely* must know their PRNG is properly seeded.  A 128-bit cipher operating at 128-bit cipher strength requires a key that had 2^128 different possibilities.  If one doesn't pay attention to the entropy level seeding their PRNG, one has no idea.

Check the OS that the code is running on.  On linux a 'man 4 random', is quite explicit in that long-lived GPG/SSL/SSH keys should *not* use /dev/urandom. Different OS may have different constraints. 

---

Further excerpts from the linux 'man 4 random':

"When read, the /dev/random device will only return  random  bytes  within the  estimated  number of bits of noise in the entropy pool.  /dev/random should be suitable for uses that need very high quality  randomness  such as one-time pad or key generation.  When the entropy pool is empty, reads from /dev/random will block until additional environmental noise is gathered.

A  read  from  the  /dev/urandom  device  will not block waiting for more entropy.  As a result, if there is not sufficient entropy in the  entropy pool, the returned values are theoretically vulnerable to a cryptographic attack on the algorithms used by the driver.  Knowledge of how to do this is not available in the current non-classified literature, but it is theoretically possible that such an attack may exist.  If this is a  concern in your application, use /dev/random instead."


---

Dave Thompson


Reply | Threaded
Open this post in threaded view
|

Re: Secure usage of /dev/random vs /dev/urandom

Dave Thompson-2
Eric,

The discussion context was along the lines of an ATS plugin written to manage sharing of TLS session information and session ticket encryption key information amongst a group of nodes behind a load balancer.     The question was which source of random is used for key material of the TLS session-ticket-encryption-key (STEK) in our own STEK plugin handler (not ATS).

STEK is the key that a TLS server will use to encrypt/decrypt all TLS session tickets.  It is among one of the most sensitive tidbits on the server, as with it, one can decrypt all client session tickets (which contain the individual session keys that encrypt/decrypt bulk data), for all clients resumption to a TLS cluster that shares the STEK.   Common practice is to generate/rotate STEK every <24 hour period.   

The actual coordination of STEK rotation and generation is outside the scope of ATS, with the details likely deployment environment constrained.  ATS has more than one mechanism for external processes to set this.   By default ATS will generate a STEK each time it is started, though for a multi-node ATS cluster, this is not functional as each node would have different STEKs (resumptions would typically fail ), nor is it secure (e.g. lack of rotation).   As such I would speculate (hope) most would roll their own handler.

Dave Thompson


On Tue, Oct 31, 2017 at 10:50 AM, Eric Friedrich (efriedri) <[hidden email]> wrote:
Dave-
  Thanks for the explanation. I wasn’t at the summit, so am likely missing some context. 

Doesn’t ATS rely on openssl to manage random number generation?

—Eric


On Oct 30, 2017, at 6:21 PM, Dave Thompson <[hidden email]> wrote:

At the ATS summit last week, there was some confusion regarding appropriate use of /dev/random vs /dev/urandom .  Depending on the usage, exploits associated with getting this wrong can be severe.  I'll sleep better, not letting this drop before attempting to explain which is an appropriate source. ;-)

From a linux perspective, the difference between these two sources of random data is that one is an entropy tracking source (/dev/random) which will block reads while the entropy pool is low, versus /dev/urandom which will always return a timely response regardless of the state of the entropy pool. When random numbers come from a deterministic pseudo-random number generator algorithm, the only real thing that is actually random is that which is collected in the entropy pool.

The linux entropy tracked source does come at a cost.   I have measured upwards of 2 seconds per byte.  Depending on the application, one might be waiting ~2 minutes to get keying material, which often imposes design constraints.  Naturally, if one doesn't need high quality random, don't use an low entropy blocking source.    /dev/urandom returns requested material almost immediately.  For purposes of TLS session-ticket-encryption-key generation (which is the context the question came up), one *absolutely* must know their PRNG is properly seeded.  A 128-bit cipher operating at 128-bit cipher strength requires a key that had 2^128 different possibilities.  If one doesn't pay attention to the entropy level seeding their PRNG, one has no idea.

Check the OS that the code is running on.  On linux a 'man 4 random', is quite explicit in that long-lived GPG/SSL/SSH keys should *not* use /dev/urandom. Different OS may have different constraints. 

---

Further excerpts from the linux 'man 4 random':

"When read, the /dev/random device will only return  random  bytes  within the  estimated  number of bits of noise in the entropy pool.  /dev/random should be suitable for uses that need very high quality  randomness  such as one-time pad or key generation.  When the entropy pool is empty, reads from /dev/random will block until additional environmental noise is gathered.

A  read  from  the  /dev/urandom  device  will not block waiting for more entropy.  As a result, if there is not sufficient entropy in the  entropy pool, the returned values are theoretically vulnerable to a cryptographic attack on the algorithms used by the driver.  Knowledge of how to do this is not available in the current non-classified literature, but it is theoretically possible that such an attack may exist.  If this is a  concern in your application, use /dev/random instead."


---

Dave Thompson



Reply | Threaded
Open this post in threaded view
|

RE: Secure usage of /dev/random vs /dev/urandom

Mischa Lehmann

Dave, thanks for clarification.

 

I raised this issue during the conference because I falsely thought that we’re generating information in the tickets based on /dev/random. Which is obviously a bad idea.

Using /dev/random for the STEK seems to be safe if we can guarantee that traffic through ATS won’t trigger rotation.

Mischa

 

From: Dave Thompson [mailto:[hidden email]]
Sent: 01 November 2017 21:22
To: [hidden email]
Subject: Re: Secure usage of /dev/random vs /dev/urandom

 

Eric,

 

The discussion context was along the lines of an ATS plugin written to manage sharing of TLS session information and session ticket encryption key information amongst a group of nodes behind a load balancer.     The question was which source of random is used for key material of the TLS session-ticket-encryption-key (STEK) in our own STEK plugin handler (not ATS).

 

STEK is the key that a TLS server will use to encrypt/decrypt all TLS session tickets.  It is among one of the most sensitive tidbits on the server, as with it, one can decrypt all client session tickets (which contain the individual session keys that encrypt/decrypt bulk data), for all clients resumption to a TLS cluster that shares the STEK.   Common practice is to generate/rotate STEK every <24 hour period.   

 

The actual coordination of STEK rotation and generation is outside the scope of ATS, with the details likely deployment environment constrained.  ATS has more than one mechanism for external processes to set this.   By default ATS will generate a STEK each time it is started, though for a multi-node ATS cluster, this is not functional as each node would have different STEKs (resumptions would typically fail ), nor is it secure (e.g. lack of rotation).   As such I would speculate (hope) most would roll their own handler.

 

Dave Thompson

 

 

On Tue, Oct 31, 2017 at 10:50 AM, Eric Friedrich (efriedri) <[hidden email]> wrote:

Dave-

  Thanks for the explanation. I wasn’t at the summit, so am likely missing some context. 

 

Doesn’t ATS rely on openssl to manage random number generation?

 

—Eric

 

 

On Oct 30, 2017, at 6:21 PM, Dave Thompson <[hidden email]> wrote:

 

At the ATS summit last week, there was some confusion regarding appropriate use of /dev/random vs /dev/urandom .  Depending on the usage, exploits associated with getting this wrong can be severe.  I'll sleep better, not letting this drop before attempting to explain which is an appropriate source. ;-)

From a linux perspective, the difference between these two sources of random data is that one is an entropy tracking source (/dev/random) which will block reads while the entropy pool is low, versus /dev/urandom which will always return a timely response regardless of the state of the entropy pool. When random numbers come from a deterministic pseudo-random number generator algorithm, the only real thing that is actually random is that which is collected in the entropy pool.

The linux entropy tracked source does come at a cost.   I have measured upwards of 2 seconds per byte.  Depending on the application, one might be waiting ~2 minutes to get keying material, which often imposes design constraints.  Naturally, if one doesn't need high quality random, don't use an low entropy blocking source.    /dev/urandom returns requested material almost immediately.  For purposes of TLS session-ticket-encryption-key generation (which is the context the question came up), one *absolutely* must know their PRNG is properly seeded.  A 128-bit cipher operating at 128-bit cipher strength requires a key that had 2^128 different possibilities.  If one doesn't pay attention to the entropy level seeding their PRNG, one has no idea.

Check the OS that the code is running on.  On linux a 'man 4 random', is quite explicit in that long-lived GPG/SSL/SSH keys should *not* use /dev/urandom. Different OS may have different constraints. 

---

Further excerpts from the linux 'man 4 random':

"When read, the /dev/random device will only return  random  bytes  within the  estimated  number of bits of noise in the entropy pool.  /dev/random should be suitable for uses that need very high quality  randomness  such as one-time pad or key generation.  When the entropy pool is empty, reads from /dev/random will block until additional environmental noise is gathered.

A  read  from  the  /dev/urandom  device  will not block waiting for more entropy.  As a result, if there is not sufficient entropy in the  entropy pool, the returned values are theoretically vulnerable to a cryptographic attack on the algorithms used by the driver.  Knowledge of how to do this is not available in the current non-classified literature, but it is theoretically possible that such an attack may exist.  If this is a  concern in your application, use /dev/random instead."

 

---

Dave Thompson

 

 


Message Processed by the Clearswift R&D Dogfood Secure Email Gateway v4.7.0

This e-mail and any files transmitted with it are strictly confidential, may be privileged and are intended only for use by the addressee unless otherwise indicated.  If you are not the intended recipient any use, dissemination, printing or copying is strictly prohibited and may be unlawful.  If you have received this e-mail in error, please delete it immediately and contact the sender as soon as possible.  Clearswift cannot be held liable for delays in receipt of an email or any errors in its content. Clearswift accepts no responsibility once an e-mail and any attachments leave us. Unless expressly stated, opinions in this message are those of the individual sender and not of Clearswift.

This email message has been inspected by Clearswift for inappropriate content and security threats.

To find out more about Clearswift’s solutions please visit www.clearswift.com

Reply | Threaded
Open this post in threaded view
|

Re: Secure usage of /dev/random vs /dev/urandom

Dave Thompson-2

So, TLDR; form of this thread on /dev/random vs /dev/urandom

/dev/random - Use when entropy tracking matters, e.g. sensitive security needs.  Performance-wise can be very expensive, to the point of constraining how it's used.

/dev/urandom - When performance is the priority.  Not for use with long lived security keys.

STEK (Session Ticket Encryption Key) - it's among one of the most sensitive tidbits on a TLS server, with regards to transaction privacy.  It should be rotated regularly. Out-of-the-box ATS only generates new at startup, though provides multiple hooks for site-specific rotation handlers.

Caveat, above is linux specific, details may vary with OS.

Dave


On Wed, Nov 8, 2017 at 8:52 AM, Mischa Lehmann <[hidden email]> wrote:

Dave, thanks for clarification.

 

I raised this issue during the conference because I falsely thought that we’re generating information in the tickets based on /dev/random. Which is obviously a bad idea.

Using /dev/random for the STEK seems to be safe if we can guarantee that traffic through ATS won’t trigger rotation.

Mischa

 

From: Dave Thompson [mailto:[hidden email]]
Sent: 01 November 2017 21:22
To: [hidden email]
Subject: Re: Secure usage of /dev/random vs /dev/urandom

 

Eric,

 

The discussion context was along the lines of an ATS plugin written to manage sharing of TLS session information and session ticket encryption key information amongst a group of nodes behind a load balancer.     The question was which source of random is used for key material of the TLS session-ticket-encryption-key (STEK) in our own STEK plugin handler (not ATS).

 

STEK is the key that a TLS server will use to encrypt/decrypt all TLS session tickets.  It is among one of the most sensitive tidbits on the server, as with it, one can decrypt all client session tickets (which contain the individual session keys that encrypt/decrypt bulk data), for all clients resumption to a TLS cluster that shares the STEK.   Common practice is to generate/rotate STEK every <24 hour period.   

 

The actual coordination of STEK rotation and generation is outside the scope of ATS, with the details likely deployment environment constrained.  ATS has more than one mechanism for external processes to set this.   By default ATS will generate a STEK each time it is started, though for a multi-node ATS cluster, this is not functional as each node would have different STEKs (resumptions would typically fail ), nor is it secure (e.g. lack of rotation).   As such I would speculate (hope) most would roll their own handler.

 

Dave Thompson

 

 

On Tue, Oct 31, 2017 at 10:50 AM, Eric Friedrich (efriedri) <[hidden email]> wrote:

Dave-

  Thanks for the explanation. I wasn’t at the summit, so am likely missing some context. 

 

Doesn’t ATS rely on openssl to manage random number generation?

 

—Eric

 

 

On Oct 30, 2017, at 6:21 PM, Dave Thompson <[hidden email]> wrote:

 

At the ATS summit last week, there was some confusion regarding appropriate use of /dev/random vs /dev/urandom .  Depending on the usage, exploits associated with getting this wrong can be severe.  I'll sleep better, not letting this drop before attempting to explain which is an appropriate source. ;-)

From a linux perspective, the difference between these two sources of random data is that one is an entropy tracking source (/dev/random) which will block reads while the entropy pool is low, versus /dev/urandom which will always return a timely response regardless of the state of the entropy pool. When random numbers come from a deterministic pseudo-random number generator algorithm, the only real thing that is actually random is that which is collected in the entropy pool.

The linux entropy tracked source does come at a cost.   I have measured upwards of 2 seconds per byte.  Depending on the application, one might be waiting ~2 minutes to get keying material, which often imposes design constraints.  Naturally, if one doesn't need high quality random, don't use an low entropy blocking source.    /dev/urandom returns requested material almost immediately.  For purposes of TLS session-ticket-encryption-key generation (which is the context the question came up), one *absolutely* must know their PRNG is properly seeded.  A 128-bit cipher operating at 128-bit cipher strength requires a key that had 2^128 different possibilities.  If one doesn't pay attention to the entropy level seeding their PRNG, one has no idea.

Check the OS that the code is running on.  On linux a 'man 4 random', is quite explicit in that long-lived GPG/SSL/SSH keys should *not* use /dev/urandom. Different OS may have different constraints. 

---

Further excerpts from the linux 'man 4 random':

"When read, the /dev/random device will only return  random  bytes  within the  estimated  number of bits of noise in the entropy pool.  /dev/random should be suitable for uses that need very high quality  randomness  such as one-time pad or key generation.  When the entropy pool is empty, reads from /dev/random will block until additional environmental noise is gathered.

A  read  from  the  /dev/urandom  device  will not block waiting for more entropy.  As a result, if there is not sufficient entropy in the  entropy pool, the returned values are theoretically vulnerable to a cryptographic attack on the algorithms used by the driver.  Knowledge of how to do this is not available in the current non-classified literature, but it is theoretically possible that such an attack may exist.  If this is a  concern in your application, use /dev/random instead."

 

---

Dave Thompson

 

 


Message Processed by the Clearswift R&D Dogfood Secure Email Gateway v4.7.0

This e-mail and any files transmitted with it are strictly confidential, may be privileged and are intended only for use by the addressee unless otherwise indicated.  If you are not the intended recipient any use, dissemination, printing or copying is strictly prohibited and may be unlawful.  If you have received this e-mail in error, please delete it immediately and contact the sender as soon as possible.  Clearswift cannot be held liable for delays in receipt of an email or any errors in its content. Clearswift accepts no responsibility once an e-mail and any attachments leave us. Unless expressly stated, opinions in this message are those of the individual sender and not of Clearswift.

This email message has been inspected by Clearswift for inappropriate content and security threats.

To find out more about Clearswift’s solutions please visit www.clearswift.com