ring bietet eine kurze Liste von Algorithmen mit aus BoringSSL abgeleitetem Assembler-Code und eine missbrauchsresistente API: Es gibt keine Möglichkeit, eine Nonce zu wählen, einen vorab berechneten Digest zu signieren oder einen Schlüssel in einem ungewöhnlichen Format zu laden. Das macht die Bibliothek schnell und schwer falsch zu benutzen – und deshalb steckt die eigentliche Arbeit im Konvertieren von Schlüsseln und Signaturen aus anderen Stacks.
Die Kodierung ist Teil des Algorithmus: ECDSA_P256_SHA256_FIXED_SIGNING erzeugt rohes r‖s mit 64 Byte und ECDSA_P256_SHA256_ASN1_SIGNING DER, dazu gibt es passende Prüfkonstanten _FIXED und _ASN1. Eine Signatur, die unter der jeweils anderen Konstante geprüft wird, scheitert schlicht mit Unspecified; eine JWS-Signatur, die mit der ASN1-Konstante geprüft wird – oder eine OpenSSL-Signatur mit FIXED –, sieht also genau wie eine Fälschung aus. Das Beispiel zeigt beide Ergebnisse. Signaturen verwenden eine zufällige Nonce, s wird nicht normalisiert, und die Prüfung akzeptiert beide Hälften.
Private Schlüssel werden nur als PKCS#8-DER gelesen, und Ed25519-Schlüssel müssen PKCS#8 v2 mit eingeschlossenem öffentlichem Schlüssel sein: Die 48 Byte lange v1-Form, die OpenSSL und die meisten Tools schreiben, wurde von Ed25519KeyPair::from_pkcs8 mit VersionNotSupported abgelehnt, während from_pkcs8_maybe_unchecked und from_seed_unchecked sie akzeptierten. Private Schlüssel in PEM, SEC1 und JWK müssen zuerst konvertiert werden, zum Beispiel mit dem JWK-Konverter. Öffentliche Schlüssel sind bloße SEC1-Punkte: public_key() liefert die 65 Byte lange unkomprimierte Form, und komprimierte Punkte werden nicht akzeptiert.
Die Kurvenliste endet bei P-256 und P-384 plus Ed25519; es gibt kein P-521, kein secp256k1 und keinen Post-Quanten-Algorithmus. Projekte, die diese oder eine FIPS-Validierung brauchen, wechseln zu aws-lc-rs, das eine zu ring kompatible API bietet.
Um zu prüfen, in welcher Kodierung eine Signatur aus ring vorliegt, füge sie in den Konverter DER ⇄ Raw ein.