Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1464324
| From | Stephan Mueller <smueller@chronox.de> |
|---|---|
| Newsgroups | linux.kernel |
| Subject | Re: [PATCH v6 0/5] /dev/random - a new approach |
| Date | 2016-08-17 07:30 +0200 |
| Message-ID | <s71Am-545-13@gated-at.bofh.it> (permalink) |
| References | <s4Xhw-3LZ-17@gated-at.bofh.it> <s6Fqa-7v0-7@gated-at.bofh.it> <s6V1T-yS-15@gated-at.bofh.it> |
| Organization | linux.* mail to news gateway |
Am Dienstag, 16. August 2016, 15:28:45 CEST schrieb H. Peter Anvin: Hi Peter, > > > > There are two motivations for that: > > > > - the current /dev/random is compliant to NTG.1 from AIS 20/31 which > > requires (in brief words) that entropy comes from auditible noise > > sources. Currently in my LRNG only RDRAND is a fast noise source which is > > not auditible (and it is designed to cause a VM exit making it even > > harder to assess it). To make the LRNG to comply with NTG.1, RDRAND can > > provide entropy but must not become the sole entropy provider which is > > the case now with that change. > > > > - the current /dev/random implementation follows the same concept with the > > exception of 3.15 and 3.16 where RDRAND was not rate-limited. In later > > versions, this was changed. > > I'm not saying it should be *sole*. I am questioning the value in > limiting it, as it seems to me that it could only ever produce a worse > result. It is not about the limiting of the data. It is all about the entropy estimate for those noise sources and how they affect the entropy estimator behind /dev/ random. If that fast noise source injects large amount of data but does not increase the entropy estimator, it is of no concern. Ciao Stephan
Back to linux.kernel | Previous | Next — Previous in thread | Find similar | Unroll thread
[PATCH v6 0/5] /dev/random - a new approach Stephan Mueller <smueller@chronox.de> - 2016-08-11 14:30 +0200
Re: [PATCH v6 0/5] /dev/random - a new approach Theodore Ts'o <tytso@mit.edu> - 2016-08-11 23:40 +0200
Re: [PATCH v6 0/5] /dev/random - a new approach Stephan Mueller <smueller@chronox.de> - 2016-08-12 11:40 +0200
Re: [PATCH v6 0/5] /dev/random - a new approach Theodore Ts'o <tytso@mit.edu> - 2016-08-12 21:30 +0200
Re: [PATCH v6 0/5] /dev/random - a new approach Stephan Mueller <smueller@chronox.de> - 2016-08-15 08:20 +0200
Re: [PATCH v6 0/5] /dev/random - a new approach Theodore Ts'o <tytso@mit.edu> - 2016-08-15 17:10 +0200
Re: [PATCH v6 0/5] /dev/random - a new approach Pavel Machek <pavel@ucw.cz> - 2016-08-17 23:50 +0200
Re: [PATCH v6 0/5] /dev/random - a new approach Theodore Ts'o <tytso@mit.edu> - 2016-08-19 03:20 +0200
Re: [PATCH v6 0/5] /dev/random - a new approach Pavel Machek <pavel@ucw.cz> - 2016-08-19 03:30 +0200
Re: [PATCH v6 0/5] /dev/random - a new approach Theodore Ts'o <tytso@mit.edu> - 2016-08-19 05:20 +0200
Re: [PATCH v6 0/5] /dev/random - a new approach Herbert Xu <herbert@gondor.apana.org.au> - 2016-08-19 08:00 +0200
Re: [PATCH v6 0/5] /dev/random - a new approach "H. Peter Anvin" <hpa@linux.intel.com> - 2016-08-19 19:30 +0200
Re: [PATCH v6 0/5] /dev/random - a new approach Herbert Xu <herbert@gondor.apana.org.au> - 2016-08-21 05:20 +0200
Re: [PATCH v6 0/5] /dev/random - a new approach Pavel Machek <pavel@ucw.cz> - 2016-08-19 09:50 +0200
Re: [PATCH v6 0/5] /dev/random - a new approach "H. Peter Anvin" <hpa@linux.intel.com> - 2016-08-15 22:50 +0200
Re: [PATCH v6 0/5] /dev/random - a new approach Stephan Mueller <smueller@chronox.de> - 2016-08-16 07:50 +0200
Re: [PATCH v6 0/5] /dev/random - a new approach "H. Peter Anvin" <hpa@linux.intel.com> - 2016-08-17 00:30 +0200
Re: [PATCH v6 0/5] /dev/random - a new approach "H. Peter Anvin" <hpa@linux.intel.com> - 2016-08-17 00:50 +0200
Re: [PATCH v6 0/5] /dev/random - a new approach Stephan Mueller <smueller@chronox.de> - 2016-08-17 07:30 +0200
csiph-web