Announcement

Collapse
No announcement yet.

Libgcrypt/GnuPG Hit By Critical Security Problem Since 1998

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

  • #11
    Bug wouldn't be found if it was lroprietary. I wonder how many critical bugs are present in windows, os x or some other proprietary crap? Nobody knows.

    Comment


    • #12
      Originally posted by Sonadow View Post
      Wonderful, an 18 year old vulnerability.

      All the open source eyes in the world, and not a single one managed to catch this one until today.
      I have actually reacted the same as you mate, but to be honest with you I shook myself with a simple question: do we actually know how every single line of code really works? I doubt it; and this concern is valid, because think about it just a bit: all these companies for example add nearly every day new lines inside Linux kernel, therefore do we *really* know how their code really works or for what purposes has been added? Again, I doubt it.

      Just have a look at the majority of major exploitations and you will see their original source: nearly always within an API's deepest corners (usually implemented in C) and it's well hidden within macro or pointer chaos.

      Therefore instead of adding features on top of features, we should stop this absurd fast-pace release-new-feature-for-the-sake-of-impressing-our-investors concept and should realize we need a stabler system with safest code that is well tested and QA-ed extensively.

      I prefer having a 2-year released program with limited and well-known bugs to the developers, than having a 2-month released program full of silly, yet dangerous bugs that are difficult to replicate on different platforms.

      To clear my position, this is just my own opinion and should not be taken for granted.

      Comment


      • #13
        Originally posted by Sonadow View Post
        Wonderful, an 18 year old vulnerability.
        All the open source eyes in the world, and not a single one managed to catch this one until today.
        This bug is not in the code but in the logic.

        "An attacker who obtains 4640 bits from the RNG can trivially predict the next 160 bits of output"

        Logic bugs are bitches to find in general, logic bugs in crypto code are rockstar queen bitches of bugs as they need GOOD cryptoanalists and a shitton of luck to be detected.

        Comment


        • #14
          Originally posted by stephen82 View Post
          Therefore instead of adding features on top of features, we should stop this absurd fast-pace release-new-feature-for-the-sake-of-impressing-our-investors concept and should realize we need a stabler system with safest code that is well tested and QA-ed extensively.
          This is basically impossible until the company's leadership is fully composed of engineers.
          Marketing types (standard company leadership) don't know and don't care, and sell the product to other marketing types that don't know and don't care.

          Comment


          • #15
            RNG Whitening Bug Weakened All Versions of GPG http://qntra.net/2016/08/rng-whiteni...rsions-of-gpg/

            "In effect, this means that no key created with GPG to date carries more than 580 bytes of effective entropy (e.g., all 4096-bit and above RSA keys have 'subkeys' which – we now find – mathematically relate, in a possibly-exploitable way, to the primary key.) ... And thus we find that, due to the staggeringly-braindamaged design of the protocol and of this implementation, GPG users who elected to use longer-than-default GPG keys ended up with smaller-than-default effective cryptographic strength."

            Comment


            • #16
              Oh, whitening? Is that still legal? Wasn't it a just plain stupid trick to avoid using a proper RNG source? WTF is it doing in a GPG?

              Comment


              • #17
                Oh, the Phuctor guy. Ignore him, he has a history of spreading FUD about PGP being horribly broken and accusing anyone who corrects him of being part of some elaborate cover-up (and in at least one case, threatening to contact the university of the person who did so). If you're not familiar with Phuctor, it's a project analysing PGP keys for shared factors. He keeps releasing blog posts claiming to have broken a bunch of high-profile Debian and Linux developers' keys, when he's actually broken corrupted versions of their keys which are unusable because the self-signatures are broken. If pushed on it, he'll argue that some of the keys have valid self-signature - the ones for [email protected] and the copy of the log-broken TI calculator keys that some joker uploaded no doubt du, but they're hardly interesting.

                In this case, he appears to be misreading the announcement, which says that someone who sees the first 4640 bits of RNG output can predict the next 160 bits of output. Not every single output bit from then on, which is what would be necessary for his claim to be true, just those bits. There's an explanation of exactly why this happens here: http://formal.iti.kit.edu/~klebanov/...-2016-6313.pdf In short, the mixing function incorrectly replaces each block with a hash of part of the buffer that doesn't include that block, so the last block processed can be predicted if you know the entire rest of the buffer.

                Comment


                • #18
                  Originally posted by makomk View Post
                  Oh, the Phuctor guy. Ignore him, he has a history of spreading FUD about PGP being horribly broken and accusing anyone who corrects him of being part of some elaborate cover-up (and in at least one case, threatening to contact the university of the person who did so). If you're not familiar with Phuctor, it's a project analysing PGP keys for shared factors. He keeps releasing blog posts claiming to have broken a bunch of high-profile Debian and Linux developers' keys, when he's actually broken corrupted versions of their keys which are unusable because the self-signatures are broken. If pushed on it, he'll argue that some of the keys have valid self-signature - the ones for [email protected] and the copy of the log-broken TI calculator keys that some joker uploaded no doubt du, but they're hardly interesting.

                  In this case, he appears to be misreading the announcement, which says that someone who sees the first 4640 bits of RNG output can predict the next 160 bits of output. Not every single output bit from then on, which is what would be necessary for his claim to be true, just those bits. There's an explanation of exactly why this happens here: http://formal.iti.kit.edu/~klebanov/...-2016-6313.pdf In short, the mixing function incorrectly replaces each block with a hash of part of the buffer that doesn't include that block, so the last block processed can be predicted if you know the entire rest of the buffer.
                  What you say it might be true, but I know one thing for sure: this announcement among many others shook waters to the programming world. I hope more people, companies, and corporations would start taking testing and QA-ing more seriously, for the sake of public and private security.

                  Comment


                  • #19
                    Originally posted by stephen82 View Post
                    What you say it might be true, but I know one thing for sure: this announcement among many others shook waters to the programming world.
                    [citation needed]

                    Comment

                    Working...
                    X