Subject: Re: [lamps] CMP draft WGLC: measuring entropy, CA certificates

From: "Salz, Rich" <[email-masked]>
Date: Mon, 22 Nov 2021 15:02:04 +0000

Thank you for the explanation and history.  I will think about it before replying, if I do.

As for the measuring entropy issue.  Maybe it is a language issue.  (And if we were doing this in German, I’d be stuck so thank you.) The document says how important it is to measure entropy so it as least as strong as the keypair, yet offers no advice or suggestions on how to do that.  Perhaps it can be reworded so that measurements aren’t needed?

---

From: Russ Housley <[email-masked]>
Date: Mon, 22 Nov 2021 10:25:11 -0500

RFC 5652 takes this approach:

   Implementations must randomly generate <list of things>.
   The use of inadequate pseudo-random number
   generators (PRNGs) to generate cryptographic keys can result in
   little or no security.  An attacker may find it much easier to
   reproduce the PRNG environment that produced the keys, searching the
   resulting small set of possibilities, rather than brute force
   searching the whole key space.  The generation of quality random
   numbers is difficult.  RFC 4086 [RANDOM] offers important guidance in
   this area.

Russ

> On Nov 22, 2021, at 10:02 AM, Salz, Rich <rsalz=[email-masked]> wrote:
> 
> _______________________________________________
> Spasm mailing list
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/spasm <https://www.ietf.org/mailman/listinfo/spasm>

---

From: "Brockhaus, Hendrik" <[email-masked]>
Date: Mon, 22 Nov 2021 17:17:50 +0000

Russ, Rich

Many thanks for your feedback and recommendation.
I like the section Russ provided and I would like to use it instead of the first sentence of that section to give implementers some more reasoning for this security consideration.

Old:
   For requirements regarding proper random number and key generation
   please refer to [RFC4086].

New:
   Implementations must randomly generate shares secret information,
   symmetric and asymmetric keys, padding, nonces, etc. The use of
   inadequate pseudo-random number generators (PRNGs) to generate
   cryptographic keys can result in little or no security.  An attacker may
   find it much easier to reproduce the PRNG environment that produced
   the keys, searching the resulting small set of possibilities, rather than
   brute force searching the whole key space.  The generation of quality
   random numbers is difficult.  RFC 4086 [RFC4086] offers important
   guidance in this area.

I am a little uncertain if this solves your issue with the section.
In the end the issue comes with the entropy of the shared secret information used for key generation or message protection.
I feel like you are worried implements may technically be not able to conform with this recommendation.
Is it the normative language that I should change?
Or is it something else that should be changed?

I recognized that Russ did not use any normative language in the Security Considerations section of RFC 5652. Is it adequate to use normative language here at all?

Rich, probably you are right, it may also be a language issue.
Any feedback or proposals are welcome.

Hendrik

Von: Spasm <[email-masked]> Im Auftrag von Russ Housley
Gesendet: Montag, 22. November 2021 16:25

Russ

On Nov 22, 2021, at 10:02 AM, Salz, Rich <rsalz=[email-masked]<mailto:rsalz=[email-masked]>> wrote:

