‹ BackHN Continuity

Thread

Forging 1024-bit RSA signatures in nearly SNFS time [pdf]

72 points · 22 comments · int0x29

  1. pseudohadamard · · focus · HN ↗
    Another piece of overblown academic panic-mongering. It's been known since forever that you never use RSA that way, which is why every single standard that specifies RSA use also specifies padding mechanisms designed to avoid this, but nowhere in the title or abstract, which is about all that 99% of non-cryptographers will read, does it ever mention this. In fact it's written to imply the exact opposite.

    This is not "we broke RSA", it's "we managed to find an implementation you've probably never heard of before that's so broken that an attack that nothing should be vulnerable to is actually feasible". This is a blog post, not a news story. I found a much bigger vuln than this in Android RSA auth some years ago, I'm talking beginner-level crypto misuse, told Google about it, and it was quietly fixed. I didn't publish a paper about it or get it in the news because it was a non-story.

    Except that in this case every single piece of crypto code or downstream app out there that has the name "RSA" associated with it, which is all of them, has to reassure every one of its users who have seen the news headline that no, it's overblown hype, you're not vulnerable, nothing to do since there's no vulnerability present in your use of RSA.

    The worst possible outcome would be if this thing actually gets a CVE assigned to it. How do you fix a "vulnerability" that doesn't exist?

    1. nullc · · focus · HN ↗
      From a security perspective perhaps it's not that interesting-- although signing oracles are all too common access to one is already close enough to a total break even before getting to the padding restriction. (e.g. go ahead and sign post dated certificates too).

      But the technique is interesting as an object of study, in a way that finding "beginner-levle crypto misuse" absolutely wouldn't be, so it makes it more relevant as an academic publication. It further clarifies just how fragile these constructs are.

      Also from a security perspective I suspect this may be a total break on some blind signature token schemes that use RSA. I've seen some of those avoid using ECC on the basis of the complexity required to avoid one-more-signature attacks that require making a fair number of concurrent blind signatures. (and have a shape a lot like this attack!)

      > How do you fix a "vulnerability" that doesn't exist?

      Don't make a signing oracle (esp one that doesn't even do the padding itself) available!

      1. pseudohadamard · · focus · HN ↗
        For the last bit see my longish reply above. PKCS #11 when the vendor doesn't bother locking down their API, which the one in the paper didn't, gives you a whole string of ways to pull keys out of HSMs, which is why you put your HSM behind as many layers of access control as you can manage. Either that or buy an HSM which the vendor has locked down so attacks like the one in the paper just bounce off.

        But really, never expose your HSM to outside access because for most of them the keys will be extractable one way or another.

Open on Hacker News to reply ↗

Unofficial Hacker News client; not affiliated with Y Combinator.