[DISCUSSION,00/41] random: possible ways towards NIST SP800-90B compliance

Message

Nicolai Stange Sept. 21, 2020, 7:58 a.m. UTC

Hi all,

first of all, my apologies for the patch bomb following up in reply to this
mail here -- it's not meant to receive any serious review at all, but only
to support the discussion I'm hoping to get going.

As some of you might already be aware of, all new submissions for FIPS
certification will be required to comply with NIST SP800-90B from Nov 7th
on ([1], sec. 7.18 "Entropy Estimation and Compliance with SP 800-90B").
For reference: broadly speaking, NIST SP800-90B is about noise sources,
SP800-90A about the DRBG algorithms stacked on top and SP800-90C about how
everything is supposed to be glued together. The main requirements from
SP800-90B are
- no correlations between different noise sources,
- to continuously run certain health tests on a noise source's output and
- to provide an interface enabling access to the raw noise samples for
  validation purposes.

To my knowledge, all SP800-90B compliant noise sources available on Linux
today are either based on the Jitter RNG one way or another or on
architectural RNGs like e.g. x86's RDSEED or arm64's RNDRRS. Currently,
there's an in-kernel Jitter RNG implementation getting registered (c.f.
crypto/drbg.c, (*)) with the Crypto RNG API, which is also accessible from
userspace via AF_ALG. The userspace haveged ([2]) or jitterentropy
integrations ([3]) are worth mentioning in this context, too. So in
summary, I think that for the in-kernel entropy consumers falling under the
scope of FIPS, the currently only way to stay compliant would be to draw it
from said Crypto API RNG. For userspace applications there's the additional
option to invoke haveged and alike.

OTOH, CPU jitter based techniques are not uncontroversial ([4]). In any
case, it would certainly be a good idea to mix (xor or whatever) any jitter
output with entropy obtained from /dev/random (**). If I'm not mistaken,
the mentioned Crypto API RNG implementation (crypto/drbg.c) follows exactly
this approach, but doesn't enforce it yet: there's no
wait_for_random_bytes() and early DRBG invocations could in principle run
on seeds dominated entirely by jitterentropy. However, this can probably
get sorted quite easily and thus, one reasonable way towards maintaining
FIPS resp. SP800-90 compliance would be to
- make crypto/drbg.c invoke wait_for_random_bytes(),
- make all relevant in-kernel consumers to draw their random numbers from
  the Crypto RNG API, if not already the case and
- convert all relevant userspace to use a SP800-90B conforming Jitter RNG
  style noise source for compliance reasons, either by invoking the
  kernel's Crypto RNG API or by diffent means, and mix that with
  /dev/random.

Even though this would probably be feasible, I'm not sure that giving up on
/dev/random being the primary, well established source of randomness in
favor of each and every userspace crypto library rolling its own entropy
collection scheme is necessarily the best solution (it might very well be
though).

An obvious alternative would be to make /dev/random conform to SP800-90B.
Stephan Müller posted his "LRNG" patchset ([5]), in which he proposed to
introduce a second, independent implementation aiming at SP800-90[A-C]
conformance. However, it's in the 35th iteration now and my impression is
that there's hardly any discussion happening around this for quite a while
now. I haven't followed the earlier development, but I can imagine several
reasons for that:
- people are not really interested in FIPS or even questioning the whole
  concept in the first place (c.f. Theodore Ts'o remarks on this topic
  at [6]),
- potential reviewers got merely discouraged by the diffstat or
- people dislike the approach of having two competing implementations for
  what is basically the same functionality in the kernel.

In either case, I figured it might perhaps help further discussion to
provide at least a rough idea of how bad the existing /dev/random
implementation would get cluttered when worked towards SP800-90B
compliance. So I implemented the required health tests for the interrupt
noise source -- the resulting patches can be found in reply to this mail.
I'd like to stress(!) that this should really only be considered a first
step and that there would still be a long way towards a complete solution;
known open items are listed below. Also, I'm fully aware that making those
continuous health tests block the best effort primary_crng reseeds upon
failure is a ridiculous thing to do -- that's again meant for demonstration
purposes only, c.f. the commit log from the next to last patch. Anyway,
those of you who are interested in some more details beyond the mere
diffstat can find them after the list of references below.

In summary, I can imagine three feasible ways towards SP800-90 compliance:
1.) Put the burden on consumers. For in-kernel users this would mean
    conversion to the Jitter backed Crypto RNG API, in case that hasn't
    happened yet. Userspace is free to use any approved Jitter based
    mechanism for compliance reasons, but is encouraged to mix that with
    /dev/random.
2.) Merge Stephan's LRNG. Users/distros would have to decide between either
    of the two competing implementations at kernel config time.
3.) Develop the existing /dev/random towards compliance, ideally w/o
    affecting !fips_enabled users too much. This would likely require some
    redundancies as well as some atrocities imposed by the specs.

I'm looking forward to hearing your opinions and suggestions! In case you
happen to know of anybody who's not on CC but might potentially be
interested in FIPS, I'd highly appreciate it if you could point him/her to
this thread. The usual suspects are probably (enterprise?) distro folks,
but there might be others I haven't thought of.

Many thanks for your time!

Nicolai


(*) That's an oversimplification for the sake of brevity: actually
    SP800-90A DRBGs stacked on top of the SP800-90B conforming
    jitterentropy source get registered with the Crypto API.
(**) "/dev/random" is used as a synonym for everything related to
     drivers/char/random.c throughout this mail.

[1] https://csrc.nist.gov/csrc/media/projects/cryptographic-module-validation-program/documents/fips140-2/fips1402ig.pdf
[2] http://www.issihosts.com/haveged/
[3] http://www.chronox.de/jent/doc/CPU-Jitter-NPTRNG.html
    c.f. appendices C-E
[4] https://lwn.net/Articles/642166/
[5] https://lkml.kernel.org/r/[e-mail]
[6] https://lkml.kernel.org/r/[e-mail]
    https://lkml.kernel.org/r/[e-mail]
[7] https://lkml.kernel.org/r/[e-mail]


As promised above, some more details on the RFC series sent alongside
follow. The primary goal was to implement that health test functionality as
required by SP800-90B for the existing drivers/char/random.c without
affecting !fips_enabled users in any way. As outlined below, I failed quite
miserably as far as performance is concerned, but that shouldn't be
something which cannot get rectified. Kernel version v5.9-rc4 had been used
as a basis. The series can be logically subdivided into the following
parts:
- [1-5]: Preparatory cleanup.
- [6-17]: Implement support for deferring entropy credit dispatch to the
  global balance to long after the corresponding pool mixing operation has
  taken place. Needed for "holding back" entropy until the health tests
  have finished on the latest pending batch of samples.
- [18-21]: Move arch_get_random_{seed_,}long() out of the interrupt path.
  Needed to adhere to how SP800-90C expects multiple noise source to get
  combined, but is also worthwhile on its own from a performance POV.
- [22-23]: Don't award entropy to non-SP800-90B conforming architectural
  RNGs if fips_enabled is set.
- [24]: Move rand_initialize() to after time_init(). A "fix" for what is
  currently a non-issue, but it's a prerequisite for the subsequent patch.
- [25]: Detect cycle counter resolution, subsequently needed for making a
  per-IRQ entropy assessment.
- [26-28]: Follow Stephan's LRNG approach in how much entropy gets
  awarded to what: a lot more than before to add_interrupt_randomness(),
  none to add_{disk,input}_randomness() anymore.
- [29-33]: Introduce empty health test stubs and wire them up to
  add_interrupt_randomness().
- [34-36]: Implement the Adaptive Proportion Test (APT) as specified by
  SP800-90B and squeeze some more statistical power out of it.
- [37]: Implement SP800-90B's Repetition Count Test (RCT).
- [38-40]: Implement the startup tests, which are nothing but the
  continuous tests (APT + RCT) run on a specified amount of samples at
  boot time.
- [41]: Attempt to keep the system going in case the entropy estimate
  had been too optimistic and the health tests keep failing.

As the health tests are run from interrupt context on each sample, a
performance measurement is due. To this end, I configured a Raspberry Pi 2B
(ARMv7 Cortex A7) to disable all peripherals, gated a
19.2 MHz / 2048 ~= 9.3 kHz clock signal to some edge triggered GPIO and
function_graph traced add_interrupt_randomness() for 10 min from a busybox
initramfs. Unfortunately, the results had been a bit disappointing: with
fips_enabled being unset there had been a runtime degradation of ~12.5% w/o
SMP and ~5% w/ SMP resp. on average merely due to the application of the
patches onto the v5.9-rc4 base. However, as the amount of work should not
have changed much and given that struct fast_pool still fits into a single
cacheline, I'm optimistic that this can get rectified by e.g. introducing
a static_key for fips_enabled and perhaps shuffling branches a bit such
that the !fips_enabled code becomes more linear. OTOH, the impact of
enabling the health tests by means of setting fips_enabled had not been so
dramatic: the observed increase in average add_interrupt_randomness()
runtimes had been 6% w/o SMP and 5% w/ SMP respectively.

Apart from those well controlled experiments on a RPi, I also did some
lax benchmarking on my x86 desktop (which has some Intel i9, IIRC).
More specifically, I simply didn't touch the system and ftraced
add_interrupt_randomness() for 15 mins. The number of captured events had
been about 2000 in each configuration. Here the add_interrupt_randomness()
performance improved greatly: from 4.3 us on average w/o the patches down
to 2.0 us with the patches applied and fips_enabled. However, I suppose
this gain was due to the removal of RDSEED from add_interrupt_randomness().
Indeed, when inspecting the distribution of add_interrupt_randomness()
runtimes on plain v5.9-rc4 more closely, it can be seen that there's a
good portion of events (about 1/4th) where add_interrupt_randomness() took
about 10us. So I think that this comparison isn't really a fair one...