As for the measuring entropy issue.  Maybe it is a language issue.  (And if we were doing this in German, I'd be stuck so thank you.) The document says how important it is to measure entropy so it as least as strong as the keypair, yet offers no advice or suggestions on how to do that.  Perhaps it can be reworded so that measurements aren't needed?
_______________________________________________
Spasm mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/spasm<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspasm&data=04%7C01%7Chendrik.brockhaus%40siemens.com%7Ceabf7e465a54425ea15108d9adcc50c5%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637731915320024581%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=4stWvH7I%2FSUKAIUjRXacwbtDnYUbi0YioINCkSaX014%3D&reserved=0>

---

From: "Salz, Rich" <[email-masked]>
Date: Mon, 22 Nov 2021 17:17:58 +0000

*   RFC 5652 takes this approach:

My concern/confusion is the mix of specifics – “entropy at least as strong as the keysize” – with the lack of specific guidance on how to do that.

I prefer the 5652 approach.

---

From: "Blumenthal, Uri - 0553 - MITLL" <[email-masked]>
Date: Mon, 22 Nov 2021 18:19:11 +0000

You can test and measure an RNG beforehand, e.g., during acceptance testing – but you cannot measure the randomness of the requested/received byte-string you’ll use in the protocol.

I like the wording that Russ proposed.

Basically, it makes sense to require that RNG complies with <whatever standards or BCP you pick for RNG/TRNG>, and refer to those. You can caution the reader that a weak RNG would doom the entire system. IMHO, that’s about all.

--

Regards,

Uri

There are two ways to design a system. One is to make is so simple there are obviously no deficiencies.

The other is to make it so complex there are no obvious deficiencies.

                                                                                                                                     -  C. A. R. Hoare

From: Spasm <[email-masked]> on behalf of "Brockhaus, Hendrik" <[email-masked]>
Date: Monday, November 22, 2021 at 12:19
To: Russ Housley <[email-masked]>, Rich Salz <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [lamps] CMP draft WGLC: measuring entropy, CA certificates

Russ, Rich

Old:

New:

   guidance in this area.

Hendrik

   this area.

Russ

_______________________________________________
Spasm mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/spasm

---

From: Tim Hollebeek <[email-masked]>
Date: Tue, 23 Nov 2021 19:04:11 +0000

The CA/Browser Forum took a similar approach.  The construction we settled on there is “containing at least 64 bits of output from a CSPRNG.”

“CSPRNG: A random number generator intended for use in cryptographic system.”

It has the advantage of being relatively simple and straightforward.

In general, if you find yourself trying to measure the strength of a cryptographic element after it has already been generated, you’ve already lost (for example, it may have plenty of entropy, but comes from the attacker!).  It’s better to focus on the technical and security requirements around the generation and secure management of such elements.

-Tim

From: Spasm <[email-masked]> On Behalf Of Russ Housley
Sent: Monday, November 22, 2021 10:25 AM
To: Brockhaus, Hendrik <[email-masked]>
Cc: [email-masked]
Subject: Re: [lamps] CMP draft WGLC: measuring entropy, CA certificates

   this area.

Russ

On Nov 22, 2021, at 10:02 AM, Salz, Rich <rsalz=[email-masked] <mailto:rsalz=[email-masked]> > wrote:

_______________________________________________
Spasm mailing list
 <mailto:[email-masked]> [email-masked]
 <https://www.ietf.org/mailman/listinfo/spasm> https://www.ietf.org/mailman/listinfo/spasm

---

From: "Brockhaus, Hendrik" <[email-masked]>
Date: Wed, 24 Nov 2021 14:11:11 +0000

Tim

Thanks also for this input. I extended the section accordingly and would propose the following change.

Old:

   8.5.  Entropy of random numbers, key pairs, and shared secret

   information

   For the case of centrally generated key pairs, the entropy of the

   shared secret information SHALL NOT be less than the security

   strength of the centrally generated key pair; if the shared secret

   information is re-used for different key pairs, the entropy and the

   security of the underlying cryptographic mechanisms SHOULD exceed the

   security strength of the key pairs.

   For the case of a PKI management operation that delivers a new trust

   anchor (e.g., a root CA certificate) using caPubs, (a) that is not

   concluded in a timely manner or (b) where the shared secret

   information is re-used for several key management operations, the

   entropy of the shared secret information SHALL NOT be less than the

   security strength of the key material being managed by the operation.

   For other cases it is recommended to (a) either use a shared secret

   information of possibly low entropy (e.g., a password) only for a

   single PKI management operation or (b) use a shared secret

   information with an entropy that matches the security strength of the

   key material being managed by the operation.

New:

  8.5.  Entropy of random numbers, key pairs, and shared secret

  information

   symmetric and asymmetric keys, padding, nonces, transactionIDs, etc.

   The use of inadequate pseudo-random number generators (PRNGs) to

   generate cryptographic keys can result in little or no security. An attacker

   may find it much easier to reproduce the PRNG environment that

   produced the keys, searching the resulting small set of possibilities,

   rather than brute force searching the whole key space. The generation

   of quality random numbers is difficult. BCP 106 [RFC4086] offers

   important guidance in this area.

   If the shared secret information is generated by a cryptographically secure

   random-number generator (CSRNG) it is safe to assume, that the entropy

   of the shared secret information is equal to its bit length. If no CSRNG is

   used, the entropy of a shared secret information depends on the details of

   the generation process and cannot be measure securely after it has been

   generated. If user-generated passwords are used as shared secret

   information, their entropy cannot be measured and are typically insufficient

   for protection of delivery of centrally generated keys or trust anchors.

   If the entropy of a shared secret information protecting the delivery of a

   centrally generated key pair is known, it should not be less than the security

   strength of that key pair; if the shared secret information is re-used for

   different key pairs, the security of the underlying cryptographic mechanisms

   should exceed the security strength of the key pairs.

   For the case of a PKI management operation that delivers a new trust anchor

   (e.g., a root CA certificate) using caPubs or genm, (a) that is not concluded in

   a timely manner or (b) where the shared secret information is re-used for

   several key management operations, the entropy of the shared secret

   information, if known, should not be less than the security strength of the

   trust anchor being managed by the operation. For other cases it is

   recommended to (a) either use a shared secret information of possibly low

   security strength (e.g., a password) only for a single PKI management

   operation or (b) use a shared secret information with an entropy that matches

   the security strength of the key material being managed by the operation.

There are tree options:

(1) Take the full new text.

(2) Take only the first two paragraphs.

(3) Take only the first paragraph.

Any opinions?

Hendrik

Von: Tim Hollebeek <[email-masked]> 
Gesendet: Dienstag, 23. November 2021 20:04
An: Russ Housley <[email-masked]>; Brockhaus, Hendrik (T RDA CST SEA-DE) <[email-masked]>
Cc: [email-masked]
Betreff: RE: [lamps] CMP draft WGLC: measuring entropy, CA certificates

-Tim

From: Spasm <[email-masked] <mailto:[email-masked]> > On Behalf Of Russ Housley
Sent: Monday, November 22, 2021 10:25 AM
To: Brockhaus, Hendrik <[email-masked] <mailto:[email-masked]> >
Cc: [email-masked] <mailto:[email-masked]> 
Subject: Re: [lamps] CMP draft WGLC: measuring entropy, CA certificates

   this area.

Russ

---

From: Tim Hollebeek <[email-masked]>
Date: Wed, 24 Nov 2021 16:33:54 +0000

Speaking only for myself, I do think the entire New text is useful and a substantial improvement over the Old text.

It could still use some editing and more work, and unfortunately I don’t have time for concrete feedback right now.  Hopefully I’ll have time to get back to it later if others don’t beat me to it.

-Tim

From: Brockhaus, Hendrik <[email-masked]> 
Sent: Wednesday, November 24, 2021 9:11 AM
To: Tim Hollebeek <[email-masked]>; Russ Housley <[email-masked]>
Cc: [email-masked]
Subject: AW: [lamps] CMP draft WGLC: measuring entropy, CA certificates

Tim

Old:

   information

New:

  information

There are tree options:

Any opinions?

Hendrik

Von: Tim Hollebeek <[email-masked] <mailto:[email-masked]> > 
Gesendet: Dienstag, 23. November 2021 20:04
An: Russ Housley <[email-masked] <mailto:[email-masked]> >; Brockhaus, Hendrik (T RDA CST SEA-DE) <[email-masked] <mailto:[email-masked]> >
Cc: [email-masked] <mailto:[email-masked]> 
Betreff: RE: [lamps] CMP draft WGLC: measuring entropy, CA certificates

-Tim

   this area.

Russ

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 24 Nov 2021 16:50:35 +0000

I like the first paragraph and think we should use just that.

I would like to see a reference to this CVE: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-0166  For Sep 2006 to May 2008 all keys generated on Debian-based systems were susceptible. I would also like to see a reference to NIST SP 800-90A, https://csrc.nist.gov/publications/detail/sp/800-90a/rev-1/final

RFC 4086 is good, but 15+ years old and should be downgraded from “importance guidance” to “some useful guidance.”

---

From: "Brockhaus, Hendrik" <[email-masked]>
Date: Wed, 24 Nov 2021 17:04:38 +0000

Tim

Thank you for your feedback.

Currently I am uncertain what exactly needs to be improved. Therefore, any concrete suggestions are welcome.

Hendrik

Von: Tim Hollebeek <[email-masked]> 
Gesendet: Mittwoch, 24. November 2021 17:34
An: Brockhaus, Hendrik (T RDA CST SEA-DE) <[email-masked]>; Russ Housley <[email-masked]>
Cc: [email-masked]
Betreff: RE: [lamps] CMP draft WGLC: measuring entropy, CA certificates

-Tim

From: Brockhaus, Hendrik <[email-masked] <mailto:[email-masked]> > 
Sent: Wednesday, November 24, 2021 9:11 AM
To: Tim Hollebeek <[email-masked] <mailto:[email-masked]> >; Russ Housley <[email-masked] <mailto:[email-masked]> >
Cc: [email-masked] <mailto:[email-masked]> 
Subject: AW: [lamps] CMP draft WGLC: measuring entropy, CA certificates

Tim

Old:

   information

New:

  information

There are tree options:

Any opinions?

Hendrik

-Tim

   this area.

Russ

---

From: "Brockhaus, Hendrik" <[email-masked]>
Date: Wed, 24 Nov 2021 17:05:38 +0000

Rich

Thank you for these links. I will have a look into them and will male a proposal for incorporating them.

Hendrik

Von: Salz, Rich <[email-masked]>
Gesendet: Mittwoch, 24. November 2021 17:51
An: Tim Hollebeek <tim.hollebeek=[email-masked]>; Brockhaus, Hendrik (T RDA CST SEA-DE) <[email-masked]>; Russ Housley <[email-masked]>
Cc: [email-masked]
Betreff: Re: [lamps] CMP draft WGLC: measuring entropy, CA certificates

I would like to see a reference to this CVE: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-0166<https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fcve.mitre.org%2Fcgi-bin%2Fcvename.cgi%3Fname%3DCVE-2008-0166&data=04%7C01%7Chendrik.brockhaus%40siemens.com%7Cf887b1ccf0fc4e94d32408d9af6a9e0d%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637733694757971965%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=iAT3YEv%2FxzFlYXCp0yWxfS3rnE9GiH2yBjxC%2BfNx7qY%3D&reserved=0>  For Sep 2006 to May 2008 all keys generated on Debian-based systems were susceptible. I would also like to see a reference to NIST SP 800-90A, https://csrc.nist.gov/publications/detail/sp/800-90a/rev-1/final<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcsrc.nist.gov%2Fpublications%2Fdetail%2Fsp%2F800-90a%2Frev-1%2Ffinal&data=04%7C01%7Chendrik.brockhaus%40siemens.com%7Cf887b1ccf0fc4e94d32408d9af6a9e0d%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637733694757981914%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=KaRfrl%2FUkxsQ7Xfb7lLbtnojGEpjvGumT349%2F%2BmBh%2FI%3D&reserved=0>

RFC 4086 is good, but 15+ years old and should be downgraded from "importance guidance" to "some useful guidance."

---

From: "Brockhaus, Hendrik" <[email-masked]>
Date: Thu, 25 Nov 2021 15:33:07 +0000

Rich

I had a look into the references you provided below. I like the example of CVE-2008-0166.
I also had a chat with one of our experts on recommendations on random number generation. He said, that there are many documents from different bodies around, e.g., from ISO/IEC, NIST, ANSI, IETF. I can add further references to the section next to RFC 4086.
Preferably I would reference "ISO/IEC 20543:2019 Information technology - Security techniques - Test and analysis methods for random bit generators within ISO/IEC 19790 and ISO/IEC 15408", https://www.iso.org/standard/68296.html. But this is behind a paywall. Therefore, I could add "A proposal for: Functionality classes for random number generators - Version 2.0" from the German BSI, https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Zertifizierung/Interpretationen/AIS_31_Functionality_classes_for_random_number_generators_e.pdf. This was kind of a bases for the ISO standard, and it is freely available.

What about this text?
Any feedback is welcome, as well as further opinions if we should leave out paragraph 2, 3, or 4.

New:

   Implementations must randomly generate shares secret information,
   symmetric and asymmetric keys, padding, nonces, transactionIDs, etc.
   The use of inadequate pseudo-random number generators (PRNGs) to
   generate cryptographic keys can result in little or no security. An attacker
   may find it much easier to reproduce the PRNG environment that
   produced the keys, searching the resulting small set of possibilities,
   rather than brute force searching the whole key space. As example for
   predictable random numbers see CVE-2008-0166 [...]. The generation
   of quality random numbers is difficult. ISO/IEC 20543:2019 [...],
   NIST SP 800-90A Rev.1 [...], BSI AIS 31 V2.0 [...], BCP 106 [RFC4086], and
   others offers important guidance in this area.

Hendrik

---

From: "Salz, Rich" <[email-masked]>
Date: Thu, 25 Nov 2021 15:53:17 +0000

I am glad you are adding the CVE. The BSI reference instead of NIST is fine with me.  Probably even better as it includes testing and analysis!

I still hope you’ll say “RFC 4084 can also offer some useful guidance” because it’s old and, especially compared to the BSI ref, pretty shallow.

---

From: "Brockhaus, Hendrik" <[email-masked]>
Date: Fri, 26 Nov 2021 17:59:36 +0000

Rich

I am also fine with completely dropping the reference to RFC 4086 if it tends to be outdated. But I cannot judge that.
Alternatively, I can just state ‘guidance’ for all of the references. I just would not like to split the list in an ‘important guidance’ and a ‘useful guidance’ section :-)

