A new cryptographic result is being summarized in some coverage as “RSA broken.” That is not what the researchers demonstrated. The September 20 preprint Forging 1024-bit RSA signatures in nearly SNFS time reports a full-scale forgery after temporary access to a raw RSA signing or decryption oracle. The team did not factor the modulus or extract the private key.
The conditions are narrow but operationally important. The attack depends on an interface that performs raw, unpadded RSA operations and on a very large number of queries. Common protocols using appropriate signature padding do not automatically expose that oracle. The result is nevertheless a warning for cryptographic management: keeping a key inside an HSM is not enough if an exposed capability lets an attacker use the device as a computational oracle.
The key can stay protected while its authority escapes
Security teams often treat non-exportability as the decisive control for high-value keys. It is valuable, but it protects only one failure mode. A key can remain inside validated hardware while an attacker abuses allowed operations, weak authorization, an overly broad API, or a protocol that intentionally exposes blind signing.
The researchers implemented an earlier algorithm at a real 1024-bit scale using an HSM-backed oracle. Their result does not make ordinary padded RSA signatures instantly forgeable and does not imply that every RSA HSM deployment is exposed. It does show that assurance must include the operations a key is permitted to perform, the encoding enforced by the device, the query volume, and the application protocol around the key.
This matters beyond RSA. HSMs and key-management services mediate capabilities: sign, decrypt, unwrap, derive, attest, and export under policy. Inventorying the key without inventorying those capabilities leaves a gap between where cryptographic material resides and how its authority can be exercised.
“RSA-2048 in an HSM” is not a sufficient record
A useful cryptographic inventory should record, for each high-value asymmetric key:
- algorithm, modulus or parameter size, purpose, owner, and expected lifetime;
- module, partition, firmware, provider, library, and interface versions;
- allowed operations and padding or encoding rules;
- applications, identities, roles, and protocols authorized to invoke the key;
- rate limits, approval requirements, session controls, and network boundaries;
- normal query volume and available per-operation telemetry;
- shared use across multiple protocols or applications; and
- rotation, revocation, replacement, and evidence-retention procedures.
These fields let defenders ask the question raised by the paper: where can a caller obtain raw RSA operations, directly or indirectly? They also help identify key reuse, where a control assumed safe for one application can be undermined by a second interface to the same key.
Usage telemetry is a cryptographic control
An attack requiring billions of oracle interactions creates an opportunity for detection, but only if the relevant activity is measured and retained. Aggregate HSM health metrics are not enough. Teams need per-key or per-role operation counts, error patterns, source identities, session behavior, and time-based baselines that can distinguish expected batch signing from abusive access.
Rate limits should align with the business process. A key that signs a few releases per day should not accept sustained high-volume requests. A privacy service designed for blind signatures may legitimately operate at scale, but it needs a threat model and limits based on the security level of that construction, not only on the nominal RSA modulus size.
Monitoring also needs an action. Teams should know when to disable an interface, revoke or rotate a key, invalidate derived artifacts, preserve logs, and notify dependent service owners. Because the private key may never be extracted, incident criteria cannot depend solely on evidence of key export.
What organizations should do next
First, do not respond by declaring all RSA immediately compromised. Validate whether raw RSA operations are exposed and whether any blind-signature or legacy workflow relies on them. Review HSM commands, provider APIs, application wrappers, and access roles rather than relying on product names.
Second, identify RSA-1024 and other undersized keys as priority remediation regardless of this paper. For longer keys, use the research as a reason to examine oracle exposure and effective security assumptions. Follow peer review and vendor guidance before translating estimates into definitive risk claims.
Third, remove unnecessary raw operations, enforce approved padding at the narrowest layer possible, isolate high-value keys by purpose, apply least privilege, and set usage limits. Test whether logging can attribute operations to the responsible workload and retain enough history for investigation.
Finally, connect classical remediation with PQC planning. Replacing RSA with post-quantum signatures will not eliminate interface abuse, excessive authority, or missing telemetry. The migration is an opportunity to redesign key policies and evidence, not merely exchange algorithm identifiers.
How Vista Platform helps
Vista Platform is a self-hosted cryptographic system of record. Its operating loop—discovery, canonical inventory, evaluation, action, and proof—helps organizations relate algorithms and keys to assets, software, policies, owners, and remediation evidence.
Vista Platform Core is free of charge and includes discovery, inventory, compliance and PQC assessment, and CBOM generation without asset, sensor, seat, or time caps. Vista can help govern findings and migration work, but it does not inspect every HSM policy automatically, generate PQC keys, or carry out every remediation. Vista is not a vulnerability scanner. Selected-asset Active Scan is targeted, and discovery gaps must not be treated as proof that raw RSA access is absent.
Where uncertainty remains
The paper is a preprint and its estimates and implications require continued review. Its demonstrated RSA-1024 experiment should not be generalized to a practical break of correctly padded RSA-2048 deployments. The defensible conclusion is narrower: cryptographic assurance must cover permitted operations and observed use, not only key location and nominal strength.
Source
- Forging 1024-bit RSA signatures in nearly SNFS time, Laura Shea, Miro Haller, Adam Suhl, Nadia Heninger, and Emmanuel Thomé, IACR Cryptology ePrint Archive, September 20, 2026.