Announcement

Collapse
No announcement yet.

New Linux /dev/random RNG Revved For The 43rd Time

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • #21
    Originally posted by sdack View Post
    Not calling it hogwash as per your suggestion, but I would like to point out that this view is somewhat narrow-minded when it is about open source. Anyone can modify the code any way they like. Thus for cryptography options to be configurable at compile time should not be an issue. For options to be configurable at run-time do we need to rely on the kernel's own security model. However, simply making code unavailable is not a guarantee for security without a kernel itself being secure in the first place. From what I have read about LRNG does it offer mostly compile-time options and the concerns raised appear to be more FUD than founded. If there are no more real issues with it that one could address then one should start supporting it.
    Theoretically speaking if you a custom compiled kernel that only has FIPS 140-2 compliant algorithms and disable features such as dynamically loading modules/code wouldn't this be compliant?

    I am just asking a general question here, I am not that familiar with the kernel in this territory

    Comment


    • #22
      Originally posted by mdedetrich View Post

      Theoretically speaking if you a custom compiled kernel that only has FIPS 140-2 compliant algorithms and disable features such as dynamically loading modules/code wouldn't this be compliant?
      FIPS 140-2 is already outdated (FIPS 140-2 testing was available until September 21, 2021). Therefore FIPS 140-3 became mandatory since September 22, 2021 and it has some extra requirements concerning also RNGs; they must be able to be tested separately and in case of several RNG sources they cannot be dependent on each others in any way which is e.g. hard requirement in current IRQ based LRNG entropy gathering.
      The document of the new approach covers comprehensively all aspects and requirements:

      Comment


      • #23
        Thanks for the link to https://www.chronox.de/lrng/doc/lrng.pdf - it makes for interesting reading,

        While trying to find background to this, I found this posting to lkml



        Where Jason A Donenfeld replies, with no technical detail, to a previous patch set:

        "trying to implement some NIST specs is most certainly the wrong way to go about this [rewriting the RNG], will lock us into subpar crypto for years, and is basically a waste of time."

        So it strikes me there are some strong opinions floating about here. I do not know enough to have an opinion one way or another, and I don't have a link to a dispassionate knowledgeable observer who can provide incisive analysis and reasoned commentary on the situation. Reading the thread in which the above linked message can be found might be instructive and give some pointers. It certainly fills in the background at a very high level, but I wont attempt to summarise it, as I am bound to do so incorrectly.

        Comment


        • #24
          I'm not english native speaker but... "revved"?

          Comment


          • #25
            Originally posted by kokoko3k View Post
            I'm not english native speaker but... "revved"?
            https://www.oxfordlearnersdictionari.../english/rev_1
            Revised. https://www.oxfordlearnersdictionari...vise?q=revised

            Could also possibly be revisited. Or reviewed. Or possibly 'rev' as slang for turned around again (from revolution).

            Comment


            • #26
              Originally posted by sdack View Post
              Not calling it hogwash as per your suggestion, but I would like to point out that this view is somewhat narrow-minded when it is about open source. Anyone can modify the code any way they like. Thus for cryptography options to be configurable at compile time should not be an issue. For options to be configurable at run-time do we need to rely on the kernel's own security model. However, simply making code unavailable is not a guarantee for security without a kernel itself being secure in the first place. From what I have read about LRNG does it offer mostly compile-time options and the concerns raised appear to be more FUD than founded. If there are no more real issues with it that one could address then one should start supporting it.
              The problem with it being a compile-time option is that end users rarely do recompile (and they shouldn't really need to), while distros will always try to make it useful for the broadest amount of use cases, which means default kernels will always be FIPS 140-2 enabled to cater for the subset of people that needs so.
              At the same time, being able to disable it with a simple flag in the stock kernel is probably also an unacceptable solution for these people.

              Originally posted by Jakobson View Post
              FIPS has been a kernel configuration option and will also be in Stephan Müller's implementation (it's disabled by default).
              Is this a runtime or build-time only option? That would be a crucial difference.

              Originally posted by sdack View Post
              The current random number generator when used on embedded systems with limited entropy can certainly use some work considering how one has to run haveged in userland just to make it work.
              Embedded and very weak laptops. I just had to do that for an OLPC-like computer for a friend. He had to type random stuff for several seconds for booting before that.

              Originally posted by Old Grouch View Post
              "trying to implement some NIST specs is most certainly the wrong way to go about this [rewriting the RNG], will lock us into subpar crypto for years, and is basically a waste of time."
              Maybe calling it "subpar" does merit extra technical details, but calling it "outdated" does not. This kind of specs get frozen for years (basically until the next iteration comes out), so you're bound to get behind the latest algos. Which is not necessarily a bad thing, some people will definitely prefer the battle tested ones.
              Last edited by sinepgib; 23 November 2021, 06:57 AM.

              Comment


              • #27
                Originally posted by sinepgib View Post


                (quotation attributed to me)

                Maybe calling it "subpar" does merit extra technical details, but calling it "outdated" does not. This kind of specs get frozen for years (basically until the next iteration comes out), so you're bound to get behind the latest algos. Which is not necessarily a bad thing, some people will definitely prefer the battle tested ones.
                Just to point out, I was quoting Jason A Donenfeld's views in his posting to LKML, not mine. I am definitely not qualified to opine on the technical aspects here, and I'm trying not to come across as someone presenting content-free opinions as purported fact. Jason is considerably more qualified to comment than I am.

                As Jakobson points out above, FIPS 140-2 is now replaced with/superseded by FIPS 140-3, so FIPS 140-2 compliance is, I suspect, no longer the ultimate goal here.

                As for 'battle-tested' algorithms, I think cryptographers are rightly suspicious of state-sanctioned algorithms - the shenanigans around Dual EC - DRBG left a bad taste in many people's mouths, as did the earlier behaviour around the use of Crypto AG. However, the average end-user is unlikely to be trying to keep information secure against hostile nation-states, so discussions around use of algorithms is pretty academic except for a very small subset of people*. I'm not one of them.

                *There are reasonable, and reasoned arguments around whether it is a good idea to use the Linux kernel for any security critical work, especially if it is being run on a network-accessible cpu, but thankfully I am not in a position where such things are critically important. On the other hand, I quite like it if TLS is good enough to stop criminals emptying my bank account after recording an online banking session. Criminals have more resources than I do to probe weak algorithms.

                Comment


                • #28
                  Originally posted by Old Grouch View Post
                  Just to point out, I was quoting Jason A Donenfeld's views in his posting to LKML, not mine.
                  I know. I meant to quote the previous line as well, where you point out there are no technical details in his answer, which sounded like the claim was itself unfounded. My 2 cents is that at least the "stuck" part doesn't require a lot of technical arguments to prove it's most likely true.

                  Comment


                  • #29
                    Originally posted by sinepgib View Post

                    The problem with it being a compile-time option is that end users rarely do recompile (and they shouldn't really need to), while distros will always try to make it useful for the broadest amount of use cases, which means default kernels will always be FIPS 140-2 enabled to cater for the subset of people that needs so.
                    At the same time, being able to disable it with a simple flag in the stock kernel is probably also an unacceptable solution for these people..
                    FIPS-mode Kconfig option is disable by default. It has been disable all the time so far and will be disabled by default also later. I do not understand how kernels could be always be FIPS 140-2/3 enabled. The feature must be explicitly turn enabled and compile the kernel.
                    However other changes among the patchset will make LRNG also faster and all kernel user will benefit it regardless the FIPS mode.

                    Comment


                    • #30
                      The precieved downsides that a few people see, that I don't really buy into personally but I'm not a expert on it. Don't appear (IMO) to be enough to stop the patch set, considering the number of advantages it does bring. The FIPS argument is like any standards argument, they're often not perfect but for MANY organisations there is no choice, the project doesn't paused because you can't support the standard, it just finds a proprietary solution that will support it. And if that happens to be a very old version of your favourite open source project with very dubious patches applied, then that's what shall be used.

                      Hopefully 44 is the ticket!

                      Comment

                      Working...
                      X