In another tread a similar topic was discussed. This reference was proposed there. Even though it is from 2012, I like it and could add it next to the CVE reference as well.
Heninger, N., Durumeric, Z., Wustrow, E., and J. Halderman, "Mining Your Ps and Qs: Detection of Widespread Weak Keys in Network Devices", Proceedings of the 21st USENIX Security Symposium , August 2012, <https://factorable.net/>.
https://www.usenix.org/conference/usenixsecurity12/technical-sessions/presentation/heninger

New:

   Implementations must randomly generate shares secret information,
   symmetric and asymmetric keys, padding, nonces, transactionIDs, etc.
   The use of inadequate pseudo-random number generators (PRNGs) to
   generate cryptographic keys can result in little or no security. An attacker
   may find it much easier to reproduce the PRNG environment that
   produced the keys, searching the resulting small set of possibilities,
   rather than brute force searching the whole key space. As example for
   malfunctioning random numbers see CVE-2008-0166 […] and "Mining
   Your Ps and Qs: Detection of Widespread Weak Keys in Network
   Devices" […]. The generation of quality random numbers is difficult.
   ISO/IEC 20543:2019 […], NIST SP 800-90A Rev.1 […], BSI AIS 31 V2.0 […],
   BCP 106 [RFC4086], and others offers guidance in this area.

