Einen Signaturalgorithmus für Ihre Lizenzschlüssel wählen: Ed25519, ECDSA und RSA im Vergleich

Ein Keyright-Lizenzschlüssel ist weder ein Passwort noch ein zufälliges Token. Er ist ein kurzes Dokument — der Kunde, die Stufe, die Anzahl der Plätze, das Ablaufdatum —, eingehüllt in eine digitale Signatur, die Ihre Anwendung offline gegen einen mitgelieferten öffentlichen Schlüssel verifiziert. Die Signatur ist die ganze Sicherheitsgeschichte: Sie ist der Grund, warum ein Kunde in einem Schlüssel nicht „Standard“ in „Pro“ ändern und ihn trotzdem validieren lassen kann, und warum niemand einen Schlüssel prägen kann, den Sie nicht ausgestellt haben.

Das wirft eine Frage auf, die nach Implementierungsdetail klingt und keines ist: Welcher Signaturalgorithmus? Die ehrliche Antwort lautet, dass sich diese Wahl auf drei Dinge auswirkt, die Ihre Kunden und Ihr Support-Team direkt spüren — wie lang der Schlüssel ist, wie schnell jeder Start ihn verifiziert und wie sehr Ihnen ein einziger Fehler in Ihrem Ausstellungscode schaden kann. Dieser Beitrag wägt die drei realistischen Optionen — RSA, ECDSA und Ed25519 — auf genau diesen Achsen ab und erklärt, warum Keyright standardmäßig mit Ed25519 signiert.

Was tatsächlich im Schlüssel landet

Beginnen wir mit der Form des Schlüssels, denn dort landet das Größenargument. Ein Lizenzschlüssel ist die kanonische Payload plus eine Signatur darüber, kodiert in Zeichen, die ein Mensch eintippen kann:

key = base32( canonical_payload_bytes || signature_bytes )

Die Payload ist klein und weitgehend fix — ein paar Dutzend Bytes an Claims. Die Signatur ist die Variable, und für die meisten Algorithmen ist sie das größte einzelne Element im Schlüssel. Die rohe Bytelänge einer Signatur ist also in erster Näherung die Länge Ihres Schlüssels. Durch diese Linse sollten Sie den nächsten Abschnitt lesen: Jedes Byte Signatur wird zu etwa 1,6 Base32-Zeichen, die Ihr Kunde ohne Tippfehler eingeben oder einfügen muss.

RSA: es funktioniert, und es hat die falsche Form für einen Schlüssel

RSA ist der Algorithmus, nach dem alle zuerst greifen, weil es derjenige ist, den sie gelernt haben. Für Lizenzsignaturen ist er vertretbar und zugleich die schwächste Passung der drei.

Das Größenproblem ist unmittelbar. Eine RSA-2048-Signatur ist exakt 256 Bytes groß — die Modulusgröße —, egal wie klein Ihre Payload ist. Kodieren Sie das in Base32, und Sie haben dem Schlüssel rund 410 Zeichen hinzugefügt, bevor die Claims kommen. Einen so langen Schlüssel tippt kein Kunde; er fügt ihn ein, und wenn er jemals vorgelesen, auf eine Karte gedruckt oder auf einem Gerät ohne Zwischenablage eingegeben werden muss, haben Sie bereits verloren. RSA auf das 128-Bit-Sicherheitsniveau zu heben, das die Elliptische-Kurven-Optionen erreichen, bedeutet RSA-3072, dessen Signatur 384 Bytes groß ist, was den Schlüssel nur noch schlimmer macht.

RSA hat eine echte Stärke, die ehrlich benannt werden sollte: Die Verifikation ist schnell, weil ein winziger öffentlicher Exponent (65537) verwendet wird, sodass die clientseitige Prüfung — die Operation, die bei jedem Start stattfindet — günstig ist. Aber ECDSA und Ed25519 verifizieren ebenfalls deutlich unter einer Millisekunde, sodass dieser Vorteil Ihnen nichts bringt, was ein Nutzer wahrnehmen könnte, und er kommt mit einer viermal so großen Signatur daher.

In .NET sieht die Verifikationsseite so aus:

using var rsa = RSA.Create();
rsa.ImportSubjectPublicKeyInfo(publicKeyDer, out _);

bool ok = rsa.VerifyData(
    payload, signature,
    HashAlgorithmName.SHA256,
    RSASignaturePadding.Pkcs1);

An diesem Code ist nichts falsch. Das Problem sind die 256 Bytes in signature, und keine noch so clevere Kodierung macht sie kleiner.