To the best of my knowledge, these are the remaining open questions/items
towards full SP800-90[A-C] compliance:
- There's no (debugfs?) interface for accessing raw samples for validation
  purposes yet. That would be doable though.
- try_to_generate_entropy() should probably get wired up to the health
  tests as well. More or less straightfoward to implement, too.
- Diverting fast_pool contents into net_rand_state is not allowed (for a
  related discussion on this topic see [7]).
- I've been told that SP800-90A is not a hard requirement yet, but I
  suppose it will eventually become one. This would mean that the chacha20
  RNG would have to get replaced by something approved for fips_enabled.
- The sequence of fast_pool -> input_pool -> extract_buf() operations
  is to be considered a "non-vetted conditioning component" in SP800-90B
  speak. It would follow that the output can't be estimated as having full
  entropy, but only 0.999 of its length at max. (c.f. sec. 3.1.5.2). This
  could be resolved by running a SP800-90A derivation function at CRNG
  reseeding for fips_enabled. extract_buf(), which is already SHA1 based,
  could perhaps be transformed into such one as well.
- The only mention of combining different noise sources I was able to find
  had been in SP800-90C, sec. 5.3.4 ("Using Multiple Entropy Sources"):
  it clearly states that the outputs have to be combined by concatenation.
  add_hwgenerator_randomness() mixes into the same input_pool as
  add_interrupt_randomness() though and I would expect that this isn't
  allowed, independent of whether the noise source backing the former
  is SP800-90B compliant or not. IIUC, Stephan solved this for his LRNG
  by maintaing a separate pool for the hw generator.
- SP800-90A sets an upper bound on how many bits may be drawn from a
  DRBG/crng before a reseed *must* take place ("reseed_interval"). In
  principle that shouldn't matter much in practice, at least not with
  CONFIG_NUMA: with reseed_interval == 2^32 bits, a single CRNG instance
  would be allowed to hand out only 500MB worth of randomness before
  reseeding, but a (single) numa crng chained to the primary_crng may
  produce as much as 8PB before the latter must eventually get reseeded
  from the input_pool. But AFAICT, a SP800-90A conforming implementation
  would still have to provide provisions for a blocking extract_crng().
- It's entirely unclear to me whether support for "prediction resistance
  requests" is optional. It would be a pity if it weren't, because IIUC
  that would effectively imply a return to the former blocking_pool
  behaviour, which is obviously a no-no.


Nicolai Stange (41):
  random: remove dead code in credit_entropy_bits()
  random: remove dead code for nbits < 0 in credit_entropy_bits()
  random: prune dead assignment to entropy_bits in credit_entropy_bits()
  random: drop 'reserved' parameter from extract_entropy()
  random: don't reset entropy to zero on overflow
  random: factor the exponential approximation in credit_entropy_bits()
    out
  random: let pool_entropy_delta() take nbits in units of
    2^-ENTROPY_SHIFT
  random: introduce __credit_entropy_bits_fast() for hot paths
  random: protect ->entropy_count with the pool spinlock
  random: implement support for delayed entropy dispatching
  random: convert add_timer_randomness() to queued_entropy API
  random: convert add_interrupt_randomness() to queued_entropy API
  random: convert try_to_generate_entropy() to queued_entropy API
  random: drop __credit_entropy_bits_fast()
  random: convert add_hwgenerator_randomness() to queued_entropy API
  random: convert random_ioctl() to queued_entropy API
  random: drop credit_entropy_bits() and credit_entropy_bits_safe()
  random: move arch_get_random_seed() calls in crng_reseed() into own
    loop
  random: reintroduce arch_has_random() + arch_has_random_seed()
  random: provide min_crng_reseed_pool_entropy()
  random: don't invoke arch_get_random_long() from
    add_interrupt_randomness()
  random: introduce arch_has_sp800_90b_random_seed()
  random: don't award entropy to non-SP800-90B arch RNGs in FIPS mode
  init: call time_init() before rand_initialize()
  random: probe cycle counter resolution at initialization
  random: implement support for evaluating larger fast_pool entropies
  random: increase per-IRQ event entropy estimate if in FIPS mode
  random: don't award entropy to disk + input events if in FIPS mode
  random: move definition of struct queued_entropy and related API
    upwards
  random: add a queued_entropy instance to struct fast_pool
  random: introduce struct health_test + health_test_reset()
    placeholders
  random: introduce health test stub and wire it up
  random: make health_test_process() maintain the get_cycles() delta
  random: implement the "Adaptive Proportion" NIST SP800-90B health test
  random: improve the APT's statistical power
  random: optimize the APT's presearch
  random: implement the "Repetition Count" NIST SP800-90B health test
  random: enable NIST SP800-90B startup tests
  random: make the startup tests include muliple APT invocations
  random: trigger startup health test on any failure of the health tests
  random: lower per-IRQ entropy estimate upon health test failure

 arch/arm64/include/asm/archrandom.h   |   33 +-
 arch/powerpc/include/asm/archrandom.h |   17 +-
 arch/s390/include/asm/archrandom.h    |   19 +-
 arch/x86/include/asm/archrandom.h     |   26 +-
 drivers/char/random.c                 | 1141 ++++++++++++++++++++++---
 include/linux/random.h                |   17 +
 init/main.c                           |    2 +-
 7 files changed, 1101 insertions(+), 154 deletions(-)

--
SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg), GF: Felix Imendörffer

Comments

Jason A. Donenfeld Sept. 21, 2020, 8:09 a.m. UTC | #1

I haven't looked into the details of this patchset yet, but your
description here indicates to me that this is motivated by FIPS
certification desires, which...worries me. I would like to rewrite the
RNG at some point, and I've started to work on a bunch of designs for
this (and proving them correct, too), but going about this via FIPS
certification or trying to implement some NIST specs is most certainly
the wrong way to go about this, will lock us into subpar crypto for
years, and is basically a waste of time.

Stephan Mueller Sept. 21, 2020, 8:40 a.m. UTC | #2

Am Montag, 21. September 2020, 09:58:16 CEST schrieb Nicolai Stange:

Hi Nicolai,

> Hi all,
> 
> first of all, my apologies for the patch bomb following up in reply to this
> mail here -- it's not meant to receive any serious review at all, but only
> to support the discussion I'm hoping to get going.

Thank you for this effort!
> 
> As some of you might already be aware of, all new submissions for FIPS
> certification will be required to comply with NIST SP800-90B from Nov 7th
> on ([1], sec. 7.18 "Entropy Estimation and Compliance with SP 800-90B").
> For reference: broadly speaking, NIST SP800-90B is about noise sources,
> SP800-90A about the DRBG algorithms stacked on top and SP800-90C about how
> everything is supposed to be glued together. The main requirements from
> SP800-90B are
> - no correlations between different noise sources,
> - to continuously run certain health tests on a noise source's output and
> - to provide an interface enabling access to the raw noise samples for
>   validation purposes.
> 
> To my knowledge, all SP800-90B compliant noise sources available on Linux
> today are either based on the Jitter RNG one way or another or on
> architectural RNGs like e.g. x86's RDSEED or arm64's RNDRRS. Currently,
> there's an in-kernel Jitter RNG implementation getting registered (c.f.
> crypto/drbg.c, (*)) with the Crypto RNG API, which is also accessible from
> userspace via AF_ALG. The userspace haveged ([2]) or jitterentropy
> integrations ([3]) are worth mentioning in this context, too. So in
> summary, I think that for the in-kernel entropy consumers falling under the
> scope of FIPS, the currently only way to stay compliant would be to draw it
> from said Crypto API RNG. For userspace applications there's the additional
> option to invoke haveged and alike.
> 
> OTOH, CPU jitter based techniques are not uncontroversial ([4]). In any
> case, it would certainly be a good idea to mix (xor or whatever) any jitter
> output with entropy obtained from /dev/random (**). If I'm not mistaken,
> the mentioned Crypto API RNG implementation (crypto/drbg.c) follows exactly
> this approach, but doesn't enforce it yet: there's no
> wait_for_random_bytes() and early DRBG invocations could in principle run
> on seeds dominated entirely by jitterentropy. However, this can probably
> get sorted quite easily and thus, one reasonable way towards maintaining
> FIPS resp. SP800-90 compliance would be to
> - make crypto/drbg.c invoke wait_for_random_bytes(),
> - make all relevant in-kernel consumers to draw their random numbers from
>   the Crypto RNG API, if not already the case and
> - convert all relevant userspace to use a SP800-90B conforming Jitter RNG
>   style noise source for compliance reasons, either by invoking the
>   kernel's Crypto RNG API or by diffent means, and mix that with
>   /dev/random.
> 
> Even though this would probably be feasible, I'm not sure that giving up on
> /dev/random being the primary, well established source of randomness in
> favor of each and every userspace crypto library rolling its own entropy
> collection scheme is necessarily the best solution (it might very well be
> though).
> 
> An obvious alternative would be to make /dev/random conform to SP800-90B.
> Stephan Müller posted his "LRNG" patchset ([5]), in which he proposed to
> introduce a second, independent implementation aiming at SP800-90[A-C]
> conformance. However, it's in the 35th iteration now and my impression is
> that there's hardly any discussion happening around this for quite a while
> now. I haven't followed the earlier development, but I can imagine several
> reasons for that:
> - people are not really interested in FIPS or even questioning the whole
>   concept in the first place (c.f. Theodore Ts'o remarks on this topic
>   at [6]),
> - potential reviewers got merely discouraged by the diffstat or

