Network Security Services est la bibliothèque sur laquelle reposent Firefox, Thunderbird et plusieurs composants système de Linux, y compris l’implémentation WebCrypto de Firefox. Elle fonctionne via PKCS#11 : les clés résident dans un jeton (le softoken intégré, une carte à puce ou un HSM), et tout ce qui se trouve au-dessus appelle les fonctions PK11_*. Les faits présentés ici ont été vérifiés sur le paquet Alpine 3.24.2, NSS 3.124, initialisé sans base de clés (NSS_NoDB_Init).
Pour ECDSA, deux couches produisent des encodages différents. Dans cryptohi, SEC_SignData et VFY_VerifyData hachent le message et utilisent DER, la forme qu’attendent X.509, CMS et OpenSSL. PK11_Sign et PK11_Verify prennent un condensat et utilisent la forme r‖s brute, 64 octets sur P-256. Les mélanger est l’erreur classique avec NSS ; convertissez avec le convertisseur DER ⇄ brut. PK11_Sign a aussi accepté un condensat de 64 octets sur P-256 et en a signé les 32 premiers octets : passez donc un condensat adapté à la courbe.
Les nonces sont aléatoires (deux signatures du même message différaient) et s n’est pas normalisé ; une signature high-S a passé la vérification. La signature et la vérification ECDSA avec SHA-256 ont réussi sur une clé P-384 : la fonction de hachage n’est donc pas liée à la courbe. Les échecs se distinguent : après que VFY_VerifyData a renvoyé SECFailure, PORT_GetError() signale SEC_ERROR_BAD_DER pour une signature brute ou tronquée et SEC_ERROR_BAD_SIGNATURE pour une signature valide portant sur d’autres données.
Le softoken n’a généré de clés que sur P-256, P-384 et P-521 ; P-224 et secp256k1 ont échoué avec SEC_ERROR_INVALID_KEY. Ed25519 fonctionne via CKM_EC_EDWARDS_KEY_PAIR_GEN et CKM_EDDSA, mais pas Ed448. L’encapsulation ML-KEM-768 fonctionne en aller-retour (PK11_Encapsulate, PK11_Decapsulate), tandis que les en-têtes déclarent des mécanismes ML-DSA que le softoken de ce build ne propose pas. Comparez le KEM avec l’outil ML-KEM.