Hendrik

Von: Salz, Rich <[email-masked]>
Gesendet: Donnerstag, 25. November 2021 16:53
An: Brockhaus, Hendrik (T RDA CST SEA-DE) <[email-masked]>; Tim Hollebeek <tim.hollebeek=[email-masked]>; Russ Housley <[email-masked]>
Cc: [email-masked]
Betreff: Re: [lamps] CMP draft WGLC: measuring entropy, CA certificates

---

From: "Salz, Rich" <[email-masked]>
Date: Fri, 26 Nov 2021 20:04:12 +0000

*   Alternatively, I can just state ‘guidance’ for all of the references. I just would not like to split the list in an ‘important guidance’ and a ‘useful guidance’ section :-)

I’m okay with that also.

  *   In another tread a similar topic was discussed. This reference was proposed there. Even though it is from 2012, I like it and could add it next to the CVE reference as well.
Heninger, N., Durumeric, Z., Wustrow, E., and J. Halderman, "Mining Your Ps and Qs: Detection of Widespread Weak Keys in Network Devices", Proceedings of the 21st USENIX Security Symposium , August 2012, <https://factorable.net/<https://urldefense.com/v3/__https:/factorable.net/__;!!GjvTz_vk!EPwUHUVFQX1hiMe8LI2F1Oo70mUnFf1QjzZ-RLiuJ9es_L66DCqFCFQGtbwF$>>.
https://www.usenix.org/conference/usenixsecurity12/technical-sessions/presentation/heninger<https://urldefense.com/v3/__https:/www.usenix.org/conference/usenixsecurity12/technical-sessions/presentation/heninger__;!!GjvTz_vk!EPwUHUVFQX1hiMe8LI2F1Oo70mUnFf1QjzZ-RLiuJ9es_L66DCqFCAwW1Iz4$>

