RSA-2048 vs. RSA-4096: Schlüssellänge, Tempo, Frist 2030

RSA-2048 vs. RSA-4096 ist die häufigste Frage zur Schlüssellänge in der PKI. RSA-2048 ist das Minimum für öffentlich vertrauenswürdige Zertifikate und liegt auf dem 112-Bit-Sicherheitsniveau von NIST; RSA-4096 liegt deutlich über 128 Bit. Die Kosten des größeren Schlüssels zeigen sich in der Signierzeit, in der Dauer der Schlüsselerzeugung und in jeder Signatur, die über die Leitung geht. Die richtige Antwort hängt also davon ab, wie oft ein Schlüssel signiert und wie lange er vertrauenswürdig bleiben muss.

Auf einen Blick

Gemessen mit openssl speed rsa2048 rsa3072 rsa4096 auf einem Kern eines Apple M4 Max.

Sicherheitsreserve

Die Sicherheit von RSA beruht darauf, wie schwer es ist, den Modul mit dem allgemeinen Zahlkörpersieb zu faktorisieren. Dessen Aufwand wächst subexponentiell mit der Schlüssellänge, weshalb RSA-Schlüssel viel schneller wachsen müssen als Schlüssel auf elliptischen Kurven. NIST SP 800-57 Teil 1 setzt 2048-Bit-RSA mit 112-Bit-Sicherheit gleich, 3072 Bit mit 128 und 7680 mit 192; für 4096 Bit gibt es keine Zeile, der Wert liegt zwischen 128 und 192. Die größte öffentlich faktorisierte RSA-Challenge-Zahl hat 829 Bit (RSA-250, 2020) – weit entfernt von 2048.

Die wichtigere Frist setzen Quantencomputer. Der Shor-Algorithmus faktorisiert alle drei Größen auf einem großen fehlertoleranten Quantencomputer in polynomieller Zeit. Ein doppelt so langer Schlüssel verdoppelt ungefähr die Zahl der nötigen Qubits und verlängert die Laufzeit moderat, ändert aber nichts am Ergebnis. Craig Gidney schätzte 2025, dass sich RSA-2048 mit weniger als einer Million verrauschter Qubits in unter einer Woche faktorisieren lässt. NIST IR 8547 (ein erster öffentlicher Entwurf) schlägt deshalb für jede RSA-Schlüssellänge dasselbe Enddatum vor, 2035, wobei RSA-2048 wegen seines klassischen 112-Bit-Niveaus zusätzlich schon nach 2030 als veraltet gilt. RSA-4096 vergrößert deine klassische Reserve; deine Post-Quanten-Frist verlängert es nicht.

Geschwindigkeit

Operationen mit dem privaten Schlüssel werden ungefähr mit der dritten Potenz der Modulgröße teurer, Operationen mit dem öffentlichen Schlüssel mit dem Quadrat:

openssl speed -seconds 2 rsa2048 rsa3072 rsa4096

                   sign    verify    encrypt   decrypt   sign/s verify/s  encr./s  decr./s
rsa  2048 bits 0.000334s 0.000009s 0.000009s 0.000339s   2994.9 114178.1 108513.6   2950.3
rsa  3072 bits 0.000957s 0.000019s 0.000019s 0.000965s   1044.7  53948.7  52312.0   1036.7
rsa  4096 bits 0.002117s 0.000032s 0.000032s 0.002121s    472.4  31522.3  30870.7    471.6

Für einen TLS-Server, der einmal pro vollständigem Handshake signiert, erhöht der Wechsel von 2048 auf 4096 diese Kosten etwa um den Faktor sechs. Für eine Root-CA, die pro Jahrzehnt ein paar Zwischenzertifikate signiert, sind die Kosten irrelevant. Auch die Schlüsselerzeugung wird deutlich langsamer, weil sie zwei große Primzahlen suchen muss: auf diesem Rechner im Schnitt etwa 26 ms für 2048 Bit gegenüber einer Viertelsekunde für 4096, mit einem langen Ausläufer nach oben. Das spielt auf kleinen Geräten eine Rolle und in Tests, die wiederholt Schlüssel erzeugen.

Die Prüfung bleibt bei jeder Größe günstig, weil der öffentliche Exponent klein ist (65537); deshalb behält RSA seinen Platz in Zertifikatsketten, die milliardenfach geprüft werden.

Grenzen durch Hardware und Protokolle

Grenzen für die Schlüssellänge setzt eher das Umfeld als RSA selbst:

