Introduction
Google DeepMind, in collaboration with cryptographers from UC San Diego and Inria, has demonstrated that AI can significantly reduce the cost of attacking 1024-bit RSA encryption. In controlled tests, AI agents reduced the CPU time for a forgery attack on a 1024-bit key from 1,380 to 391 CPU core-years. Their algorithm for factoring additional 1024-bit keys is about 30 times cheaper than previous methods, though this is theoretical and not yet implemented. Pushmeet Kohli from Google DeepMind assures that modern protocols using 2048-bit or larger keys remain secure.
Why should your team care? Article 32 GDPR mandates Technical and Organisational Measures appropriate to the risk, considering the state of the art. When the cost of attacking an algorithm drops, "state of the art" shifts. This checklist helps ensure no legacy RSA-1024 usage is lurking in your systems, undocumented and unmanaged.
Prerequisites
Before starting, ensure you have:
- Access to your record of processing activities (Article 30 GDPR).
- A designated owner in security or infrastructure to query certificate stores, HSM configurations, and application code.
- Your latest risk register and any completed ISO/IEC 29134 assessments for High-Risk Processing.
- A list of third-party processors handling Restricted Data on your behalf.
Checklist
1. Build a cryptographic inventory.
Document every system using Asymmetric Encryption or Digital Signature functions: TLS certificates, code signing, document signing, VPNs, email signing, HSM-backed services, and embedded devices. Reference: Article 30 and Article 32(1) GDPR.
Done when: every entry lists the algorithm, key length, owner, and the personal data it protects.
Good looks like: the inventory is generated by automated Data Discovery of certificate stores and refreshed regularly, not just compiled once in a spreadsheet.
2. Flag every RSA key shorter than 2048 bits.
Search for 1024-bit keys in certificates, keystores, HSM slots, and configuration files. Treat unknown key lengths as findings until verified.
Done when: every RSA-1024 instance is tagged with a system and an owner.
Good looks like: zero unexplained 1024-bit keys, with a dated exception record for any that remain.
3. Check signing interfaces for PKCS#1 v1.5 exposure.
Research shows that padding offers no protection once an attacker controls roughly half the signed block. This affects the PKCS#1 v1.5 format used through the PKCS#11 interface of devices like HSMs. Identify any service that signs data an outside party can influence.
Done when: each signing service is documented with its padding scheme and key length.
Good looks like: no RSA-1024 signing service accepts attacker-influenced input, and legacy padding is scheduled for replacement.
4. Understand the limits of the attack before you escalate.
The forgery attack doesn't recover the private key. It required about 4 billion signing queries made in advance and doesn't work against devices that hash messages internally. Factoring a key would still take an estimated 500,000 to 1 million core-years.
Done when: your risk assessment records these preconditions for each affected system.
Good looks like: your severity ratings reflect real exploitability, so urgent work targets systems that actually meet the attack conditions.
5. Rate the risk to individuals.
For each RSA-1024 finding, assess the impact of a forged signature or compromised key on data subjects. Reference: Article 32(2) and, where risk is high, Article 35 GDPR.
Done when: findings are scored in the risk register with likelihood and impact.
Good looks like: ratings are reviewed by the Chief Privacy Officer (CPO) or DPO, not left solely to engineering.
6. Set a migration plan with dates.
Move affected systems to 2048-bit or larger RSA, or to alternative algorithms approved by your security team. Include certificate reissuance, HSM reconfiguration, and dependent integrations.
Done when: each legacy system has an owner, a target date, and a rollback plan.
Good looks like: migration dates are tracked to completion, and retired keys undergo Secure Deletion or Cryptographic Erasure.
7. Cover your processors.
Ask each processor to confirm in writing whether it uses RSA-1024 for systems handling your data. Reference: Article 28(3)(c) GDPR, which requires processors to implement Article 32 measures.
Done when: every processor has answered and gaps are logged.
Good looks like: contracts include a right to audit cryptographic controls and a duty to notify you of deprecated algorithm use.
8. Define a review trigger for cryptographic assumptions.
Kohli emphasizes that cryptographic hardness cannot be assumed fixed. Set a standing review, annual at minimum, plus event-driven reviews when credible new research is published.
Done when: the review is on the governance calendar with a named owner.
Good looks like: each review produces a dated record showing what was checked and what changed.
9. Document your Article 32 reasoning.
Record why your chosen algorithms and key lengths are appropriate, including the state-of-the-art consideration.
Done when: a current, approved entry exists in your Technical and Organisational Measures documentation.
Good looks like: an auditor or Supervisory Authority could read it and understand your decision without needing further explanation.
10. Prepare the incident path.
If a legacy key is compromised, act quickly. Confirm your Breach Register process and 72-Hour Notification workflow cover cryptographic failures.
Done when: an incident runbook names key revocation, reissuance, and Notification to Supervisory Authority steps.
Good looks like: the runbook was exercised in a tabletop within the last review cycle.
Common Mistakes
- Treating the research as a 2048-bit emergency. It isn't. Overreacting wastes credibility and budget.
- Ignoring the issue. Legacy keys persist in embedded devices, old HSM partitions, and forgotten integrations. That's where the exposure lies.
- Trusting engineering's "we don't use that anymore." Verify by scanning.
- Skipping processors. Your exposure includes their legacy systems.
- Leaving no paper trail. Under Article 5(2) GDPR, accountability means you must demonstrate your reasoning.
Next Steps
Start with items 1 and 2 this week; they will tell you whether the rest is urgent or routine. Brief your CPO and security lead on the findings, schedule the migration work, and put the cryptographic review in your governance calendar. The lesson from this research isn't that RSA broke. It's that the margin around legacy cryptography is thinner than your documentation may assume, and AI-assisted analysis will keep testing it.
