The most important thing to know about this work, which is awesome, is that it relies on access to a raw RSA oracle, where you have a public key and an API that allows you to directly do RSA operations with the corresponding key. The idea is that you then lose access to the oracle, and thus to the private key, but you've gained enough information from your session with the oracle to make forgeries in the future.
So it's not a straightforward general-purpose RSA-1024 signature break; it's pretty situational. The paper goes into detail (in section 5) about how those situations can emerge in practical scenarios.
All these articles are merely clickbait. I knew there wasn't a real break in RSA before reading the article. It's just some weird subset of usage which allows this. It's nowhere near breaking RSA.
Why are we even contemplating quantum computers breaking encryption when they can't even factorize a 3-digit prime number? I'm wondering if I'll even see quantum computers breaking RSA in my lifetime.
I was expecting to see mention of Microsoft/Apple executable code-signing in the examples. I know key lengths are well beyond 1024 now, but on the Microsoft side it was (is?) possible for USB tokens to be distributed in the mail. What I don't know is whether the tokens could be used as oracles in this attack.
I was unaware of snfs algorithms for generic moduli and/or signatures. Very nice.
The theoretical result is purely due to the 2007 Joux et al. paper.
What’s new is the implementation and the 1024-bit rsa signature forgery.
Also no ai, so we can expect some speedups soon.
I really didn’t expect rsa to be targeted so much this year. Hope that these results will motivate people to pursue algorithmic improvements!
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?
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!
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.
Actually it's just thoughts from someone who has to deal with the fallout from this stuff. Which will include spending at least a week researching and writing up a sufficiently nontechnical analysis for mgt explaining why its completely irrelevant, all wasted time I should be spending dealing with actual real security issues.
But is that the fault of Heninger et al? Far from being academic and alarmist attention seekers, they have done the hard yards of dealing with real hardware, albeit a reduced difficulty variant.
I would say so, yes, because as I pointed out in my previous post, nowhere in the title or abstract do they say that this doesn't apply to virtually any use of RSA today. It's an interesting academic result but a giant headache for anyone who has to deal with the fallout, because anyone who reads about it will only see "RSA is broken" and demand action, and the cleanup task will fall on people who are already overloaded dealing with a malware infection and suspected penetration of one of the networks by parties unknown (probably Russia or China again) and an SAR audit all going on at the same time.
I don't think you can impose an obligation on academic authors to assume that dangerously uninformed people will glom on to keywords like 'RSA', not understand any of the content, and somehow this is the author's burden.
Yes, it creates bullshit for experts to deal with. Unfortunately dealing with bullshit is part of the job. The amount of AI hacking doomerism and naive super optimism I have to deal with is revolting, but grounding the paranoia and boosterism is part of the job.
The people I take issue with are the ones who claim expertise, and then say "This new paper says 1024 but RSA is broken, we must move to PQC immediately!" They are so good at blowing their own trumpet they get appointed to boards and are anointed as experts in regulators, and you can't expose them without experiencing institutional anger.
The same argument can be made for justifying shouting "fire" in a crowded theatre: "It was a war movie, they were taking their time shooting the other guys, I was just encouraging them, there's no obligation on me to assume that dangerously uninformed people will glom on to keywords like 'fire!' and respond to it". Courts have repeatedly ruled that anyone doing that should know better. In this case the actual result is "We present an improvement of an attack by Joux, Naccache, and Thome. While not applicable to the use of RSA today, it presents an interesting new avenue of research for signature forgery". There have been hundreds of papers presented at crypto conferences like this, "here's a neat new attack, theoretical only, but isn't it cool?". They did find one thing that was vulnerable, via direct PKCS #11 API access to an HSM where the vendor forgot to lock down the API properly, but then again if you've got PKCS #11 access there are dozens of ways to pull keys out of an HSM when the vendor doesn't bother locking down their API that don't involve this, and they take a few seconds or minutes, not months. In this case it's the old Luna HSM which has a pile of these vulns, including Mike Bond's work from more than 20 years ago and non-public stuff even before then. This is why no-one allows outside API access to an HSM, once you've got that it's game over.
Instead, the way this one has been presented leads to things like https://it.slashdot.org/story/26/09/24/1652228/theres-a-new-..., "a new way to break RSA encryption". I don't think this was just a case of "oops, we phrased that badly" because an IACR ePrint posting, of which there have been over 2,000 so far this year, doesn't get mainstream IT media coverage unless you've gone out of your way to attract it. Because of this I now have a missed phonecall from someone senior at 3:30am and three followup voicemails (luckily I keep my phone on silent overnight), all from someone who doesn't realise we're in a different time zone, I'll let you guess which country they're from. And I won't be the only one, there'll be a pile of security people in other organisations out there who have had their weekend and/or week messed up by this.
The most important thing to know about this work, which is awesome, is that it relies on access to a raw RSA oracle, where you have a public key and an API that allows you to directly do RSA operations with the corresponding key. The idea is that you then lose access to the oracle, and thus to the private key, but you've gained enough information from your session with the oracle to make forgeries in the future.
So it's not a straightforward general-purpose RSA-1024 signature break; it's pretty situational. The paper goes into detail (in section 5) about how those situations can emerge in practical scenarios.
It’s important to note that by “raw” they mean without padding, which is more rare than just a signing oracle, see section 7 of the paper.
Thank you for this nice explanation. I skimmed the abstract but didn't really understand it.
All these articles are merely clickbait. I knew there wasn't a real break in RSA before reading the article. It's just some weird subset of usage which allows this. It's nowhere near breaking RSA.
Why are we even contemplating quantum computers breaking encryption when they can't even factorize a 3-digit prime number? I'm wondering if I'll even see quantum computers breaking RSA in my lifetime.
I'm pretty sure you just described an IACR paper --- with Nadia Heninger's name on it --- as "clickbait"?
in the PDF metadata we find the proper and appropriate title of this work:
I was expecting to see mention of Microsoft/Apple executable code-signing in the examples. I know key lengths are well beyond 1024 now, but on the Microsoft side it was (is?) possible for USB tokens to be distributed in the mail. What I don't know is whether the tokens could be used as oracles in this attack.
Actually it does apply to some padding schemes but old ones those based on the adding of a fixed pattern of bits.
I was unaware of snfs algorithms for generic moduli and/or signatures. Very nice. The theoretical result is purely due to the 2007 Joux et al. paper. What’s new is the implementation and the 1024-bit rsa signature forgery.
Also no ai, so we can expect some speedups soon.
I really didn’t expect rsa to be targeted so much this year. Hope that these results will motivate people to pursue algorithmic improvements!
Good to hear .nice work
nice poem at the end of the paper
[dead]
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?
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!
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.
It is a rare privilege to read such volcanic straw-manning.
Actually it's just thoughts from someone who has to deal with the fallout from this stuff. Which will include spending at least a week researching and writing up a sufficiently nontechnical analysis for mgt explaining why its completely irrelevant, all wasted time I should be spending dealing with actual real security issues.
But is that the fault of Heninger et al? Far from being academic and alarmist attention seekers, they have done the hard yards of dealing with real hardware, albeit a reduced difficulty variant.
I would say so, yes, because as I pointed out in my previous post, nowhere in the title or abstract do they say that this doesn't apply to virtually any use of RSA today. It's an interesting academic result but a giant headache for anyone who has to deal with the fallout, because anyone who reads about it will only see "RSA is broken" and demand action, and the cleanup task will fall on people who are already overloaded dealing with a malware infection and suspected penetration of one of the networks by parties unknown (probably Russia or China again) and an SAR audit all going on at the same time.
I don't think you can impose an obligation on academic authors to assume that dangerously uninformed people will glom on to keywords like 'RSA', not understand any of the content, and somehow this is the author's burden.
Yes, it creates bullshit for experts to deal with. Unfortunately dealing with bullshit is part of the job. The amount of AI hacking doomerism and naive super optimism I have to deal with is revolting, but grounding the paranoia and boosterism is part of the job.
The people I take issue with are the ones who claim expertise, and then say "This new paper says 1024 but RSA is broken, we must move to PQC immediately!" They are so good at blowing their own trumpet they get appointed to boards and are anointed as experts in regulators, and you can't expose them without experiencing institutional anger.
The same argument can be made for justifying shouting "fire" in a crowded theatre: "It was a war movie, they were taking their time shooting the other guys, I was just encouraging them, there's no obligation on me to assume that dangerously uninformed people will glom on to keywords like 'fire!' and respond to it". Courts have repeatedly ruled that anyone doing that should know better. In this case the actual result is "We present an improvement of an attack by Joux, Naccache, and Thome. While not applicable to the use of RSA today, it presents an interesting new avenue of research for signature forgery". There have been hundreds of papers presented at crypto conferences like this, "here's a neat new attack, theoretical only, but isn't it cool?". They did find one thing that was vulnerable, via direct PKCS #11 API access to an HSM where the vendor forgot to lock down the API properly, but then again if you've got PKCS #11 access there are dozens of ways to pull keys out of an HSM when the vendor doesn't bother locking down their API that don't involve this, and they take a few seconds or minutes, not months. In this case it's the old Luna HSM which has a pile of these vulns, including Mike Bond's work from more than 20 years ago and non-public stuff even before then. This is why no-one allows outside API access to an HSM, once you've got that it's game over.
Instead, the way this one has been presented leads to things like https://it.slashdot.org/story/26/09/24/1652228/theres-a-new-..., "a new way to break RSA encryption". I don't think this was just a case of "oops, we phrased that badly" because an IACR ePrint posting, of which there have been over 2,000 so far this year, doesn't get mainstream IT media coverage unless you've gone out of your way to attract it. Because of this I now have a missed phonecall from someone senior at 3:30am and three followup voicemails (luckily I keep my phone on silent overnight), all from someone who doesn't realise we're in a different time zone, I'll let you guess which country they're from. And I won't be the only one, there'll be a pile of security people in other organisations out there who have had their weekend and/or week messed up by this.
From the article:
>Still, some real-world systems continue to use blind-signature, also known as textbook, RSA.
I think those are two different things.