Warum wir RSA durch Ed25519 ersetzt haben (und Sie das auch tun sollten)

Sie kennen die Browser-Warnung. „Ihre Verbindung ist nicht sicher.” Selbstsignierte Zertifikate gehören zum Alltag, wenn Sie selbst hosten. Aber der Schlüssel in diesem Zertifikat ist wichtiger, als die meisten denken — und die meisten Anleitungen empfehlen immer noch das falsche Standardverfahren.

Die RSA-Gewohnheit

Jede Self-Hosting-Anleitung im Internet sagt dasselbe:

openssl req -x509 -newkey rsa:4096 -keyout key.pem -out cert.pem -days 365

RSA 4096. Weil größere Zahlen mehr Sicherheit bedeuten, oder? Nicht mehr. RSA-4096-Schlüssel sind 3,2 KB groß. Auf einem 5-Euro-VPS dauert die Generierung Sekunden. Und sie bieten ungefähr die gleiche Sicherheitsstufe wie ein 256-Bit-Schlüssel auf elliptischer Kurve.

RSA ist der Standard aus historischer Trägheit, nicht aus technischen Gründen. Es funktioniert überall, und bei CA-signierten Zertifikaten ist diese Kompatibilität wichtig. Aber bei selbstsignierten Zertifikaten in einem Stack, den Sie kontrollieren? Sie zahlen einen Performance-Aufschlag für Kompatibilität, die Sie nicht brauchen.

Ed25519 im Überblick

Ed25519 ist ein EdDSA-Signaturverfahren auf Basis der Curve25519. Es erzeugt kleine, feste 256-Bit-Schlüssel. Es wurde ausschließlich für digitale Signaturen entwickelt — keine Verschlüsselung, kein Schlüsselaustausch, nur Signaturen. Diese Konzentration macht es einfacher, schneller und fehlerresistenter.

In Go ist es ein gleichberechtigter Bürger. Das Paket crypto/ed25519 gehört seit Go 1.13 zur Standardbibliothek. Schlüsselgenerierung in zwei Zeilen. Serialisierung über x509.MarshalPKCS8PrivateKey. Keine externen Abhängigkeiten, kein CGo, keine speziellen Build-Tags.

Im Vergleich

Quellen: Schlüsseltypen erklärt, Go-Benchmarks: RSA vs ECDSA vs Ed25519, SSH-Schlüsselalgorithmus-Vergleich

Die ECDSA-KeyUsage-Falle

Hier ist ein Fehler, der fast jeden trifft, der von RSA auf ECDSA umsteigt. In Go’s crypto/x509 benötigen RSA-Schlüssel sowohl KeyUsageDigitalSignature als auch KeyUsageKeyEncipherment im Zertifikats-Template. Wenn Sie dieses Muster auf ECDSA übertragen — also KeyUsageKeyEncipherment zu einem EC-Schlüssel hinzufügen —, lehnen einige TLS-Clients das Zertifikat ab. EC-Schlüssel führen keine Schlüsselverschlüsselung durch. Die Erweiterung ist bedeutungslos und aktiv schädlich.

So sieht die Lösung in Bedruds Zertifikatserstellung aus (server/internal/utils/tls.go):

func keyUsageForAlgo(algo KeyAlgorithm) x509.KeyUsage {
    switch algo {
    case KeyRSA2048, KeyRSA4096:
        return x509.KeyUsageDigitalSignature | x509.KeyUsageKeyEncipherment
    default:
        return x509.KeyUsageDigitalSignature
    }
}

Ed25519 fällt in den Default-Zweig. Reine digitale Signatur. Keine KeyEncipherment-Option zum Fehlkonfigurieren. Eine Fehlerquelle weniger.

Was das auf einem 5-Euro-VPS bedeutet

Auf einem Hetzner CX22 (2 vCPU, 4 GB RAM) ist der Unterschied messbar:

• Schlüsselgenerierung: RSA 4096 dauert ~1–2 Sekunden. Ed25519 dauert unter 1 ms. Das zählt, wenn Ihr Server beim ersten Start ein selbstsigniertes Zertifikat erstellt.
• TLS-Handshake: Ed25519 signiert und verifiziert schneller, was die Handshake-Latenz reduziert. Auf einem ausgelasteten Server mit dutzenden WebRTC-Verbindungen summieren sich diese Millisekunden.
• Speicherbedarf: Ein Ed25519-Privatschlüssel ist PEM-kodiert 48 Bytes. Ein RSA-4096-Schlüssel 3,2 KB. Für ein Zertifikat kein großer Unterschied, aber er spiegelt den rechnerischen Gewichtsunterschied wider.

Was Bedrud macht

Bedrud generiert standardmäßig Ed25519-selbstsignierte Zertifikate. Die Funktion GenerateSelfSignedCert verwendet KeyEd25519, sofern nichts anderes angegeben wird.

Wenn Sie einen anderen Algorithmus benötigen — für Legacy-Client-Kompatibilität oder interne Richtlinien — verwenden Sie das Flag --key-algorithm:

bedrud run --key-algorithm rsa4096
bedrud run --key-algorithm ecdsa256

Unterstützte Werte: ed25519 (Standard), ecdsa256, rsa2048, rsa4096.

Wann Sie bei RSA bleiben sollten

RSA ist nicht tot. Sie brauchen es weiterhin für:

• Ältere Java-Clients, die Ed25519-TLS-Handshakes nicht unterstützen
• Android-Geräte vor 7.0 (Nougat), denen Ed25519 im TLS-Stack fehlt
• Eingebettete Geräte mit älteren OpenSSL- oder mbedTLS-Versionen
• Unternehmensumgebungen mit TLS-Inspektions-Middleboxes, die nur RSA verstehen

Wenn Ihr Stack modern ist — Go-Backend, Chromium-basierte Browser, aktuelle mobile Apps — funktioniert Ed25519 überall, wo es darauf ankommt.

Fazit

Self-Hosted-Infrastruktur sollte nicht mit 4096-Bit-RSA-Schlüsseln belastet werden, nur weil eine Anleitung aus dem Jahr 2013 das empfiehlt. Ed25519 ist schneller, kleiner und fehlerresistenter. Es ist das, wofür Gos Standardbibliothek optimiert ist. Und bei selbstsignierten Zertifikaten in einem kontrollierten Stack überzeugt das RSA-Kompatibilitätsargument nicht.

Selbst hosten mit besseren Standards. Bedrud installieren und selbst ausprobieren.