Maybe I followed the Linux principle a bit to much here? Release early, 
release often.

But with the v35, all goals I tried to achieve are now in (namely the last was 
to get rid of any non-cryptographic conditioning functions) and to have a very 
clean data processing / entropy analysis. I do not expect big changes any 
more.

> - people dislike the approach of having two competing implementations for
>   what is basically the same functionality in the kernel.

Is this really so bad considering the security implications on this topic? We 
also have multiple file systems, multiple memory allocators, etc...
> 
> In either case, I figured it might perhaps help further discussion to
> provide at least a rough idea of how bad the existing /dev/random
> implementation would get cluttered when worked towards SP800-90B
> compliance. So I implemented the required health tests for the interrupt
> noise source -- the resulting patches can be found in reply to this mail.
> I'd like to stress(!) that this should really only be considered a first
> step and that there would still be a long way towards a complete solution;
> known open items are listed below. Also, I'm fully aware that making those
> continuous health tests block the best effort primary_crng reseeds upon
> failure is a ridiculous thing to do -- that's again meant for demonstration
> purposes only, c.f. the commit log from the next to last patch. Anyway,
> those of you who are interested in some more details beyond the mere
> diffstat can find them after the list of references below.
> 
> In summary, I can imagine three feasible ways towards SP800-90 compliance:
> 1.) Put the burden on consumers. For in-kernel users this would mean
>     conversion to the Jitter backed Crypto RNG API, in case that hasn't
>     happened yet. Userspace is free to use any approved Jitter based
>     mechanism for compliance reasons, but is encouraged to mix that with
>     /dev/random.
> 2.) Merge Stephan's LRNG. Users/distros would have to decide between either
>     of the two competing implementations at kernel config time.
> 3.) Develop the existing /dev/random towards compliance, ideally w/o
>     affecting !fips_enabled users too much. This would likely require some
>     redundancies as well as some atrocities imposed by the specs.
> 
> I'm looking forward to hearing your opinions and suggestions! In case you
> happen to know of anybody who's not on CC but might potentially be
> interested in FIPS, I'd highly appreciate it if you could point him/her to
> this thread. The usual suspects are probably (enterprise?) distro folks,
> but there might be others I haven't thought of.
> 
> Many thanks for your time!
> 
> Nicolai
> 
> 
> (*) That's an oversimplification for the sake of brevity: actually
>     SP800-90A DRBGs stacked on top of the SP800-90B conforming
>     jitterentropy source get registered with the Crypto API.
> (**) "/dev/random" is used as a synonym for everything related to
>      drivers/char/random.c throughout this mail.
> 
> [1]
> https://csrc.nist.gov/csrc/media/projects/cryptographic-module-validation-p
> rogram/documents/fips140-2/fips1402ig.pdf [2]
> http://www.issihosts.com/haveged/
> [3] http://www.chronox.de/jent/doc/CPU-Jitter-NPTRNG.html
>     c.f. appendices C-E
> [4] https://lwn.net/Articles/642166/
> [5] https://lkml.kernel.org/r/[e-mail]
> [6] https://lkml.kernel.org/r/[e-mail]
>     https://lkml.kernel.org/r/[e-mail]
> [7] https://lkml.kernel.org/r/[e-mail]
> 
> 
> As promised above, some more details on the RFC series sent alongside
> follow. The primary goal was to implement that health test functionality as
> required by SP800-90B for the existing drivers/char/random.c without
> affecting !fips_enabled users in any way. As outlined below, I failed quite
> miserably as far as performance is concerned, but that shouldn't be
> something which cannot get rectified. Kernel version v5.9-rc4 had been used
> as a basis. The series can be logically subdivided into the following
> parts:
> - [1-5]: Preparatory cleanup.
> - [6-17]: Implement support for deferring entropy credit dispatch to the
>   global balance to long after the corresponding pool mixing operation has
>   taken place. Needed for "holding back" entropy until the health tests
>   have finished on the latest pending batch of samples.
> - [18-21]: Move arch_get_random_{seed_,}long() out of the interrupt path.
>   Needed to adhere to how SP800-90C expects multiple noise source to get
>   combined, but is also worthwhile on its own from a performance POV.
> - [22-23]: Don't award entropy to non-SP800-90B conforming architectural
>   RNGs if fips_enabled is set.
> - [24]: Move rand_initialize() to after time_init(). A "fix" for what is
>   currently a non-issue, but it's a prerequisite for the subsequent patch.
> - [25]: Detect cycle counter resolution, subsequently needed for making a
>   per-IRQ entropy assessment.
> - [26-28]: Follow Stephan's LRNG approach in how much entropy gets
>   awarded to what: a lot more than before to add_interrupt_randomness(),
>   none to add_{disk,input}_randomness() anymore.
> - [29-33]: Introduce empty health test stubs and wire them up to
>   add_interrupt_randomness().
> - [34-36]: Implement the Adaptive Proportion Test (APT) as specified by
>   SP800-90B and squeeze some more statistical power out of it.
> - [37]: Implement SP800-90B's Repetition Count Test (RCT).
> - [38-40]: Implement the startup tests, which are nothing but the
>   continuous tests (APT + RCT) run on a specified amount of samples at
>   boot time.
> - [41]: Attempt to keep the system going in case the entropy estimate
>   had been too optimistic and the health tests keep failing.
> 
> As the health tests are run from interrupt context on each sample, a
> performance measurement is due. To this end, I configured a Raspberry Pi 2B
> (ARMv7 Cortex A7) to disable all peripherals, gated a
> 19.2 MHz / 2048 ~= 9.3 kHz clock signal to some edge triggered GPIO and
> function_graph traced add_interrupt_randomness() for 10 min from a busybox
> initramfs. Unfortunately, the results had been a bit disappointing: with
> fips_enabled being unset there had been a runtime degradation of ~12.5% w/o
> SMP and ~5% w/ SMP resp. on average merely due to the application of the
> patches onto the v5.9-rc4 base. However, as the amount of work should not
> have changed much and given that struct fast_pool still fits into a single
> cacheline, I'm optimistic that this can get rectified by e.g. introducing
> a static_key for fips_enabled and perhaps shuffling branches a bit such
> that the !fips_enabled code becomes more linear. OTOH, the impact of
> enabling the health tests by means of setting fips_enabled had not been so
> dramatic: the observed increase in average add_interrupt_randomness()
> runtimes had been 6% w/o SMP and 5% w/ SMP respectively.
> 
> Apart from those well controlled experiments on a RPi, I also did some
> lax benchmarking on my x86 desktop (which has some Intel i9, IIRC).
> More specifically, I simply didn't touch the system and ftraced
> add_interrupt_randomness() for 15 mins. The number of captured events had
> been about 2000 in each configuration. Here the add_interrupt_randomness()
> performance improved greatly: from 4.3 us on average w/o the patches down
> to 2.0 us with the patches applied and fips_enabled. However, I suppose
> this gain was due to the removal of RDSEED from add_interrupt_randomness().
> Indeed, when inspecting the distribution of add_interrupt_randomness()
> runtimes on plain v5.9-rc4 more closely, it can be seen that there's a
> good portion of events (about 1/4th) where add_interrupt_randomness() took
> about 10us. So I think that this comparison isn't really a fair one...
> 
> 
> To the best of my knowledge, these are the remaining open questions/items
> towards full SP800-90[A-C] compliance:
> - There's no (debugfs?) interface for accessing raw samples for validation
>   purposes yet. That would be doable though.

I use the patch 12/13 from my patch series successfully for random.c too.

> - try_to_generate_entropy() should probably get wired up to the health
>   tests as well. More or less straightfoward to implement, too.

Correct, but when assessing this function as part of [1], I found hardly any 
entropy being provided with this component.

[1] https://www.bsi.bund.de/SharedDocs/Downloads/EN/BSI/Publications/Studies/
LinuxRNG/LinuxRNG_EN_V4_1.pdf?__blob=publicationFile&v=2

> - Diverting fast_pool contents into net_rand_state is not allowed (for a
>   related discussion on this topic see [7]).

Totally agreed, this is a bad design.

> - I've been told that SP800-90A is not a hard requirement yet, but I
>   suppose it will eventually become one. This would mean that the chacha20
>   RNG would have to get replaced by something approved for fips_enabled.
> - The sequence of fast_pool -> input_pool -> extract_buf() operations
>   is to be considered a "non-vetted conditioning component" in SP800-90B
>   speak. It would follow that the output can't be estimated as having full
>   entropy, but only 0.999 of its length at max. (c.f. sec. 3.1.5.2). This
>   could be resolved by running a SP800-90A derivation function at CRNG
>   reseeding for fips_enabled. extract_buf(), which is already SHA1 based,
>   could perhaps be transformed into such one as well.

The core issue may very well be the SHA-1: using SHA-1 and folding its output 
in half may be an artificial limit of the upper bound of entropy.

> - The only mention of combining different noise sources I was able to find
>   had been in SP800-90C, sec. 5.3.4 ("Using Multiple Entropy Sources"):
>   it clearly states that the outputs have to be combined by concatenation.
>   add_hwgenerator_randomness() mixes into the same input_pool as
>   add_interrupt_randomness() though and I would expect that this isn't
>   allowed, independent of whether the noise source backing the former
>   is SP800-90B compliant or not. IIUC, Stephan solved this for his LRNG
>   by maintaing a separate pool for the hw generator.