Sure.  If you think there are too many references, you could just use that one and not the CVE.  Or just both.

---

From: "Brockhaus, Hendrik" <[email-masked]>
Date: Mon, 29 Nov 2021 07:21:44 +0000

Rich

Von: Salz, Rich <[email-masked]>
Gesendet: Freitag, 26. November 2021 21:04

  *   Alternatively, I can just state 'guidance' for all of the references. I just would not like to split the list in an 'important guidance' and a 'useful guidance' section :-)

I'm okay with that also.

[Bro] I tend to drop the reference to RFC 4086 then, if no one objects.

  *   In another tread a similar topic was discussed. This reference was proposed there. Even though it is from 2012, I like it and could add it next to the CVE reference as well.
Heninger, N., Durumeric, Z., Wustrow, E., and J. Halderman, "Mining Your Ps and Qs: Detection of Widespread Weak Keys in Network Devices", Proceedings of the 21st USENIX Security Symposium , August 2012, <https://factorable.net/<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Ffactorable.net%2F__%3B!!GjvTz_vk!EPwUHUVFQX1hiMe8LI2F1Oo70mUnFf1QjzZ-RLiuJ9es_L66DCqFCFQGtbwF%24&data=04%7C01%7Chendrik.brockhaus%40siemens.com%7C7a44016f20bc41e510a008d9b117ee8c%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637735538610338323%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=%2F5pMxQasHwedD2ChKq2RgzJvo0TJI4cTW0WfRdD8UmA%3D&reserved=0>>.
https://www.usenix.org/conference/usenixsecurity12/technical-sessions/presentation/heninger<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Fwww.usenix.org%2Fconference%2Fusenixsecurity12%2Ftechnical-sessions%2Fpresentation%2Fheninger__%3B!!GjvTz_vk!EPwUHUVFQX1hiMe8LI2F1Oo70mUnFf1QjzZ-RLiuJ9es_L66DCqFCAwW1Iz4%24&data=04%7C01%7Chendrik.brockhaus%40siemens.com%7C7a44016f20bc41e510a008d9b117ee8c%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637735538610348279%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=aCldWoCamju7zuVysrg1%2BBCNMH0U3EAXsRlMItT1NnY%3D&reserved=0>

[Bro] I think we can keep both.

@Tim, did you have time to think about the paragraphs 2-4? Or should we just go with the first paragraph, like Rich proposed?
@Russ, Uri, what do you think?

Old:

New:

   Implementations must randomly generate nonces and private keys.
   The use of inadequate pseudo-random number generators (PRNGs) to
   generate cryptographic keys can result in little or no security. An attacker
   may find it much easier to reproduce the PRNG environment that
   produced the keys, searching the resulting small set of possibilities,
   rather than brute force searching the whole key space. As an example of
   predictable random numbers see CVE-2008-0166 [...], and some consequences
   of low-entropy random numbers are discussed in Mining Your Ps and Qs [...].
   The generation of quality random numbers is difficult. ISO/IEC 20543:2019 [...],
   NIST SP 800-90A Rev.1 [...], BSI AIS 31 V2.0 [...], and others offers valuable
   guidance in this area.

Hendrik