ECDSA: die richtige Größe, mit einer Nonce, die man falsch machen kann

Elliptische-Kurven-DSA über die NIST-Kurve P-256 liefert 128-Bit-Sicherheit — vergleichbar mit RSA-3072 — bei einer Rohsignatur von nur 64 Bytes (zwei 32-Byte-Ganzzahlen, r und s). Das ist ein Viertel der Größe von RSA-2048 für einen stärkeren Schlüssel, und es ist direkt in System.Security.Cryptography in jeder unterstützten .NET-Version eingebaut, was es zur naheliegenden Wahl macht, wenn Ihre Einschränkung „nur eingebaute Algorithmen“ lautet:

using var ecdsa = ECDsa.Create();
ecdsa.ImportSubjectPublicKeyInfo(publicKeyDer, out _);

// Keyright stores the raw r‖s form to keep the key short; .NET verifies it directly.
bool ok = ecdsa.VerifyData(
    payload, signature,
    HashAlgorithmName.SHA256,
    DSASignatureFormat.IeeeP1363FixedFieldConcatenation);

Beachten Sie das letzte Argument. ECDSA-Signaturen haben zwei Kodierungen: die kompakte 64-Byte-IEEE P1363-Verkettung von r und s und die ASN.1-DER-Form, die sie in eine SEQUENCE aus zwei INTEGERn einhüllt und 70–72 Bytes mit variabler Länge umfasst (Regeln für führende Nullen lassen DER-Signaturen von Signatur zu Signatur in der Größe schwanken). Für einen Lizenzschlüssel wollen Sie die feste 64-Byte-Form; eine DER-Signatur variabler Länge lässt Ihre Schlüssellänge wackeln und verkompliziert das Parsen fester Breiten. Das falsch zu machen ist ein häufiger Interop-Fehler — ein Signierer, der DER ausgibt, und ein Verifizierer, der P1363 erwartet, lehnt jede gültige Signatur ab.

Das tiefere Problem bei ECDSA ist nicht die Größe, sondern die Nonce. Jede ECDSA-Signatur verbraucht einen geheimen Wert k pro Signatur. Wird k jemals über zwei verschiedene Nachrichten hinweg wiederverwendet oder ist er auch nur leicht vorhersagbar, fällt der private Schlüssel mit ein paar Zeilen Algebra aus den beiden Signaturen heraus. Das ist keine Hypothese — es ist exakt der Mechanismus hinter mehreren berühmten Schlüsselextraktionen. Das ECDsa von .NET erzeugt k korrekt und hält es intern, sodass das Signieren innerhalb des Frameworks sicher ist. Aber sobald Ihr Ausstellungspfad eigenen Code, eine andere Sprache oder einen geliehenen Zufallsgenerator einbezieht — und ein Lizenz-Backend wächst oft genau in diese Richtung —, ist ECDSA nur eine schwache Zufallsquelle davon entfernt, den Schlüssel preiszugeben, der Ihr gesamtes Produkt schützt. Der Algorithmus reicht Ihnen eine geladene Waffe und vertraut darauf, dass Sie sie nicht auf sich selbst richten.

Ed25519: klein, schnell und nichts, was man falsch machen kann

Ed25519 — EdDSA über die von Curve25519 abgeleitete Edwards-Kurve — wurde mit den Lehren aus RSA und ECDSA entworfen, und für Lizenzschlüssel gewinnt es auf jeder Achse, die zählt.

Die Größen sind die besten der drei: eine 64-Byte-Signatur und ein 32-Byte-Public-Key bei 128-Bit-Sicherheit. Auch der öffentliche Schlüssel zählt, denn er ist der Wert, den Ihre Anwendung einbettet und (wenn Sie ihn härten) verankert; ein 32-Byte-Anker ist weit leichter per Fingerprint zu prüfen und zu schützen als RSAs rund 294 Bytes große SubjectPublicKeyInfo. Sein DER-Public-Key beginnt in Base64 mit dem festen Präfix MCowBQYDK2Vw, ein verräterisches Zeichen dafür, dass Sie einen Ed25519-Schlüssel vor sich haben.