See 90B section 3.1.6: combining both via vetted conditioning function is 
accepted. 

> - SP800-90A sets an upper bound on how many bits may be drawn from a
>   DRBG/crng before a reseed *must* take place ("reseed_interval"). In
>   principle that shouldn't matter much in practice, at least not with
>   CONFIG_NUMA: with reseed_interval == 2^32 bits, a single CRNG instance
>   would be allowed to hand out only 500MB worth of randomness before
>   reseeding, but a (single) numa crng chained to the primary_crng may
>   produce as much as 8PB before the latter must eventually get reseeded
>   from the input_pool. But AFAICT, a SP800-90A conforming implementation
>   would still have to provide provisions for a blocking extract_crng().

The hard limit is 2^48 generate operation with up to 2^16 bytes each. This is 
a very large amount of data. If we start triggering reseeds early enough, a 
hard blocking may not be needed.

> - It's entirely unclear to me whether support for "prediction resistance
>   requests" is optional. It would be a pity if it weren't, because IIUC
>   that would effectively imply a return to the former blocking_pool
>   behaviour, which is obviously a no-no.

This is not required.


Ciao
Stephan

Torsten Duwe Sept. 22, 2020, 1:23 p.m. UTC | #3

On Mon, Sep 21, 2020 at 10:40:37AM +0200, Stephan Mueller wrote:
> Am Montag, 21. September 2020, 09:58:16 CEST schrieb Nicolai Stange:
> 
> > - people dislike the approach of having two competing implementations for
> >   what is basically the same functionality in the kernel.
> 
> Is this really so bad considering the security implications on this topic? We 
> also have multiple file systems, multiple memory allocators, etc...

Exactly. I thought Linux was about the freedom of choice. Some people choose
to get a FIPS certification for their Linux-based products, which mostly
means to restrict crypto capabilities to an "allowed" set, granted. But in
this case people might opt for some sort of "entropy QA". I find it hard to
accept that this option is suppressed, especially if it's because of personal
antipathy of the maintainer about the origin of this change and not for
technical reasons. Restrictions on cryptographic functionality are ok, but
health tests on entropy sources are not?

I do understand people's reluctance after the dual-ECC DRBG desaster, but
OTOH SElinux is generally considered an improvement. Definitely not
everything coming from that direction is tainted.

A big portion of this patch set is cleanup, another one said introduction of
entropy source monitoring. This is important, no matter what your attitude
towards certifications might be.

	Torsten

Greg KH Sept. 22, 2020, 4:21 p.m. UTC | #4

On Tue, Sep 22, 2020 at 03:23:44PM +0200, Torsten Duwe wrote:
> On Mon, Sep 21, 2020 at 10:40:37AM +0200, Stephan Mueller wrote:
> > Am Montag, 21. September 2020, 09:58:16 CEST schrieb Nicolai Stange:
> > 
> > > - people dislike the approach of having two competing implementations for
> > >   what is basically the same functionality in the kernel.
> > 
> > Is this really so bad considering the security implications on this topic? We 
> > also have multiple file systems, multiple memory allocators, etc...
> 
> Exactly. I thought Linux was about the freedom of choice.

http://www.islinuxaboutchoice.com/

:)

Torsten Duwe Sept. 22, 2020, 5:48 p.m. UTC | #5

On Tue, 22 Sep 2020 18:21:52 +0200
Greg Kroah-Hartman <[e-mail]> wrote:

> On Tue, Sep 22, 2020 at 03:23:44PM +0200, Torsten Duwe wrote:
> > On Mon, Sep 21, 2020 at 10:40:37AM +0200, Stephan Mueller wrote:
> > > Am Montag, 21. September 2020, 09:58:16 CEST schrieb Nicolai
> > > Stange:
> > > 
> > > > - people dislike the approach of having two competing
> > > > implementations for what is basically the same functionality in
> > > > the kernel.
> > > 
> > > Is this really so bad considering the security implications on
> > > this topic? We also have multiple file systems, multiple memory
> > > allocators, etc...
> > 
> > Exactly. I thought Linux was about the freedom of choice.
> 
> http://www.islinuxaboutchoice.com/
> 
> :)

Talk is cheap.

gzip -dc /proc/config.gz | wc -l
9789

:-P
	Torsten

Torsten Duwe Oct. 2, 2020, 12:38 p.m. UTC | #6

Almost two weeks passed and these are the "relevant" replies:

Jason personally does not like FIPS, and is afraid of
"subpar crypto". Albeit this patch set strictly isn't about
crypto at all; the crypto subsystem is in the unlucky position
to just depend on a good entropy source.

Greg claims that Linux (kernel) isn't about choice, which is clearly
wrong.

And this is all ???

There are options for stack protection. I can see bounds checking
and other sanity checks all over the place. And doing a similar thing
on entropy sources is a problem?

Admittedly, if entropy sources fail, the kernel will happily remain
running. No bad immediate effects in userland will arise. Only some
cryptographic algorithms, otherwise very decent, will run on
unneccessarily weak keys, probably causing some real-world problems.
Does anybody care?
The NIST and the BSI do, but that does not mean their solutions are
automatically wrong or backdoored.

There is now a well layed-out scheme to ensure quality randomness,
and a lot of work here has been put into its implementation.

Would some maintainer please comment on potential problems or
shortcomings? Otherwise a "Thanks, applied" would be appropriate, IMO.

	Torsten

Willy Tarreau Oct. 2, 2020, 1:15 p.m. UTC | #7

On Fri, Oct 02, 2020 at 02:38:36PM +0200, Torsten Duwe wrote:
> Almost two weeks passed and these are the "relevant" replies:
> 
> Jason personally does not like FIPS, and is afraid of
> "subpar crypto". Albeit this patch set strictly isn't about
> crypto at all; the crypto subsystem is in the unlucky position
> to just depend on a good entropy source.
> 
> Greg claims that Linux (kernel) isn't about choice, which is clearly
> wrong.

I think there's a small misunderstanding here, my understanding is
that for quite a while, the possibilities offered by the various
random subsystems or their proposed derivative used to range from
"you have to choose between a fast system that may be vulnerable
to some attacks, a system that might not be vulnerable to certain
attacks but might not always boot, or a slow system not vulnerable
to certain attacks". Greg's point seems to be that if we add an
option, it means it's yet another tradeoff between these possibilities
and that someone will still not be happy at the end of the chain. If
the proposed solution covers everything at once (performance,
reliability, unpredictability), then there probably is no more reason
for keeping alternate solutions at all, hence there's no need to give
the user the choice between multiple options when only one is known
to always be valid. At least that's how I see it and it makes sense
to me.

> And this is all ???

Possibly a lot of people got used to seeing the numerous versions
and are less attentive to new series, it's possible that your message
will wake everyone up.

Regards,
Willy

Greg KH Oct. 2, 2020, 1:33 p.m. UTC | #8

On Fri, Oct 02, 2020 at 03:15:55PM +0200, Willy Tarreau wrote:
> On Fri, Oct 02, 2020 at 02:38:36PM +0200, Torsten Duwe wrote:
> > Almost two weeks passed and these are the "relevant" replies:
> > 
> > Jason personally does not like FIPS, and is afraid of
> > "subpar crypto". Albeit this patch set strictly isn't about
> > crypto at all; the crypto subsystem is in the unlucky position
> > to just depend on a good entropy source.
> > 
> > Greg claims that Linux (kernel) isn't about choice, which is clearly
> > wrong.
> 
> I think there's a small misunderstanding here, my understanding is
> that for quite a while, the possibilities offered by the various
> random subsystems or their proposed derivative used to range from
> "you have to choose between a fast system that may be vulnerable
> to some attacks, a system that might not be vulnerable to certain
> attacks but might not always boot, or a slow system not vulnerable
> to certain attacks". Greg's point seems to be that if we add an
> option, it means it's yet another tradeoff between these possibilities
> and that someone will still not be happy at the end of the chain. If
> the proposed solution covers everything at once (performance,
> reliability, unpredictability), then there probably is no more reason
> for keeping alternate solutions at all, hence there's no need to give
> the user the choice between multiple options when only one is known
> to always be valid. At least that's how I see it and it makes sense
> to me.

Thanks for spelling it out in much more detail than I was willing to :)

thanks,

greg k-h

Van Leeuwen, Pascal Oct. 2, 2020, 1:35 p.m. UTC | #9

Torsten,

Ok, if you must have more replies then I'll bite :-)

> -----Original Message-----
> From: Torsten Duwe <[e-mail]>
> Sent: Friday, October 2, 2020 2:39 PM
> To: Theodore Y. Ts'o <[e-mail]>
> Cc: [e-mail]; Nicolai Stange <[e-mail]>; LKML <[e-mail]>; Arnd Bergmann
> <[e-mail]>; Greg Kroah-Hartman <[e-mail]>; Eric W. Biederman <[e-mail]>; Alexander
> E. Patrakov <[e-mail]>; Ahmed S. Darwish <[e-mail]>; Willy Tarreau <[e-mail]>; Matthew Garrett
> <[e-mail]>; Vito Caputo <[e-mail]>; Andreas Dilger <[e-mail]>; Jan Kara <[e-mail]>;
> Ray Strode <[e-mail]>; William Jon McCann <[e-mail]>; zhangjs <[e-mail]>; Andy Lutomirski
> <[e-mail]>; Florian Weimer <[e-mail]>; Lennart Poettering <[e-mail]>; Peter Matthias
> <[e-mail]>; Marcelo Henrique Cerri <[e-mail]>; Neil Horman <[e-mail]>;
> Randy Dunlap <[e-mail]>; Julia Lawall <[e-mail]>; Dan Carpenter <[e-mail]>; Andy Lavr
> <[e-mail]>; Eric Biggers <[e-mail]>; Jason A. Donenfeld <[e-mail]>; Stephan Müller
> <[e-mail]>; Petr Tesarik <[e-mail]>
> Subject: Re: [DISCUSSION PATCH 00/41] random: possible ways towards NIST SP800-90B compliance
>
> <<< External Email >>>
> Almost two weeks passed and these are the "relevant" replies:
>
> Jason personally does not like FIPS, and is afraid of
> "subpar crypto". Albeit this patch set strictly isn't about
> crypto at all; the crypto subsystem is in the unlucky position
> to just depend on a good entropy source.
>
IMHO, Jason's statement is completely silly and solely based on some personal beef.
Obviously, the _ability_ to be compliant with FIPS testing does not preclude the use
of non-FIPS crypto, in case you should choose not to trust any of the FIPS recommended
implementations.

