ring propose une courte liste d’algorithmes, avec de l’assembleur dérivé de BoringSSL et une API résistante aux mauvais usages : impossible de choisir un nonce, de signer un condensat précalculé ou de charger une clé dans un format inhabituel. ring est ainsi rapide et difficile à mal utiliser, et c’est pourquoi l’essentiel du travail consiste à convertir les clés et les signatures venues d’autres piles.
L’encodage fait partie de l’algorithme : ECDSA_P256_SHA256_FIXED_SIGNING produit du r‖s brut de 64 octets et ECDSA_P256_SHA256_ASN1_SIGNING du DER, avec les constantes de vérification _FIXED et _ASN1 correspondantes. Une signature contrôlée sous l’autre constante échoue simplement avec Unspecified : une signature JWS vérifiée avec la constante ASN1, ou une signature OpenSSL avec FIXED, ressemble donc exactement à une falsification. L’exemple montre les deux issues. Les signatures utilisent un nonce aléatoire, s n’est pas normalisé et la vérification accepte les deux moitiés.
Les clés privées ne se lisent qu’en PKCS#8 DER, et les clés Ed25519 doivent être en PKCS#8 v2 avec la clé publique incluse : la forme v1 de 48 octets qu’écrivent OpenSSL et la plupart des outils a été rejetée par Ed25519KeyPair::from_pkcs8 avec VersionNotSupported, alors que from_pkcs8_maybe_unchecked et from_seed_unchecked l’ont acceptée. Les clés privées PEM, SEC1 et JWK doivent d’abord être converties, par exemple avec le convertisseur JWK. Les clés publiques sont des points SEC1 nus : public_key() renvoie la forme non compressée de 65 octets, et les points compressés ne sont pas acceptés.
La liste des courbes s’arrête à P-256 et P-384, plus Ed25519 : pas de P-521, pas de secp256k1 et aucun algorithme post-quantique. Les projets qui en ont besoin, ou qui exigent une validation FIPS, passent à aws-lc-rs, qui offre une API compatible avec ring.
Pour savoir dans quel encodage est une signature produite par ring, collez-la dans le convertisseur DER ⇄ brut.