lkml.org 
[lkml]   [2020]   [Oct]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    SubjectRe: [DISCUSSION PATCH 00/41] random: possible ways towards NIST SP800-90B compliance
    Date
    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


    \
     
     \ /
      Last update: 2020-10-07 07:55    [W:3.181 / U:1.036 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site