Fact of the matter is, many application areas (including but not limited to defence,
industrial automation, automotive, aero space, ...) have a hard a hard requirement on
FIPS certification. So not supporting that would either rule out using Linux altogether,
or steer them towards out-of-tree solutions.

And just running tests on your entropy source can't possibly be a bad thing anyway,
especially if you can configure it out if don't need or want to have it.

> Greg claims that Linux (kernel) isn't about choice, which is clearly
> wrong.
>
Well, I'm not going to argue with Greg about that ;-)

> And this is all ???
>
> There are options for stack protection. I can see bounds checking
> and other sanity checks all over the place. And doing a similar thing
> on entropy sources is a problem?
>
> Admittedly, if entropy sources fail, the kernel will happily remain
> running. No bad immediate effects in userland will arise. Only some
> cryptographic algorithms, otherwise very decent, will run on
> unneccessarily weak keys, probably causing some real-world problems.
> Does anybody care?
> The NIST and the BSI do, but that does not mean their solutions are
> automatically wrong or backdoored.
>
> There is now a well layed-out scheme to ensure quality randomness,
> and a lot of work here has been put into its implementation.
>
> Would some maintainer please comment on potential problems or
> shortcomings? Otherwise a "Thanks, applied" would be appropriate, IMO.
>
> Torsten

Regards,
Pascal van Leeuwen
Silicon IP Architect Multi-Protocol Engines, Rambus Security
Rambus ROTW Holding BV
[phone]

Note: The Inside Secure/Verimatrix Silicon IP team was recently acquired by Rambus.
Please be so kind to update your e-mail address book with my new e-mail address.

** This message and any attachments are for the sole use of the intended recipient(s). It may contain information that is confidential and privileged. If you are not the intended recipient of this message, you are prohibited from printing, copying, forwarding or saving it. Please delete the message and attachments and notify the sender immediately. **

Rambus Inc.<http://www.rambus.com>

Stephan Mueller Oct. 2, 2020, 1:56 p.m. UTC | #10

Am Freitag, 2. Oktober 2020, 15:15:55 CEST schrieb Willy Tarreau:

Hi Willy,

> > And this is all ???
> 
> Possibly a lot of people got used to seeing the numerous versions
> and are less attentive to new series, it's possible that your message
> will wake everyone up.

I think that points to my patch series. My patch series which provide a 
complete separate, API and ABI compliant drop in replacement of /dev/random, 
nobody from the gatekeepers cared to even answer. It would not touch the 
existing code.

After waiting some time without changing the code (e.g. after Andi Lutomirski 
commented), I got no answer at all from the gatekeepers, not even any 
indication in what direction I should move if something was not desired in the 
patch series.

Thus I continued adding the features that I think are necessary and for which 
I received comments from mathematicians. What else should I do?

With the patch set v35 of my patch series, I see all my goals finally 
achieved at I expect the code to be stable from here on. The last one was the 
hardest: to get rid of all non-cryptographic conditioning operations and yet 
retain performance en par or even superior to the existing /dev/random 
implementation.

Ciao
Stephan

Greg KH Oct. 2, 2020, 2:04 p.m. UTC | #11

On Fri, Oct 02, 2020 at 01:35:18PM +0000, Van Leeuwen, Pascal wrote:
> ** This message and any attachments are for the sole use of the intended recipient(s). It may contain information that is confidential and privileged. If you are not the intended recipient of this message, you are prohibited from printing, copying, forwarding or saving it. Please delete the message and attachments and notify the sender immediately. **

As per my legal department requests, this is now ignored and deleted on
my system...

Hint, it's not a valid footer for public mailing lists...

greg k-h

Torsten Duwe Oct. 2, 2020, 2:05 p.m. UTC | #12

On Fri, Oct 02, 2020 at 03:33:58PM +0200, Greg Kroah-Hartman wrote:
> On Fri, Oct 02, 2020 at 03:15:55PM +0200, Willy Tarreau wrote:
> > On Fri, Oct 02, 2020 at 02:38:36PM +0200, Torsten Duwe wrote:
> > > Almost two weeks passed and these are the "relevant" replies:
> > > 
> > > Jason personally does not like FIPS, and is afraid of
> > > "subpar crypto". Albeit this patch set strictly isn't about
> > > crypto at all; the crypto subsystem is in the unlucky position
> > > to just depend on a good entropy source.
> > > 
> > > Greg claims that Linux (kernel) isn't about choice, which is clearly
> > > wrong.
> > 
> > I think there's a small misunderstanding here, my understanding is
> > that for quite a while, the possibilities offered by the various
> > random subsystems or their proposed derivative used to range from
> > "you have to choose between a fast system that may be vulnerable
> > to some attacks, a system that might not be vulnerable to certain
> > attacks but might not always boot, or a slow system not vulnerable
> > to certain attacks". Greg's point seems to be that if we add an
> > option, it means it's yet another tradeoff between these possibilities
> > and that someone will still not be happy at the end of the chain. If
> > the proposed solution covers everything at once (performance,
> > reliability, unpredictability), then there probably is no more reason
> > for keeping alternate solutions at all, hence there's no need to give
> > the user the choice between multiple options when only one is known
> > to always be valid. At least that's how I see it and it makes sense
> > to me.
> 
> Thanks for spelling it out in much more detail than I was willing to :)

I assume you're not trying to pull the discussion off-topic. The one and
only choice here is that some people believe in NIST and certifications.
Yes, others don't, no problem either. The former folks boot with fips=1,
that's it. Those people are usually certain about their decision.

That option is about to break, for reasons I stated previously. This patch
set is to introduce the now-missing pieces. One thing worth to discuss here
would be whether people not so security conscious should benefit from the
sanity checks as well. IMHO they should, because, as Willy explained, stick
with the option that's always valid.

My disappointment was that _none_ of the maintaners had an on-topic,
technical remark. I get the impression some read "FIPS" and stop, regardless
of the actual functionality.

	Torsten

Van Leeuwen, Pascal Oct. 2, 2020, 2:34 p.m. UTC | #13

> -----Original Message-----
> From: Greg Kroah-Hartman <[e-mail]>
> Sent: Friday, October 2, 2020 4:04 PM
> To: Van Leeuwen, Pascal <[e-mail]>
> Cc: Torsten Duwe <[e-mail]>; Theodore Y. Ts'o <[e-mail]>; [e-mail]; Nicolai Stange
> <[e-mail]>; LKML <[e-mail]>; Arnd Bergmann <[e-mail]>; Eric W. Biederman
> <[e-mail]>; Alexander E. Patrakov <[e-mail]>; Ahmed S. Darwish <[e-mail]>; Willy
> Tarreau <[e-mail]>; Matthew Garrett <[e-mail]>; Vito Caputo <[e-mail]>; Andreas Dilger
> <[e-mail]>; Jan Kara <[e-mail]>; Ray Strode <[e-mail]>; William Jon McCann <[e-mail]>;
> zhangjs <[e-mail]>; Andy Lutomirski <[e-mail]>; Florian Weimer <[e-mail]>; Lennart
> Poettering <[e-mail]>; Peter Matthias <[e-mail]>; Marcelo Henrique Cerri
> <[e-mail]>; Neil Horman <[e-mail]>; Randy Dunlap <[e-mail]>; Julia Lawall
> <[e-mail]>; Dan Carpenter <[e-mail]>; Andy Lavr <[e-mail]>; Eric Biggers
> <[e-mail]>; Jason A. Donenfeld <[e-mail]>; Stephan Müller <[e-mail]>; Petr Tesarik
> <[e-mail]>
> Subject: Re: [DISCUSSION PATCH 00/41] random: possible ways towards NIST SP800-90B compliance
>
> <<< External Email >>>
> On Fri, Oct 02, 2020 at 01:35:18PM +0000, Van Leeuwen, Pascal wrote:
> > ** This message and any attachments are for the sole use of the intended recipient(s). It may contain information that is
> confidential and privileged. If you are not the intended recipient of this message, you are prohibited from printing, copying,
> forwarding or saving it. Please delete the message and attachments and notify the sender immediately. **
>
> As per my legal department requests, this is now ignored and deleted on
> my system...
>
> Hint, it's not a valid footer for public mailing lists...
>
> greg k-h
It's automatically added by our company mail server ... not something I can control at all :-(
And using some external SMTP server would not pass our firewall.
So free webmail would be my only alternative, but I have a thorough dislike for web-based
tools, as I have yet to come across one with an even remotely acceptable user interface.

Regards,
Pascal van Leeuwen
Silicon IP Architect Multi-Protocol Engines, Rambus Security
Rambus ROTW Holding BV
[phone]

