1. 39
  1. 9

    I really wish people would stop using such sensationalist headlines. Like tons of instances before, this is not an attack on RSA, but on a specific implementation. It’s like saying that regular expressions are broken when there’s a bug in grep.

    1. 9

      Like tons of instances before, this is not an attack on RSA, but on a specific implementation.

      It is demonstrated a bug in a specific implementation but is a bug that is very easy to introduce into RSA implementations. Newer public key cryptosystems are designed specifically to avoid this kind of bug by simply requiring that you provide some random bit pattern as the key. With RSA, there are a lot of key pairs of any given length that work with the algorithm but are significantly weaker than you would expect given their length, unless you carefully follow a bunch of rules.

      1. 4

        Well, this one is a bit of a pitfall of RSA that could potentially affect more implementations. But in this case there seems to be only one library that’s affected.

        1. 1

          or just a poorly written regular expression

        2. 6

          I shared the exploit code with certificate authorities and are aware that some have implemented checks in their certificate issuance process to avoid accepting keys vulnerable to this attack.

          Good mitigation. Props to the author and to LetsEncrypt for implementing this. :)

          1. 2

            Surely more than just the Fujifilm printers use the Basic Crypto Module of the Safezone library by Rambus. Can we expect more CVEs to come out against software that uses this library?

            1. 4

              Well, I haven’t seen these keys, and I have checked a lot of keys. So I can safely say that if there are other products using that library then either they’re not using it for key generation or they’re not very widely used or they’re not doing TLS or SSH.

              (And for the CVEs: No, I discussed that with Mitre and their current policy is that when multiple products use the same library that’s one CVE for all of them.)

              1. 2

                I recall a study a “few” years ago (with my current understanding of the passage of time it could easily be a decade :D)

                They basically got a large DB of public keys and just computed GCD of all of them, IIRC they found a few pairs. Could be worth someone doing again now (especially with the public CT logs providing a record of large numbers of RSA keys)

                1. 6

                  You mean https://factorable.net/

                  I have actually been trying to run this against CT log data, the problem is CT is really big and it goes beyond what this algorithm can practically handle.

                  1. 1

                    How big is really big?

                    1. 3

                      More than 6 billion certs. Just lookup a recent cert on crt.sh and check the id.

                      (Though this includes certs with duplicate keys - every cert these days has a precert - and non-RSA keys, but still - it’s a lot of keys.)

                  2. 2

                    Tangentially, one thing that does happen is VERY easily factorised public keys being uploaded to key servers as a result of bad RAM. If you’re storing a public key in RAM which introduces a bit flip due to a fault, it’s overwhelmingly likely that the bit flip will produce a number that is highly composite and easy to factor. The majority of really big numbers are highly composite, so a random bit flip from a good key almost always lands on a number that is highly composite.

                    1. 1

                      They basically got a large DB of public keys and just computed GCD of all of them, IIRC they found a few pairs. Could be worth someone doing again now (especially with the public CT logs providing a record of large numbers of RSA keys)

                      This concept is absolutely fascinating to me. I never thought of this being used/abused in this way!

                      1. 1

                        I remember hearing about this study as a grad student, so it has indeed been at least a decade :P

                        IIRC the effected devices were mostly embedded devices e.g. home routers and such, and it was supposed that there was an underlying problem with the randomness on those machines.

                        1. 4

                          Whenever something like this comes up it is always some network attached thing that sold in huge quantities (with reseller branding), no mechanism to disable the bad logic, and no ability to update the software even if the owners were aware of the problem.

                          Womp womp :)

                    2. 2

                      They also need someone to publish the keys somewhere, which is presumably the problem