Entscheidend ist, dass Ed25519 deterministisch ist. Die Nonce pro Signatur wird abgeleitet, indem der private Schlüssel zusammen mit der Nachricht gehasht wird, sodass sie pro Nachricht eindeutig ist, ohne beim Signieren überhaupt Zufall zu benötigen. Es gibt kein k, das wiederverwendet werden könnte, keinen Zufallsgenerator, der falsch konfiguriert werden könnte, keine Nonce-Verzerrung, die den Schlüssel preisgibt — die schärfste Kante von ECDSA ist schlicht nicht vorhanden. Dieselbe Payload zweimal zu signieren erzeugt byteidentische Ausgaben, was auch das Ausstellen idempotent und Test-Fixtures stabil macht. Die Verifikation ist per Konstruktion constant-time und umgeht damit eine Klasse von Timing-Problemen, über die Sie sonst nachdenken müssten.

Der einzige praktische Haken unter .NET: Ed25519 wird nicht über die eingebaute Oberfläche von System.Security.Cryptography bereitgestellt, wie es RSA und ECDsa werden, sodass die Verifikation über eine mitgelieferte Implementierung statt über die BCL läuft. Aus Sicht eines Integrators ist das unsichtbar — das Keyright-SDK verifiziert für Sie:

var verifier = new LicenseVerifier(new LicenseVerifierOptions
{
    // 32-byte Ed25519 public key, base64 SubjectPublicKeyInfo — safe to ship, worth pinning.
    PublicKeyBase64 = "MCowBQYDK2VwAyEA9mF3rQ2pxK8vN1cWbYh6Zt0uQ4sJ7eD3rL5nX8kH2A=",
});

LicenseResult result = verifier.Verify(licenseKey);
if (result.IsValid && result.Claims.Tier == "Pro")
{
    // honor the entitlements
}

Die 64-Byte-Signatur hält den Schlüssel kurz, das deterministische Design hält Ihre Ausstellungsseite aus dem Nonce-Minenfeld heraus, und der Verify-Aufruf ist eine Operation im Submillisekundenbereich, die Sie bei jedem Start ohne Server im Pfad ausführen können.

Wie die drei auf den entscheidenden Achsen landen

Lesen Sie die Tabelle so, wie ein Lizenzsystem sie erlebt. Die Zeile, die entscheidet, ob Ihr Schlüssel überhaupt brauchbar ist, ist Schlüssellänge, und sie schließt RSA für alles aus, was ein Mensch anfasst. Die Zeile, die entscheidet, ob ein einziger schlechter Tag in Ihrem Ausstellungscode Sie das ganze Produkt kostet, ist Nonce-Gefahr, und sie trennt Ed25519 von ECDSA. Auf den beiden Zeilen, auf denen RSA konkurrenzfähig ist — Determinismus und Verifikationsgeschwindigkeit —, ziehen die Elliptische-Kurven-Optionen ohnehin gleich oder vorbei. Es gibt keine Achse, auf der RSA-2048 die richtige Antwort für Lizenzschlüssel ist, und die einzige Achse, auf der ECDSA Ed25519 schlägt, lautet „auf jeder alten Zielplattform bereits eingebaut“.

Was das in der Praxis bedeutet

Wenn Sie neu anfangen, signieren Sie mit Ed25519. Es erzeugt die kürzesten Schlüssel, erreicht ein 128-Bit-Sicherheitsniveau, verifiziert schnell genug, um bei jedem Start zu laufen, und — der Teil, der am meisten zählt, wenn Ihr Signaturpfad über eine einzige saubere Funktion hinauswächst — es hat keine Nonce pro Signatur, die den privaten Schlüssel preisgeben könnte. Deshalb ist es der Standard von Keyright: Das SDK bettet einen 32-Byte-Public-Key ein, den Sie verankern können, verifiziert die 64-Byte-Signatur offline und verlangt von Ihrer Ausstellungsseite nie Zufall, den sie falsch liefern könnte.

Greifen Sie nur dann zu ECDSA P-256, wenn eine harte Einschränkung Sie auf eingebaute Algorithmen auf einer Zielplattform zwingt, auf der Ed25519 nicht verfügbar ist — und wenn Sie es tun, legen Sie die feste 64-Byte-IEEE P1363-Kodierung fest, lassen Sie das Framework die Nonce erzeugen und lassen Sie niemals einen eigenen Signierer in die Nähe von k. Greifen Sie nur dann zu RSA, wenn Sie mit einem System interoperieren, das es bereits vorschreibt, und akzeptieren Sie, dass Ihre Schlüssel nur per Einfügen funktionieren werden.

Der Signaturalgorithmus ist das Fundament, auf dem das gesamte Lizenzschema steht. Wählen Sie den, der klein genug zum Eintippen, stark genug für die Zukunft und so geformt ist, dass der einfachste Weg durch Ihren eigenen Code zugleich der sichere ist.