Note: The Inside Secure/Verimatrix Silicon IP team was recently acquired by Rambus.
Please be so kind to update your e-mail address book with my new e-mail address.

** This message and any attachments are for the sole use of the intended recipient(s). It may contain information that is confidential and privileged. If you are not the intended recipient of this message, you are prohibited from printing, copying, forwarding or saving it. Please delete the message and attachments and notify the sender immediately. **

Rambus Inc.<http://www.rambus.com>

Greg KH Oct. 2, 2020, 3:13 p.m. UTC | #14

On Fri, Oct 02, 2020 at 02:34:44PM +0000, Van Leeuwen, Pascal wrote:
> 
> 
> 
> > -----Original Message-----
> > From: Greg Kroah-Hartman <[e-mail]>
> > Sent: Friday, October 2, 2020 4:04 PM
> > To: Van Leeuwen, Pascal <[e-mail]>
> > Cc: Torsten Duwe <[e-mail]>; Theodore Y. Ts'o <[e-mail]>; [e-mail]; Nicolai Stange
> > <[e-mail]>; LKML <[e-mail]>; Arnd Bergmann <[e-mail]>; Eric W. Biederman
> > <[e-mail]>; Alexander E. Patrakov <[e-mail]>; Ahmed S. Darwish <[e-mail]>; Willy
> > Tarreau <[e-mail]>; Matthew Garrett <[e-mail]>; Vito Caputo <[e-mail]>; Andreas Dilger
> > <[e-mail]>; Jan Kara <[e-mail]>; Ray Strode <[e-mail]>; William Jon McCann <[e-mail]>;
> > zhangjs <[e-mail]>; Andy Lutomirski <[e-mail]>; Florian Weimer <[e-mail]>; Lennart
> > Poettering <[e-mail]>; Peter Matthias <[e-mail]>; Marcelo Henrique Cerri
> > <[e-mail]>; Neil Horman <[e-mail]>; Randy Dunlap <[e-mail]>; Julia Lawall
> > <[e-mail]>; Dan Carpenter <[e-mail]>; Andy Lavr <[e-mail]>; Eric Biggers
> > <[e-mail]>; Jason A. Donenfeld <[e-mail]>; Stephan Müller <[e-mail]>; Petr Tesarik
> > <[e-mail]>
> > Subject: Re: [DISCUSSION PATCH 00/41] random: possible ways towards NIST SP800-90B compliance
> >
> > <<< External Email >>>
> > On Fri, Oct 02, 2020 at 01:35:18PM +0000, Van Leeuwen, Pascal wrote:
> > > ** This message and any attachments are for the sole use of the intended recipient(s). It may contain information that is
> > confidential and privileged. If you are not the intended recipient of this message, you are prohibited from printing, copying,
> > forwarding or saving it. Please delete the message and attachments and notify the sender immediately. **
> >
> > As per my legal department requests, this is now ignored and deleted on
> > my system...
> >
> > Hint, it's not a valid footer for public mailing lists...
> >
> > greg k-h
> It's automatically added by our company mail server ... not something I can control at all :-(

Then your company can not contribute in Linux kernel development, as
this is obviously not allowed by such a footer.

Please work with your IT and legal department to fix this.

thanks,

greg k-h

Van Leeuwen, Pascal Oct. 2, 2020, 3:39 p.m. UTC | #15

> -----Original Message-----
> From: Greg Kroah-Hartman <[e-mail]>
> Sent: Friday, October 2, 2020 5:13 PM
> To: Van Leeuwen, Pascal <[e-mail]>
> Cc: Torsten Duwe <[e-mail]>; Theodore Y. Ts'o <[e-mail]>; [e-mail]; Nicolai Stange
> <[e-mail]>; LKML <[e-mail]>; Arnd Bergmann <[e-mail]>; Eric W. Biederman
> <[e-mail]>; Alexander E. Patrakov <[e-mail]>; Ahmed S. Darwish <[e-mail]>; Willy
> Tarreau <[e-mail]>; Matthew Garrett <[e-mail]>; Vito Caputo <[e-mail]>; Andreas Dilger
> <[e-mail]>; Jan Kara <[e-mail]>; Ray Strode <[e-mail]>; William Jon McCann <[e-mail]>;
> zhangjs <[e-mail]>; Andy Lutomirski <[e-mail]>; Florian Weimer <[e-mail]>; Lennart
> Poettering <[e-mail]>; Peter Matthias <[e-mail]>; Marcelo Henrique Cerri
> <[e-mail]>; Neil Horman <[e-mail]>; Randy Dunlap <[e-mail]>; Julia Lawall
> <[e-mail]>; Dan Carpenter <[e-mail]>; Andy Lavr <[e-mail]>; Eric Biggers
> <[e-mail]>; Jason A. Donenfeld <[e-mail]>; Stephan Müller <[e-mail]>; Petr Tesarik
> <[e-mail]>
> Subject: Re: [DISCUSSION PATCH 00/41] random: possible ways towards NIST SP800-90B compliance
>
> <<< External Email >>>
> On Fri, Oct 02, 2020 at 02:34:44PM +0000, Van Leeuwen, Pascal wrote:
> >
> >
> >
> > > -----Original Message-----
> > > From: Greg Kroah-Hartman <[e-mail]>
> > > Sent: Friday, October 2, 2020 4:04 PM
> > > To: Van Leeuwen, Pascal <[e-mail]>
> > > Cc: Torsten Duwe <[e-mail]>; Theodore Y. Ts'o <[e-mail]>; [e-mail]; Nicolai Stange
> > > <[e-mail]>; LKML <[e-mail]>; Arnd Bergmann <[e-mail]>; Eric W. Biederman
> > > <[e-mail]>; Alexander E. Patrakov <[e-mail]>; Ahmed S. Darwish <[e-mail]>; Willy
> > > Tarreau <[e-mail]>; Matthew Garrett <[e-mail]>; Vito Caputo <[e-mail]>; Andreas Dilger
> > > <[e-mail]>; Jan Kara <[e-mail]>; Ray Strode <[e-mail]>; William Jon McCann
> <[e-mail]>;
> > > zhangjs <[e-mail]>; Andy Lutomirski <[e-mail]>; Florian Weimer <[e-mail]>; Lennart
> > > Poettering <[e-mail]>; Peter Matthias <[e-mail]>; Marcelo Henrique Cerri
> > > <[e-mail]>; Neil Horman <[e-mail]>; Randy Dunlap <[e-mail]>; Julia Lawall
> > > <[e-mail]>; Dan Carpenter <[e-mail]>; Andy Lavr <[e-mail]>; Eric Biggers
> > > <[e-mail]>; Jason A. Donenfeld <[e-mail]>; Stephan Müller <[e-mail]>; Petr Tesarik
> > > <[e-mail]>
> > > Subject: Re: [DISCUSSION PATCH 00/41] random: possible ways towards NIST SP800-90B compliance
> > >
> > > <<< External Email >>>
> > > On Fri, Oct 02, 2020 at 01:35:18PM +0000, Van Leeuwen, Pascal wrote:
> > > > ** This message and any attachments are for the sole use of the intended recipient(s). It may contain information that is
> > > confidential and privileged. If you are not the intended recipient of this message, you are prohibited from printing, copying,
> > > forwarding or saving it. Please delete the message and attachments and notify the sender immediately. **
> > >
> > > As per my legal department requests, this is now ignored and deleted on
> > > my system...
> > >
> > > Hint, it's not a valid footer for public mailing lists...
> > >
> > > greg k-h
> > It's automatically added by our company mail server ... not something I can control at all :-(
>
> Then your company can not contribute in Linux kernel development, as
> this is obviously not allowed by such a footer.
>
Interesting, this has never been raised as a problem until today ...
Going back through my mail archive, it looks like they started automatically adding that some
3 months ago. Not that they informed anyone about that, it just silently happened.

> Please work with your IT and legal department to fix this.
>
Eh ... Greg ... that's not how that works in the real world. In the real world, legal and IT lay
down the law and you just comply with that (or hack your way around it, if you can ;-).

I'm already fighting the good fight trying to keep control of my development machines
because IT would just love to get rid of those (since not under IT control .... oh dear ...)
And obviously, you cannot do kernel development on a machine without root access.
It's annoying enough already to require IT support to provide explicit permission to open
the task manager on my own company laptop ... grmbl.

>
> thanks,
>
> greg k-h

Regards,
Pascal van Leeuwen
Silicon IP Architect Multi-Protocol Engines, Rambus Security
Rambus ROTW Holding BV
[phone]

Note: The Inside Secure/Verimatrix Silicon IP team was recently acquired by Rambus.
Please be so kind to update your e-mail address book with my new e-mail address.


** This message and any attachments are for the sole use of the intended recipient(s). It may contain information that is confidential and privileged. If you are not the intended recipient of this message, you are prohibited from printing, copying, forwarding or saving it. Please delete the message and attachments and notify the sender immediately. **

Rambus Inc.<http://www.rambus.com>

Randy Dunlap Oct. 2, 2020, 4:30 p.m. UTC | #16

