2026-12.html.j2 (5997B)
1 {% extends "common/news.j2" %} 2 {% block body_content %} 3 4 <h1> 5 Successful attacks against 1024-bit RSA signatures</h1> 6 <p> 7 Laura Shea, Miro Haller, Adam Suhl, Nadia Heninger, and Emmanuel Thomé 8 published a report <a href="https://eprint.iacr.org/2026/2131"> 9 <i>"{{ _("Forging 1024-bit RSA signatures in nearly SNFS time") }}"</i></a> 10 on implementing and successfully executing a not so well-known attack to 11 forge RSA-1024 signatures by Joux, Naccache, and Thomé from 2007. The attack 12 applies in principle to the blind signatures used by GNU Taler and as far as 13 we know is the most efficient forgery attack on RSA signatures today. 14 </p> 15 <h2>Effects on Taler</h2> 16 <p> 17 Any real and recommended deployment of GNU Taler 18 is not at risk from this attack, 19 due to the following security measures in GNU Taler: 20 <ul> 21 <li><b>Secure defaults:</b> 22 Taler's default minimal security level is RSA-2048, 23 which makes the attack <i>economically</i> infeasible in practice. 24 </li> 25 <li><b>Key rotation:</b> 26 Taler supports key rotation of demonination keys, 27 with a default of once per week, 28 which makes the attack <i>technically</i> infeasible in practice. 29 </li> 30 <li><b>Alternative to RSA available:</b> 31 Taler supports blind signatures of type Clause-Schnorr—introduced 32 precisely as an alternative to RSA—which 33 are <i>not affected</i> by this attack. 34 </li> 35 </ul> 36 We provide more technical details in the analysis section below. 37 </p> 38 <p> 39 Though we've never recommended using RSA-1024 and the academic attack is rather 40 expensive, it still makes sense to analyze it to derive what its implications 41 are on how one should configure a GNU Taler exchange, after all forging RSA 42 signatures would enable an attacker to print money and bankrupt Taler 43 exchange operators! What follows is a coarse back-of-the-envelope rough 44 extrapolation of the cost of the attack against the standard GNU Taler 45 configuration. 46 </p> 47 <h2>Technical Analysis</h2> 48 <p> 49 At a high level, the attack requires two steps: obtaining many signatures, and 50 then doing an expensive computation using them. At RSA-2048, the recommended 51 minimal security level for GNU Taler, the attack requires the attacker to 52 obtain 2<sup>43</sup> signatures. Obtaining a signature from a Taler exchange 53 is pretty easy: you can just pay for one. However, you need this many signatures 54 for the same RSA key, and GNU Taler supports key rotation. Let's assume we 55 rotate keys once per week (our default), and an attacker attacks the 0.02 EUR 56 denomination (forging 0.01 EUR might be ineffective, given that the deposit fee 57 for 0.01 EUR is likely 0.01 EUR leaving no profit for the attacker). In that 58 case, you would need to withdraw 2<sup>43</sup> * 0.02 EUR or about 175 billion 59 Euros in a single week. As a point of comparision, the GDP of the European 60 Union is about 416 billion per week. 61 Now, assuming the attacker has that much money to 62 spend on buying the signatures, how about the computation? 63 </p> 64 <p> 65 Well, the first issue is the exchange server. While the attacker doesn't have 66 to provision it, it still must be able to respond to the attackers requests 67 and create a sufficient number of signatures. The exchange would need to create the 68 2<sup>43</sup> signatures in 7 days, and the current Taler implementation does not support 69 sharing the same RSA key across multiple machines (each host creates 70 its own private keys). Given a modern 256-core dual-die system where each core can create 71 approximately 10,000 RSA-2048 signatures per second we can get about 2<sup>41</sup> RSA 72 signatures per week from a single host, assuming the system does basically nothing else. 73 This would also require at least 15 GBit of sustained bandwidth for the 74 blinded values, blind signatures and other protocol overheads. Pretty impressive: 75 Taler theoretically could mint digital cash for the entire EU GDP on a single host, 76 even using a rather tiny denomination of 0.02 EUR. The 77 adversary would need to store at least the resulting 360 TB of signatures. 78 </p> 79 <p> 80 Still, that's only the first phase. In the second phase, the attacker 81 would need to do 2<sup>90</sup> computations. The authors write that 82 doing 2<sup>65</sup> computations (for RSA-1024) took 1380 core-years. So for RSA-2048, 83 this would imply 2<sup>25</sup> * 1380 core-years or approximately 46 billion 84 core-years. Realistic prices per core-year are around USD 100, 85 so the computational cost of the attack would be about 4.6 trillion USD, or 86 about 10% of the current US national debt. There is a little problem 87 with provisioning the compute though: a random Internet search suggests we have about 88 2 billion (suitable, high-performance) CPU cores available in data centers on the planet 89 (an alternative quick plausibility check suggested AMSL production limits 90 resulting in about 4-8 billion suitable CPU cores having been produced in total by 2026). 91 Taking the 2 billion number as available compute capacity, 92 the computational part of the attack would require 23 years, and 93 in the default configuration GNU Taler's blind signatures expire after about 2 years. 94 Hence, for a practical attack, an attacker would also have to scale global 95 available data center capacity by a factor of 10, and then use all 96 of it for two years. 97 </p> 98 <p> 99 In summary, RSA-2048, especially combined with key rotation, makes the 100 attack infeasible in practice. The GNU Taler default configuration should 101 remain safe until attacks improve significantly. Concerned central 102 banks for China, the US or Europe that require additional safety 103 margins are advised to increase the key rotation frequency for their 104 rCBDC GNU Taler deployments to once per day or even per hour. GNU Taler 105 also supports RSA-4096, but at this point we see no reason for anyone 106 to use settings beyond RSA-2048. 107 </p> 108 109 {% endblock body_content %}