Key points

  • The team forged signatures for a 1,024-bit RSA key without factoring the modulus or extracting the private key.
  • The experiment required about 2^32 oracle queries and 1,380 CPU core-years, making it a specialized research result rather than an immediate mass exploit.
  • Bitcoin and Ethereum use elliptic-curve signatures, while standard padded RSA deployments do not expose the raw operation used in the experiment.

A practical result for a long-known attack

Researchers from the University of California, San Diego and France's INRIA have demonstrated a full-scale forgery against a 1,024-bit RSA signing key without factoring the modulus or extracting the private key. Their preprint, “Forging 1024-bit RSA signatures in nearly SNFS time,” implements a 2007 algorithm by Antoine Joux, David Naccache and Emmanuel Thomé. The team used a hardware security module, or HSM, as a black-box signing oracle and then produced signatures that appeared to come from the protected key.

The cost was large and the access model was narrow

The authors report that the attack made about 2^32 signing queries and consumed 1,380 CPU core-years across roughly five calendar months. Most of that work was precomputation. Afterward, forging a chosen signature offline still required about 180 core-years, according to the paper. Those figures make the experiment an important cryptanalytic milestone, but they also show why the result is not a simple, low-cost method for compromising ordinary RSA systems. The researchers estimate that factoring the same modulus would have required far more computation, which is why the oracle-based route matters even though its resource demand remains extreme.

Related reporting: Quantum researchers cut key Bitcoin attack benchmark by 86%

Raw RSA access is the critical condition

The researchers needed temporary access to an interface that performed raw RSA operations on attacker-chosen values. In their test, the HSM's FIPS mode was disabled so the device would sign unformatted inputs. Modern RSA signature systems normally add structured padding, including PKCS#1 v1.5 or PSS, before the mathematical operation. Independent cryptographer Bruce Schneier noted that the technique targets unformatted signatures and does not translate into a general break of properly padded RSA deployments. Rate limits and strict API permissions would also make the billions of required queries easier to detect or prevent in a well-managed production environment.

Bitcoin and Ethereum signatures are not broken

The result also does not compromise Bitcoin or Ethereum transaction signing. Bitcoin uses elliptic-curve cryptography, including ECDSA and Schnorr signatures, while Ethereum accounts use ECDSA. The paper focuses on RSA, a different signature family. The relevance to digital assets is therefore indirect: exchanges, custodians and other institutions may use HSMs across wider security infrastructure, but exposure depends on the algorithm, device configuration, API permissions and whether raw signing operations are available.

Why security teams will still pay attention

The paper argues that RSA security in this signing-oracle model may be 15 to 30 bits lower than estimates based only on factoring for key sizes from 1,024 to 4,096 bits. That is an extrapolation within a specific access model, not evidence that all RSA keys can now be forged. Even so, it gives infrastructure operators a reason to audit HSM policies, disable unnecessary raw RSA mechanisms, enforce padding and limit signing queries. It also strengthens the case for cryptographic agility as organizations plan post-quantum migrations. The finding is classical cryptanalysis, not a quantum-computing result, so it is relevant to current architecture reviews rather than only future quantum risk.

No production compromise has been reported

The demonstration used a test key controlled by the researchers, and neither the paper nor independent coverage identifies a breached cryptocurrency network or custody provider. The immediate takeaway is operational rather than alarmist: a private key remaining inside secure hardware does not by itself guarantee that every signing interface is safe. Institutions need controls around what an HSM will sign, how often it will respond and which cryptographic modes remain enabled.

Sources

AI-generated editorial image; not a photograph of the reported event. Prepared with AI assistance and source verification.