On 10/2/20 8:39 AM, Van Leeuwen, Pascal wrote:
>> -----Original Message-----
>> From: Greg Kroah-Hartman <[e-mail]>
>> Sent: Friday, October 2, 2020 5:13 PM
>> To: Van Leeuwen, Pascal <[e-mail]>
>> Cc: Torsten Duwe <[e-mail]>; Theodore Y. Ts'o <[e-mail]>; [e-mail]; Nicolai Stange
>> <[e-mail]>; LKML <[e-mail]>; Arnd Bergmann <[e-mail]>; Eric W. Biederman
>> <[e-mail]>; Alexander E. Patrakov <[e-mail]>; Ahmed S. Darwish <[e-mail]>; Willy
>> Tarreau <[e-mail]>; Matthew Garrett <[e-mail]>; Vito Caputo <[e-mail]>; Andreas Dilger
>> <[e-mail]>; Jan Kara <[e-mail]>; Ray Strode <[e-mail]>; William Jon McCann <[e-mail]>;
>> zhangjs <[e-mail]>; Andy Lutomirski <[e-mail]>; Florian Weimer <[e-mail]>; Lennart
>> Poettering <[e-mail]>; Peter Matthias <[e-mail]>; Marcelo Henrique Cerri
>> <[e-mail]>; Neil Horman <[e-mail]>; Randy Dunlap <[e-mail]>; Julia Lawall
>> <[e-mail]>; Dan Carpenter <[e-mail]>; Andy Lavr <[e-mail]>; Eric Biggers
>> <[e-mail]>; Jason A. Donenfeld <[e-mail]>; Stephan Müller <[e-mail]>; Petr Tesarik
>> <[e-mail]>
>> Subject: Re: [DISCUSSION PATCH 00/41] random: possible ways towards NIST SP800-90B compliance
>>
>> <<< External Email >>>
>> On Fri, Oct 02, 2020 at 02:34:44PM +0000, Van Leeuwen, Pascal wrote:
>>>
>>>
>>>
>>>> -----Original Message-----
>>>> From: Greg Kroah-Hartman <[e-mail]>
>>>> Sent: Friday, October 2, 2020 4:04 PM
>>>> To: Van Leeuwen, Pascal <[e-mail]>
>>>> Cc: Torsten Duwe <[e-mail]>; Theodore Y. Ts'o <[e-mail]>; [e-mail]; Nicolai Stange
>>>> <[e-mail]>; LKML <[e-mail]>; Arnd Bergmann <[e-mail]>; Eric W. Biederman
>>>> <[e-mail]>; Alexander E. Patrakov <[e-mail]>; Ahmed S. Darwish <[e-mail]>; Willy
>>>> Tarreau <[e-mail]>; Matthew Garrett <[e-mail]>; Vito Caputo <[e-mail]>; Andreas Dilger
>>>> <[e-mail]>; Jan Kara <[e-mail]>; Ray Strode <[e-mail]>; William Jon McCann
>> <[e-mail]>;
>>>> zhangjs <[e-mail]>; Andy Lutomirski <[e-mail]>; Florian Weimer <[e-mail]>; Lennart
>>>> Poettering <[e-mail]>; Peter Matthias <[e-mail]>; Marcelo Henrique Cerri
>>>> <[e-mail]>; Neil Horman <[e-mail]>; Randy Dunlap <[e-mail]>; Julia Lawall
>>>> <[e-mail]>; Dan Carpenter <[e-mail]>; Andy Lavr <[e-mail]>; Eric Biggers
>>>> <[e-mail]>; Jason A. Donenfeld <[e-mail]>; Stephan Müller <[e-mail]>; Petr Tesarik
>>>> <[e-mail]>
>>>> Subject: Re: [DISCUSSION PATCH 00/41] random: possible ways towards NIST SP800-90B compliance
>>>>
>>>> <<< External Email >>>
>>>> On Fri, Oct 02, 2020 at 01:35:18PM +0000, Van Leeuwen, Pascal wrote:
>>>>> ** This message and any attachments are for the sole use of the intended recipient(s). It may contain information that is
>>>> confidential and privileged. If you are not the intended recipient of this message, you are prohibited from printing, copying,
>>>> forwarding or saving it. Please delete the message and attachments and notify the sender immediately. **
>>>>
>>>> As per my legal department requests, this is now ignored and deleted on
>>>> my system...
>>>>
>>>> Hint, it's not a valid footer for public mailing lists...
>>>>
>>>> greg k-h
>>> It's automatically added by our company mail server ... not something I can control at all :-(
>>
>> Then your company can not contribute in Linux kernel development, as
>> this is obviously not allowed by such a footer.
>>
> Interesting, this has never been raised as a problem until today ...
> Going back through my mail archive, it looks like they started automatically adding that some
> 3 months ago. Not that they informed anyone about that, it just silently happened.
> 
>> Please work with your IT and legal department to fix this.
>>
> Eh ... Greg ... that's not how that works in the real world. In the real world, legal and IT lay
> down the law and you just comply with that (or hack your way around it, if you can ;-).

That's how it worked at $big_companies that I have worked at.

If it's a company/business requirement that you do Linux kernel development work, (is it?)
then they should make that possible on internal systems or give you access to
external email server(s).

> I'm already fighting the good fight trying to keep control of my development machines
> because IT would just love to get rid of those (since not under IT control .... oh dear ...)
> And obviously, you cannot do kernel development on a machine without root access.
> It's annoying enough already to require IT support to provide explicit permission to open
> the task manager on my own company laptop ... grmbl.
> 
>>
>> thanks,
>>
>> greg k-h
> 
> Regards,
> Pascal van Leeuwen
> Silicon IP Architect Multi-Protocol Engines, Rambus Security
> Rambus ROTW Holding BV
> [phone]
> 
> Note: The Inside Secure/Verimatrix Silicon IP team was recently acquired by Rambus.
> Please be so kind to update your e-mail address book with my new e-mail address.
> 
> 
> ** This message and any attachments are for the sole use of the intended recipient(s). It may contain information that is confidential and privileged. If you are not the intended recipient of this message, you are prohibited from printing, copying, forwarding or saving it. Please delete the message and attachments and notify the sender immediately. **
> 
> Rambus Inc.<http://www.rambus.com>
>

Theodore Ts'o Oct. 2, 2020, 6:14 p.m. UTC | #17

On Fri, Oct 02, 2020 at 03:39:35PM +0000, Van Leeuwen, Pascal wrote:
> > Then your company can not contribute in Linux kernel development, as
> > this is obviously not allowed by such a footer.
> >
> Interesting, this has never been raised as a problem until today ...
> Going back through my mail archive, it looks like they started automatically adding that some
> 3 months ago. Not that they informed anyone about that, it just silently happened.

So use a private e-mail address (e.g., at fastmail.fm if you don't
want to run your mail server) and then tunnel out SMTP requests using
ssh.  It's not hard.  :-)

I've worked a multiple $BIG_COMPANY's, and I've been doing this for
decades.  It's also helpful when I need to send e-mails from
conference networks from my laptop....

						- Ted

Van Leeuwen, Pascal Oct. 2, 2020, 7:09 p.m. UTC | #18