• Smartcards und Tokens: Viele PIV-Karten und ältere Sicherheitstokens unterstützen nur RSA-2048; neuere Geräte unterstützen zusätzlich 3072 und 4096. Prüfe das, bevor du Hardware bestellst.
• HSMs und Cloud-KMS: Alle drei Größen sind Standard (AWS KMS bietet RSA_2048, RSA_3072 und RSA_4096), aber Preise pro Operation und Durchsatzlimits machen 4096 bei großem Volumen spürbar teurer.
• DNS: Ein 4096-Bit-DKIM-Schlüssel umfasst 736 Zeichen in base64 und muss auf mehrere TXT-Strings aufgeteilt werden; manche DNS-Anbieter und alte Resolver kommen mit langen Einträgen schlecht zurecht. DNSSEC-Zonen mit RSA-4096 erzeugen große Antworten, die unter Umständen TCP erfordern.
• Zertifikatsketten: Jedes RSA-4096-Zertifikat bringt etwa 512 Byte Signatur und 550 Byte Schlüssel mit, gegenüber wenigen Hundert Byte bei ECDSA – das ist für Clients mit knappen Ressourcen relevant.

Wann welche Schlüssellänge passt

• Neue TLS-Serverzertifikate: zuerst ECDSA P-256; wenn es RSA sein muss, akzeptieren alle Clients und CAs weiterhin RSA-2048, aber RSA-3072 bietet eine Reserve über 2030 hinaus.
• Root-CAs und langlebige Zwischen-CAs: RSA-4096 (oder ECDSA P-384); die Signierkosten sind vernachlässigbar, die Laufzeiten lang. ISRG Root X1 von Let's Encrypt verwendet RSA-4096, die zugehörigen RSA-Zwischenzertifikate dagegen RSA-2048.
• JWT-Signaturen (RS256): RSA-2048 ist verbreitet und zulässig (RFC 7518 verlangt mindestens 2048), RSA-3072 für neue Schlüssel; erwäge stattdessen ES256.
• SSH-Schlüssel: vorzugsweise Ed25519; wenn RSA, dann mindestens 3072.
• Schlüssel für Codesignatur und Dokumentsignaturen: RSA-3072 oder 4096, passend zum Angebot der CA und zur erwarteten Lebensdauer der Signatur, dazu Zeitstempel.
• Hardware mit knappen Ressourcen: was sie unterstützt, meist RSA-2048, mit einem dokumentierten Plan für den Ersatz.

Hinweise zur Migration

Eine andere RSA-Schlüssellänge bedeutet ein neues Schlüsselpaar und bei Zertifikaten ein neues Zertifikat.

1. Inventarisiere die Schlüssel nach Länge: Zertifikate (openssl x509 -noout -text), JWKS (Länge von n), SSH-Schlüssel (ssh-keygen -l), DKIM-Einträge und Schlüssel-Handles in HSMs. RSA-2048-Schlüssel mit Laufzeiten über 2030 hinaus werden zuerst rotiert.
2. Erzeuge neue Schlüssel dort, wo sie liegen sollen: openssl genpkey -algorithm RSA -pkeyopt rsa_keygen_bits:3072 oder das Gegenstück im HSM; vermeide es, Schlüssel zu exportieren, um ihre Länge zu ändern.
3. Lass alte und neue Schlüssel überlappen: Veröffentliche beide im JWKS mit unterschiedlichen Werten für kid, lege den neuen DKIM-Selektor vor dem Umschalten an und biete während der Umstellung beide SSH-Host-Schlüssel an.
4. Teste die abhängigen Systeme mit dem größeren Schlüssel: Puffer fester Größe, Längengrenzen für DNS-Einträge und eingebettete TLS-Stacks sind die üblichen Fehlerquellen.
5. Nutze die Rotation, um den Algorithmus zu überdenken: Wenn alle abhängigen Systeme ECDSA oder EdDSA unterstützen, ist der vollständige Abschied von RSA meist die bessere Investition, und für Post-Quanten-Signaturen ist vor 2035 eine weitere Rotation nötig.

Quellen

• NIST SP 800-57 Teil 1 Rev. 5, Tabelle 2
• NIST IR 8547, erster öffentlicher Entwurf
• FIPS 186-5 §5, RSA
• RFC 8017, PKCS #1 v2.2
• RFC 7518 §3.3, Mindestlänge von RSA-Schlüsseln für JWS
• Gidney (2025), RSA-2048 mit weniger als einer Million verrauschter Qubits faktorisieren
• CA/Browser Forum Baseline Requirements §6.1.5