> -----Original Message-----
> From: Theodore Y. Ts'o <[e-mail]>
> Sent: Friday, October 2, 2020 8:14 PM
> To: Van Leeuwen, Pascal <[e-mail]>
> Cc: Greg Kroah-Hartman <[e-mail]>; Torsten Duwe <[e-mail]>; [e-mail]; Nicolai Stange
> <[e-mail]>; LKML <[e-mail]>; Arnd Bergmann <[e-mail]>; Eric W. Biederman
> <[e-mail]>; Alexander E. Patrakov <[e-mail]>; Ahmed S. Darwish <[e-mail]>; Willy
> Tarreau <[e-mail]>; Matthew Garrett <[e-mail]>; Vito Caputo <[e-mail]>; Andreas Dilger
> <[e-mail]>; Jan Kara <[e-mail]>; Ray Strode <[e-mail]>; William Jon McCann <[e-mail]>;
> zhangjs <[e-mail]>; Andy Lutomirski <[e-mail]>; Florian Weimer <[e-mail]>; Lennart
> Poettering <[e-mail]>; Peter Matthias <[e-mail]>; Marcelo Henrique Cerri
> <[e-mail]>; Neil Horman <[e-mail]>; Randy Dunlap <[e-mail]>; Julia Lawall
> <[e-mail]>; Dan Carpenter <[e-mail]>; Andy Lavr <[e-mail]>; Eric Biggers
> <[e-mail]>; Jason A. Donenfeld <[e-mail]>; Stephan Müller <[e-mail]>; Petr Tesarik
> <[e-mail]>
> Subject: Re: [DISCUSSION PATCH 00/41] random: possible ways towards NIST SP800-90B compliance
>
> <<< External Email >>>
> On Fri, Oct 02, 2020 at 03:39:35PM +0000, Van Leeuwen, Pascal wrote:
> > > Then your company can not contribute in Linux kernel development, as
> > > this is obviously not allowed by such a footer.
> > >
> > Interesting, this has never been raised as a problem until today ...
> > Going back through my mail archive, it looks like they started automatically adding that some
> > 3 months ago. Not that they informed anyone about that, it just silently happened.
>
> So use a private e-mail address (e.g., at fastmail.fm if you don't
> want to run your mail server) and then tunnel out SMTP requests using
> ssh.  It's not hard.  :-)
>
Actually, for the last patches I sent I already had to tunnel them over some 3rd
party SMTP-over-HTTPS service because of our firewall blocking access to
the Gmail SMTP server I previously used for that :-(

I guess tunnelling over SSH is another option, although I have no idea how to
do such a thing (didn't know it was possible). At the end of the day, I am not
a software guy, so I'm not _that_ much into these kinds of things ...

That doesn't work for _regular_ mail, though, as I would not be able to setup
a mail client for that. I can't install anything and I can't even touch the settings
of my Outlook client :-(

For incoming mail I'm actually bulk forwarding the mailing list through my
Gmail account now because our mail server stopped accepting it directly.
WIth POP3 and IMAP being blocked, I still need to find some way to receive
patches without our Exchange server fubarring them though (tips are welcome!).
Right now the only solution I have is fetch them from my home PC and take
them to work on a USB stick. Welcome to 2020 ...

> I've worked a multiple $BIG_COMPANY's, and I've been doing this for
> decades.  It's also helpful when I need to send e-mails from
> conference networks from my laptop....
>
>

Regards,
Pascal van Leeuwen
Silicon IP Architect Multi-Protocol Engines, Rambus Security
Rambus ROTW Holding BV
[phone]

Note: The Inside Secure/Verimatrix Silicon IP team was recently acquired by Rambus.
Please be so kind to update your e-mail address book with my new e-mail address.
- Ted


** This message and any attachments are for the sole use of the intended recipient(s). It may contain information that is confidential and privileged. If you are not the intended recipient of this message, you are prohibited from printing, copying, forwarding or saving it. Please delete the message and attachments and notify the sender immediately. **

Rambus Inc.<http://www.rambus.com>

Eric Biggers Oct. 7, 2020, 4:24 a.m. UTC | #19

On Fri, Oct 02, 2020 at 02:38:36PM +0200, Torsten Duwe wrote:
> Almost two weeks passed and these are the "relevant" replies:
> 
> Jason personally does not like FIPS, and is afraid of
> "subpar crypto". Albeit this patch set strictly isn't about
> crypto at all; the crypto subsystem is in the unlucky position
> to just depend on a good entropy source.
> 
> Greg claims that Linux (kernel) isn't about choice, which is clearly
> wrong.
> 
> And this is all ???
> 
> There are options for stack protection. I can see bounds checking
> and other sanity checks all over the place. And doing a similar thing
> on entropy sources is a problem?
> 
> Admittedly, if entropy sources fail, the kernel will happily remain
> running. No bad immediate effects in userland will arise. Only some
> cryptographic algorithms, otherwise very decent, will run on
> unneccessarily weak keys, probably causing some real-world problems.
> Does anybody care?
> The NIST and the BSI do, but that does not mean their solutions are
> automatically wrong or backdoored.
> 
> There is now a well layed-out scheme to ensure quality randomness,
> and a lot of work here has been put into its implementation.
> 
> Would some maintainer please comment on potential problems or
> shortcomings? Otherwise a "Thanks, applied" would be appropriate, IMO.
> 

Well, very people are experts in the Linux RNG *and* have time to review large
patchsets, especially when three people are all proposing conflicting changes.
And those that might be able to review these patches aren't necessarily
interested in compliance with particular government standards.

Note that having multiple RNG implementations would cause fragmentation, more
maintenance burden, etc.  So IMO, that should be a last resort.  Instead we
should try to find an implementation that works for everyone.  I.e., at least to
me, Nicolai's patchset seems more on the right track than Stephan's patchset...

However, not everyone cares about "compliance".  So any changes for "compliance"
either need to have a real technical argument for making the change, *or* need
to be optional (e.g. controlled by fips_enabled).

AFAICS, this patchset mostly just talks about NIST SP800-90B compliance, and
doesn't make clear whether the changes make the RNG better, worse, or the same
from an actual technical perspective.

If that was properly explained, and if the answer was "better" or at least
"not worse", I expect that people would be more interested.

- Eric

Stephan Mueller Oct. 7, 2020, 5:52 a.m. UTC | #20

Am Mittwoch, 7. Oktober 2020, 06:24:09 CEST schrieb Eric Biggers:

Hi Eric,
> 
> Note that having multiple RNG implementations would cause fragmentation,
> more maintenance burden, etc.  So IMO, that should be a last resort. 
> Instead we should try to find an implementation that works for everyone. 
> I.e., at least to me, Nicolai's patchset seems more on the right track than
> Stephan's patchset...

Thank you for sharing your considerations.

If you say that only one implementation should be there, I am wondering why 
not considering an implementation that as significant advantages over the 
existing implementation as outlined in my cover letter to patch v35. In the 
default configuration, it compiles no code at all that has any bearing on 
government standards. Yet it has a more cryptographic sound approach to handle 
entropy. In addition is meant to be extensible allowing each user to pick and 
chose what he wants. Yet, users who do not want these extensions should not 
suffer from it (neither performance-wise, nor should they suffer from an 
unnecessary complex code that builds all options into one C file).

And speaking of fragmentation, if it is not *possible* to allow users to pick 
what they want and need (and yes, in some parts of the world or for some users 
these government standards are simply a necessity), we surely invite 
fragmentation. In the LRNG, I tried to have all operations critical to entropy 
compression and random number generation modularized so that the a can be 
replaced or extended if needed without fragmentation.

PS: The reason why I started the LRNG was not government standards, but the 
result of performing two studies. The one study was about entropy in 
virtualized environment which showed that we have significant entropy in 
virtual environments and yet the existing /dev/random implementation thinks 
there is much less available. Another study I maintain for years also shows 
that the entire entropy collection and heuristic on bare metal systems is also 
in need of advancements. Initially I provided patches to the existing /dev/
random implementation, but basically all were silently ignored.

Ciao
Stephan

Nicolai Stange Oct. 7, 2020, 10:38 a.m. UTC | #21

Eric Biggers <[e-mail]> writes:

> On Fri, Oct 02, 2020 at 02:38:36PM +0200, Torsten Duwe wrote:
>>
>> Would some maintainer please comment on potential problems or
>> shortcomings?
>> 
>
> Well, very people are experts in the Linux RNG *and* have time to review large
> patchsets, especially when three people are all proposing conflicting changes.
> And those that might be able to review these patches aren't necessarily
> interested in compliance with particular government standards.

To make it clear: I'm personally not really enthusiastic about some of
the restrictions imposed by SP800-90 either and Jason certainly has a
point with his concerns about "subpar crypto" ([1]). However, at the
same time I'm acknowledging that for some users FIPS compliance is
simply a necessity and I don't see a strong reason why that shouldn't be
supported, if doable without negatively affecting !fips_enabled users.


> Note that having multiple RNG implementations would cause fragmentation, more
> maintenance burden, etc.  So IMO, that should be a last resort.  Instead we
> should try to find an implementation that works for everyone.  I.e., at least to
> me, Nicolai's patchset seems more on the right track than Stephan's patchset...

I suppose that this concern about fragmentation is among the main
reasons for reservations against Stephan's LRNG patchset and that's why
I posted this RFC series here for comparison purposes. But note that, as
said ([2]), it's incomplete and the only intent was to provide at least
a rough idea on what it would take to move the current /dev/random
implementation towards SP800-90 -- I was hoping for either a hard NACK
or something along the lines of "maybe, go ahead and let's see".


> However, not everyone cares about "compliance".  So any changes for "compliance"
> either need to have a real technical argument for making the change, *or* need
> to be optional (e.g. controlled by fips_enabled).

Fully agreed.


> AFAICS, this patchset mostly just talks about NIST SP800-90B compliance, and
> doesn't make clear whether the changes make the RNG better, worse, or the same
> from an actual technical perspective.
>
> If that was properly explained, and if the answer was "better" or at least
> "not worse", I expect that people would be more interested.

The goal was not to negatively affect !fips_enabled users, but as
outlined in the cover letter ([2]), a performance impact had been
measured on ARMv7. This probably isn't something which couldn't get
sorted out, but I see no point in doing it at this stage, because
- there's still quite some stuff missing for full SP800-90 compliance
  anyway, c.f. the overview at the end of [2] and
- such optimizations would have bloated this patchset even more,
  e.g. for making fips_enabled a static_key, which should certainly go
  into a separate series.

User visible effects set aside, an obvious downside of SP800-90
compliance would be the increase in code size and the associated
maintenance burden.

That being said, I can imagine that those boot health tests could also
get enabled for !fips_enabled users in the future, if wanted: rather
than inhibiting /dev/random output on failure, a warning would get
logged instead.  Whether or not this would be seen as an improvement
is for others to judge though.

Thanks,

Nicolai


[1] https://lkml.kernel.org/r/[e-mail]
[2] https://lkml.kernel.org/r/[e-mail]

Torsten Duwe Oct. 16, 2020, 5:26 p.m. UTC | #22

On Fri, Oct 02, 2020 at 03:56:28PM +0200, Stephan Mueller wrote:
> Am Freitag, 2. Oktober 2020, 15:15:55 CEST schrieb Willy Tarreau:
> 
> Hi Willy,
> 
> > > And this is all ???
> > 
> > Possibly a lot of people got used to seeing the numerous versions
> > and are less attentive to new series, it's possible that your message
> > will wake everyone up.
> 
> I think that points to my patch series. My patch series which provide a 
> complete separate, API and ABI compliant drop in replacement of /dev/random, 
> nobody from the gatekeepers cared to even answer. It would not touch the 
> existing code.
> 
> After waiting some time without changing the code (e.g. after Andi Lutomirski 
> commented), I got no answer at all from the gatekeepers, not even any 
> indication in what direction I should move if something was not desired in the 
> patch series.
> 
> Thus I continued adding the features that I think are necessary and for which 
> I received comments from mathematicians. What else should I do?
> 
> With the patch set v35 of my patch series, I see all my goals finally 
> achieved at I expect the code to be stable from here on. The last one was the 
> hardest: to get rid of all non-cryptographic conditioning operations and yet 
> retain performance en par or even superior to the existing /dev/random 
> implementation.

Would you mind to resend it here, for a comparison?

	Torsten