Aller au contenu
ecdsa.com
Référence

Glossaire

302 termes relatifs aux signatures numériques, aux certificats, aux jetons, aux protocoles et à la cryptographie post-quantique, chacun défini en quelques phrases et rattaché aux normes qui le spécifient.

Affichage : 302 sur 302

De A à Z

A

AAGUID (GUID d’attestation de l’authentificateur)
L’ID de 16 octets qui, dans les données d’identifiant attestées de WebAuthn, désigne le modèle d’authentificateur, par exemple une clé de sécurité précise ou un gestionnaire de mots de passe, et sert à retrouver ses métadonnées et ses icônes.
AC (autorité de certification)
Un organisme ou un service qui émet et signe des certificats après avoir vérifié que le demandeur contrôle les noms ou l’identité que le certificat attestera.
AC intermédiaire
Un certificat d’AC signé par une racine ou une autre AC intermédiaire, dont la clé émet les certificats d’entité finale, ce qui laisse la clé racine hors ligne.
AC racine (certificat racine)
Un certificat d’AC auto-signé, approuvé d’emblée car présent dans le magasin de certificats racines : l’ancre où doit aboutir tout chemin de certification.
ACME (gestion automatique des certificats)
Le protocole de la RFC 8555, créé pour Let’s Encrypt, dans lequel un client prouve qu’il contrôle des identifiants au moyen de challenges et obtient des certificats d’une AC sans intervention humaine.
Adresse Bitcoin
Un encodage lisible par un humain d’un script de sortie Bitcoin : les anciens formats P2PKH (1…) et P2SH (3…) en Base58Check, SegWit v0 (bc1q…) en bech32 et Taproot (bc1p…) en bech32m.
Adresse Ethereum
Un identifiant de compte de 20 octets : pour un compte externe, les 20 derniers octets du condensat Keccak-256 de la clé publique non compressée de 64 octets (secp256k1), sans son préfixe 0x04, écrits sous la forme 0x suivi de 40 chiffres hexadécimaux.
AEAD (chiffrement authentifié avec données associées)
Un mode de chiffrement symétrique qui assure confidentialité et intégrité en une seule opération et authentifie en outre des données associées non chiffrées, comme des en-têtes ; la RFC 5116 en donne une définition générique.
AES-GCM
AES en mode Galois/Counter (NIST SP 800-38D), l’AEAD le plus déployé : un chiffrement en mode compteur associé à un authentificateur GHASH, généralement avec un nonce de 96 bits et un tag de 128 bits.
age (chiffrement de fichiers)
Un outil et un format de chiffrement de fichiers, compacts et modernes (age-encryption.org/v1), créés par Filippo Valsorda, qui chiffrent pour des destinataires X25519, SSH ou hybrides post-quantiques, ou avec une phrase de passe, sans signatures ni configuration.
Agilité cryptographique (crypto-agilité)
La capacité d’un système à changer d’algorithmes cryptographiques, de tailles de clé et de paramètres sans refonte – grâce à la négociation, à la configuration et à l’inventaire –, que la transition post-quantique fait passer du statut de bonne pratique à celui de nécessité.
Agrafage OCSP (OCSP stapling)
Une fonctionnalité de TLS dans laquelle le serveur obtient une réponse OCSP récente pour son propre certificat et l’envoie dans le handshake, ce qui épargne aux clients une interrogation de l’AC préjudiciable à leur confidentialité.
alg (en-tête JOSE de l’algorithme)
Le paramètre d’en-tête JOSE qui désigne l’algorithme de signature ou de MAC d’un JWS (par exemple ES256) ou l’algorithme de gestion des clés d’un JWE (par exemple RSA-OAEP-256), enregistré par la RFC 7518 et des RFC ultérieures.
alg none (JWS non sécurisé)
La valeur d’algorithme JWS none (RFC 7518 §3.6) qui désigne un jeton non signé dont la partie signature est vide, et qu’un vérificateur ne doit jamais accepter, sauf s’il attend explicitement un contenu non sécurisé.
Algorithme de Grover
L’algorithme de recherche quantique de Lov Grover (1996), qui trouve un élément marqué parmi N en environ √N étapes et divise donc au plus par deux la sécurité effective, en bits, des clés symétriques et des préimages de hachage.
Algorithme de Shor
L’algorithme quantique de Peter Shor (1994), qui factorise les entiers et calcule les logarithmes discrets en temps polynomial et qui, sur un grand ordinateur quantique tolérant aux fautes, casserait RSA, Diffie–Hellman, ECDSA, EdDSA et ECDH.
Alignement des identifiants DMARC
L’exigence de DMARC selon laquelle le domaine authentifié par SPF (l’expéditeur d’enveloppe) ou par DKIM (le domaine d=) doit correspondre au domaine de l’en-tête From, soit exactement (strict), soit au sein du même domaine organisationnel (relaxed).
ALPN (négociation du protocole applicatif)
L’extension TLS de la RFC 7301 par laquelle le client propose des protocoles applicatifs comme h2 et http/1.1 et le serveur en choisit un pendant le handshake, ce qui évite un aller-retour supplémentaire.
Arbre de Merkle
Un arbre de hachage binaire dans lequel chaque nœud interne est le condensat de ses deux enfants, de sorte qu’un seul condensat racine constitue un engagement sur toutes les feuilles et que l’appartenance ou une croissance en ajout seul peut être démontrée par des preuves de taille logarithmique.
ARC (chaîne de réception authentifiée)
Le protocole expérimental de la RFC 8617 (2019) dans lequel chaque intermédiaire qui traite un message enregistre les résultats d’authentification qu’il a observés et les scelle, afin que le destinataire final puisse se fier à des résultats que le transfert ou des listes de diffusion ont ensuite invalidés.
Armure ASCII
L’encodage texte d’OpenPGP qui représente des paquets binaires en base64 entre des lignes comme -----BEGIN PGP PUBLIC KEY BLOCK----- et -----END PGP PUBLIC KEY BLOCK----- (RFC 9580 §6.2).
ASN.1 (notation de syntaxe abstraite numéro un)
Le langage UIT-T X.680 qui décrit des structures de données indépendamment de leur encodage, utilisé pour définir les certificats X.509, CMS, les clés PKCS #8, OCSP, LDAP et des protocoles de télécommunications.
Attaque par canal auxiliaire
Une attaque qui déduit des secrets du comportement physique ou temporel d’un calcul (son temps d’exécution, ses accès au cache, sa consommation électrique, ses émissions électromagnétiques ou sa réaction à des fautes provoquées) plutôt que de ses entrées et sorties.
Attaque par courbe invalide
Une attaque dans laquelle un pair envoie un point qui n’est pas sur la courbe convenue, si bien qu’une implémentation qui omet la validation des points calcule sur une courbe plus faible et divulgue sa clé privée morceau par morceau.
Attaque par extension de longueur
Une attaque contre les fonctions de hachage de Merkle–Damgård comme MD5, SHA-1, SHA-256 et SHA-512, qui calcule H(secret ‖ m ‖ remplissage ‖ m′) à partir de H(secret ‖ m) et de la longueur de secret ‖ m, sans connaître le secret.
Attestation (WebAuthn)
Une déclaration, signée par la clé d’attestation d’un authentificateur lors de l’enregistrement, qui indique à une partie de confiance quel type d’authentificateur a créé un identifiant, afin qu’elle puisse appliquer des politiques d’appareils.
Attestation vérifiable
Un ensemble de claims sur un sujet, dont toute altération est détectable, signé par un émetteur et conservé par le sujet dans un portefeuille, qu’un vérificateur peut contrôler sans contacter l’émetteur ; il est normalisé sous plusieurs formats (W3C VC, SD-JWT VC, mdoc).
aud (claim d’audience)
Le claim JWT enregistré (RFC 7519 §4.1.3) qui désigne les destinataires prévus d’un jeton, sous forme de chaîne ou de tableau de chaînes ; chaque destinataire doit vérifier qu’il contient son propre identifiant.
Authenticode
Le format de signature de code de Microsoft pour les exécutables, pilotes, programmes d’installation et scripts Windows : une structure SignedData PKCS #7 portant sur un condensat du fichier, intégrée dans la table des certificats PE et généralement horodatée.
Authentificateur (FIDO/WebAuthn)
Le composant qui détient les identifiants WebAuthn et produit les signatures : un authentificateur de plateforme intégré à un appareil, une clé de sécurité itinérante ou un gestionnaire d’identifiants qui synchronise les clés d’accès.

B

Base64url
L’alphabet base64 compatible avec les URL et les noms de fichiers de la RFC 4648 §5, qui remplace + et / par - et _ et qui, dans JOSE, omet les = de remplissage ; chaque partie d’un JWT est encodée en base64url.
Baseline Requirements (exigences de base, BR)
Les règles du CA/Browser Forum pour l’émission et la gestion des certificats de serveur TLS de confiance publique : méthodes de validation, profils de certificats, durées de vie, révocation et fonctionnement des AC.
BIMI (indicateurs de marque des e-mails)
Un schéma fondé sur un enregistrement DNS et un certificat, encore à l’état d’Internet-Draft à l’IETF, qui permet à un domaine dont la politique DMARC est restrictive d’afficher son logo à côté des messages dans les messageries compatibles, comme Gmail, Yahoo et Apple Mail.
BIP-32 (portefeuilles HD)
Le standard Bitcoin qui dérive un arbre de clés d’une seule graine avec HMAC-SHA512 et des codes de chaîne, si bien qu’une seule sauvegarde couvre toutes les adresses et que les clés publiques étendues peuvent dériver des adresses de réception sans clés privées.
BIP-39 (phrases de récupération mnémoniques)
Le standard qui encode l’entropie d’un portefeuille en 12 à 24 mots tirés d’une liste de 2048 mots, puis étire la phrase avec PBKDF2-HMAC-SHA512 (2048 itérations) pour obtenir la graine de 64 octets utilisée par BIP-32.
BIP-137 (format de message signé)
Le format Bitcoin de signature de messages qui utilise une signature ECDSA récupérable de 65 octets dont l’octet d’en-tête encode à la fois l’identifiant de récupération et le type d’adresse : 27–30 P2PKH à clé non compressée, 31–34 à clé compressée, 35–38 P2SH-P2WPKH, 39–42 P2WPKH.
BIP-322 (signature générique de messages)
Le standard Bitcoin de signature de messages qui prouve le contrôle de tout type d’adresse, y compris SegWit, Taproot et multisig, en signant une transaction virtuelle qui dépense depuis l’adresse.
BIP-340 (signatures Schnorr pour secp256k1)
Le standard Bitcoin des signatures Schnorr de 64 octets sur secp256k1, à clés publiques x-only de 32 octets et hachages étiquetés, utilisé par Taproot et Nostr.
BLAKE2
Une famille de fonctions de hachage rapides (BLAKE2b pour les plateformes 64 bits, avec des condensats jusqu’à 64 octets, BLAKE2s pour les plateformes 32 bits, jusqu’à 32 octets), spécifiée dans la RFC 7693 et utilisée dans Argon2, WireGuard, PASETO et libsodium.

C

C2PA (Content Credentials)
La norme de la C2PA (coalition pour la provenance et l’authenticité des contenus) pour des manifestes de provenance signés, intégrés aux images, vidéos, fichiers audio et documents, qui enregistrent qui a créé ou modifié un contenu et avec quels outils, génération par IA comprise.
CA/Browser Forum
L’organisme à adhésion volontaire qui réunit des autorités de certification et des éditeurs de navigateurs et de systèmes d’exploitation, et qui rédige les Baseline Requirements et d’autres règles pour les certificats de confiance publique : TLS, S/MIME et signature de code.
CAA (autorisation des autorités de certification)
Un type d’enregistrement DNS (RFC 8659) par lequel le propriétaire d’un domaine liste les AC autorisées à émettre des certificats pour ses noms, et que toute AC publique doit vérifier avant l’émission.
Canonicalisation
La transformation de données en une représentation unique et convenue en octets avant le hachage ou la signature, afin que des entrées sémantiquement équivalentes (espaces différents, ordre des clés, préfixes d’espace de noms ou repliement des en-têtes) produisent la même entrée de signature.
Canonicalisation DKIM
Les deux algorithmes, simple et relaxed (RFC 6376 §3.4), qui normalisent les en-têtes et le corps d’un message avant le hachage DKIM, choisis indépendamment pour les en-têtes et pour le corps avec la balise c=.
Catégorie de sécurité post-quantique du NIST
L’un des cinq niveaux de robustesse que le NIST définit pour les jeux de paramètres post-quantiques par comparaison avec le cassage d’AES ou de SHA-2/SHA-3 : catégorie 1 ≈ recherche de clé AES-128, 3 ≈ AES-192, 5 ≈ AES-256, les catégories 2 et 4 étant calées sur les collisions de SHA-256 et de SHA3-384.
CBOM (nomenclature cryptographique)
Un inventaire lisible par machine des actifs cryptographiques d’un système (algorithmes, clés, certificats, protocoles et bibliothèques, avec leurs paramètres), utilisé pour planifier et suivre des migrations comme le passage à la cryptographie post-quantique.
Certificat (certificat de clé publique)
Une déclaration signée par un émetteur attestant qu’une clé publique donnée appartient à un sujet nommé, valable pour une durée limitée et pour des usages déterminés, le plus souvent au format X.509.
Certificat auto-signé
Un certificat dont l’émetteur et le sujet sont identiques et dont la signature a été produite avec sa propre clé privée ; il n’est donc approuvé que là où il a été installé comme ancre de confiance.
Certificat de courte durée
Un certificat dont la validité est si courte (au plus 7 jours pour les certificats TLS publics émis depuis le 15 mars 2026) qu’il expire tout simplement, sans dépendre des contrôles de révocation.
Certificat SSH
Une déclaration signée propre à OpenSSH (pas X.509) dans laquelle la clé d’une autorité de certification lie la clé publique d’un utilisateur ou d’un hôte à des principaux (principals), à une fenêtre de validité et à des options, ce qui évite de distribuer les clés une à une.
Certificat wildcard
Un certificat portant un nom alternatif du sujet tel que *.example.com, qui correspond à une seule étiquette quelconque à cette position, par exemple www.example.com, mais ni à example.com ni à a.b.example.com.
Certificate Transparency (CT)
Le système de journaux publics en ajout seul, fondés sur des arbres de Merkle (RFC 6962), auxquels les AC soumettent chaque certificat TLS de confiance publique, afin que les propriétaires de domaines et les services de surveillance puissent détecter les certificats émis à tort.
Certificats en arbre de Merkle (MTC)
Un modèle de certificats en cours de normalisation à l’IETF, dans lequel une AC consigne chaque émission dans un arbre de Merkle et les clients vérifient une courte preuve d’inclusion au lieu de volumineuses signatures post-quantiques.
ChaCha20-Poly1305
L’AEAD qui associe l’algorithme de chiffrement par flot ChaCha20 à l’authentificateur Poly1305 (RFC 8439) : clés de 256 bits, nonces de 96 bits et tags de 128 bits, rapide en logiciel sans matériel AES.
Chaîne de certificats
La séquence ordonnée de certificats qui va d’un certificat d’entité finale (feuille) à une racine de confiance en passant par un ou plusieurs certificats d’AC intermédiaires, chacun étant signé par le suivant.
Challenge ACME dns-01
La méthode de validation de domaine d’ACME dans laquelle le client publie, à _acme-challenge.domain, un enregistrement TXT contenant base64url(SHA-256(autorisation de clé)), la seule méthode ACME capable de valider des noms wildcard.
Challenge ACME http-01
La méthode de validation de domaine d’ACME dans laquelle le client sert l’autorisation de clé à l’adresse http://domain/.well-known/acme-challenge/token sur le port 80, et l’AC la récupère depuis plusieurs points d’observation du réseau.
Clé d’accès (passkey)
Un identifiant détectable FIDO2/WebAuthn (une paire de clés liée à un site web ou à une application, déverrouillée par la biométrie, le PIN ou le mot de passe de l’appareil) qui remplace un mot de passe par une signature résistante à l’hameçonnage.
Clé d’hôte SSH
La paire de clés à long terme avec laquelle un serveur SSH signe chaque échange de clés, prouvant son identité aux clients qui ont enregistré la clé publique dans known_hosts ou qui font confiance à une AC qui l’a certifiée.
Clé faible
Une clé plus fragile que ne l’indique sa taille nominale : générateur défaillant, entropie insuffisante, défaut structurel ou réutilisation entre appareils.
Clé OpenPGP v6
Le format de clé introduit par la RFC 9580, avec des empreintes SHA-256 de 32 octets, les algorithmes natifs Ed25519/X25519/Ed448/X448 et des signatures v6 salées, qui remplace les clés v4 de la RFC 4880 fondées sur SHA-1.
Clé privée
La moitié secrète d’une paire de clés asymétrique, utilisée pour signer, déchiffrer ou réaliser un accord de clé ; quiconque la détient peut agir comme son propriétaire, elle ne doit donc jamais quitter sans protection son périmètre de confiance.
Clé publique
La moitié d’une paire de clés asymétrique qui peut être librement partagée et sert à vérifier des signatures, à chiffrer à destination du détenteur de la clé privée correspondante ou à réaliser un accord de clé avec lui.
ClientHello
Le premier message du handshake TLS, envoyé en clair, dans lequel le client liste les versions, suites de chiffrement, groupes, algorithmes de signature et key shares qu’il prend en charge, ainsi que des extensions comme le nom du serveur.
CMS (syntaxe des messages cryptographiques)
Le successeur IETF de PKCS #7 (RFC 5652) pour les données signées, enveloppées et authentifiées, utilisé par S/MIME, Authenticode, les signatures PDF, les horodatages RFC 3161 et de nombreux formats de micrologiciels.
CNSA 2.0
La Commercial National Security Algorithm Suite 2.0 de la NSA (septembre 2022), qui impose ML-KEM-1024, ML-DSA-87, LMS ou XMSS, AES-256 et SHA-384 ou SHA-512 dans les systèmes de sécurité nationale américains d’ici 2030 à 2035.
Cofacteur
Le rapport h = #E / n entre le nombre de points d’une courbe elliptique et l’ordre premier n du sous-groupe utilisé en cryptographie : 1 pour les courbes P du NIST et secp256k1, 8 pour Curve25519, 4 pour Curve448.
Compression de point
L’encodage d’un point de courbe elliptique par sa coordonnée x et un bit de y au lieu des deux coordonnées, ce qui divise environ par deux la taille de la clé publique au prix d’une racine carrée au décodage.
Compression des certificats TLS
L’extension TLS 1.3 de la RFC 8879 (compress_certificate, 27) qui permet au serveur de compresser sa chaîne de certificats avec zlib, brotli ou zstd, ce qui la réduit généralement d’un tiers ou plus.
Condensat de message (digest)
La sortie de longueur fixe d’une fonction de hachage cryptographique appliquée à des données, utilisée comme identifiant compact de ces données, résistant aux collisions, et comme entrée que la plupart des schémas de signature signent réellement.
Confidentialité persistante (forward secrecy)
La propriété selon laquelle la compromission de clés à long terme, comme la clé du certificat d’un serveur, n’expose pas les sessions passées ; on l’obtient en dérivant les clés de chaque session d’un échange de clés éphémères dont les valeurs sont ensuite effacées.
Confusion d’algorithme (confusion de clé)
Une faille de vérification dans laquelle une bibliothèque laisse l’en-tête alg du jeton choisir l’algorithme, si bien qu’une clé prévue pour un algorithme est utilisée avec un autre : classiquement, une clé publique RSA employée comme secret HS256.
Contraintes de base (Basic Constraints)
L’extension X.509 (OID 2.5.29.19) dont l’indicateur cA précise si un certificat appartient à une AC autorisée à signer d’autres certificats, avec un pathLenConstraint facultatif qui limite le nombre d’AC pouvant suivre ce certificat dans la chaîne.
Contraintes de noms (Name Constraints)
L’extension X.509 (OID 2.5.29.30), autorisée uniquement dans les certificats d’AC, qui limite les noms que peuvent contenir les certificats subordonnés au moyen de sous-arbres autorisés et exclus de noms DNS, de plages IP, de domaines e-mail et de noms d’annuaire.
COSE (signature et chiffrement d’objets CBOR)
L’équivalent CBOR de JOSE (RFC 9052, RFC 9053) pour signatures, MAC, chiffrement et clés, utilisé par WebAuthn, les permis de conduire mdoc, les CWT et C2PA.
cosign
L’outil en ligne de commande de Sigstore pour signer et vérifier des images de conteneurs, des blobs et des attestations, soit avec des clés, soit sans clé grâce à des identités OIDC et à des certificats à courte durée de vie.
Courbe elliptique
L’ensemble des points qui satisfont une équation cubique comme y² = x³ + ax + b sur un corps fini, muni d’une loi d’addition de points qui forme le groupe utilisé par ECDSA, EdDSA et ECDH.
Courbes Brainpool
Une famille de courbes elliptiques aux paramètres pseudo-aléatoires vérifiables (RFC 5639, 2010), privilégiée par les profils gouvernementaux allemands et d’autres pays européens comme alternative aux courbes du NIST.
CRL (liste de révocation de certificats)
Une liste de numéros de série de certificats révoqués, signée et publiée périodiquement par une AC (RFC 5280 §5), que les vérificateurs téléchargent pour contrôler la révocation sans interroger l’AC pour chaque certificat.
CRLite
Le mécanisme de révocation de Firefox, qui compresse le statut de révocation de chaque certificat journalisé dans Certificate Transparency en filtres compacts, téléchargés par le navigateur et interrogés localement.
Cryptographie post-quantique (PQC)
Les algorithmes à clé publique conçus pour résister aux grands ordinateurs quantiques, comme ML-KEM, ML-DSA et SLH-DSA (FIPS 203–205, 2024), qui remplacent RSA, Diffie-Hellman et les schémas à courbes elliptiques.
Cryptographie sur les réseaux euclidiens
Une cryptographie fondée sur des problèmes difficiles dans des réseaux euclidiens de grande dimension, comme Learning With Errors (apprentissage avec erreurs) et le problème Short Integer Solution, à la base de ML-KEM, ML-DSA et FN-DSA.
CSPRNG (générateur d’aléa cryptographique)
Un générateur de nombres aléatoires dont la sortie ne peut être ni prédite ni distinguée d’un aléa véritable, même par un attaquant qui a vu les sorties précédentes, et qui est indispensable pour les clés, les nonces, les sels et les jetons.
CSR (demande de signature de certificat)
Un message PKCS #10 (RFC 2986) contenant un nom de sujet, une clé publique et des attributs demandés, signé avec la clé privée correspondante pour en prouver la possession, et qu’une AC transforme en certificat.
CTAP (protocole client-authentificateur)
Le protocole de la FIDO Alliance entre un client (navigateur ou système d’exploitation) et un authentificateur externe, via USB HID, NFC, Bluetooth ou le transport hybride par téléphone, avec des commandes encodées en CBOR comme authenticatorMakeCredential.
Curve25519
La courbe de Montgomery y² = x³ + 486662x² + x modulo le nombre premier 2²⁵⁵ − 19, publiée par Daniel J. Bernstein en 2005, qui sert de base à l’échange de clés X25519 et, sous sa forme d’Edwards, aux signatures Ed25519.
CWT (CBOR Web Token)
L’équivalent CBOR du JWT (RFC 8392) : un ensemble de claims encodé en map CBOR à clés entières et protégé par une signature, un MAC ou un chiffrement COSE.

D

DANE (authentification DNS d’entités nommées)
L’utilisation d’enregistrements TLSA signés par DNSSEC (RFC 6698, RFC 7671) pour indiquer quel certificat ou quelle clé publique un service TLS doit présenter, en complément des AC publiques ou à leur place.
DER (règles de codage distinctives)
L’encodage binaire canonique d’ASN.1 défini par la recommandation ITU-T X.690, qui donne à chaque valeur exactement une représentation en octets : c’est pourquoi les certificats, les CSR, les CRL, les clés et de nombreuses signatures sont encodés en DER.
DID (identifiant décentralisé)
Un URI de la forme did:method:identifier (W3C DID Core 1.0, 2022) qui se résout en un document DID listant des clés publiques et des points de terminaison de service, et qui est contrôlé par son sujet plutôt que par un registre central.
DKIM (DomainKeys Identified Mail)
La norme d’authentification des e-mails de la RFC 6376 dans laquelle le domaine expéditeur signe certains en-têtes et le corps d’un message et publie la clé publique dans le DNS, afin que les destinataires puissent vérifier que le message provient bien de ce domaine sans avoir été modifié.
DMARC
Domain-based Message Authentication, Reporting and Conformance (RFC 9989, mai 2026) : une politique publiée dans le DNS qui exige que SPF ou DKIM réussisse en alignement avec le domaine From visible et qui indique aux destinataires que faire des messages en échec.
DNSSEC
Les extensions de sécurité du DNS (DNS Security Extensions, RFC 4033–4035), qui signent les ensembles d’enregistrements DNS afin que les résolveurs validants puissent vérifier que les réponses proviennent sans modification du propriétaire de la zone, par une chaîne qui remonte à la clé de la zone racine.
DoH (DNS over HTTPS)
Le protocole de la RFC 8484 qui transporte les requêtes et les réponses DNS dans des requêtes HTTPS (type de média application/dns-message), ce qui les masque aux observateurs situés sur le chemin et permet aux applications web de résoudre des noms directement.
Données d’authentificateur
La structure binaire que porte chaque réponse WebAuthn : un condensat SHA-256 de 32 octets du RP ID, un octet d’indicateurs, un compteur de signatures de 4 octets et, en option, des données d’identifiant attestées et des sorties d’extensions CBOR.
DPoP (démonstration de preuve de possession)
Le mécanisme OAuth de la RFC 9449 qui lie les jetons d’accès et les jetons d’actualisation à une clé détenue par le client : chaque requête porte une nouvelle preuve DPoP signée, sous forme de JWT, si bien qu’un jeton volé ne sert à rien à lui seul.
DSA (algorithme de signature numérique)
L’algorithme de signature fondé sur le logarithme discret dans un corps fini, défini par FIPS 186 (1994), retiré par FIPS 186-5 en 2023 pour les nouvelles signatures et conservé uniquement pour vérifier les signatures existantes.
Durée de vie des certificats (période de validité)
L’intervalle entre le notBefore et le notAfter d’un certificat, bornes incluses ; pour les certificats TLS de confiance publique, le maximum est de 200 jours depuis le 15 mars 2026 et passera à 100 jours en 2027, puis à 47 jours en 2029.

E

ECDH (Diffie–Hellman sur courbe elliptique)
L’accord de clé dans lequel chaque partie combine sa propre clé privée sur courbe elliptique avec la clé publique de l’autre pour calculer le même secret partagé, la coordonnée x de d_A·d_B·G.
ECDH-ES (accord de clé JWE)
La famille d’algorithmes de gestion des clés JWE de la RFC 7518 §4.6 dans laquelle l’expéditeur génère une clé EC éphémère, établit un secret avec la clé statique du destinataire et dérive la clé de contenu avec la Concat KDF.
ECDHE (Diffie–Hellman éphémère sur courbe elliptique)
Le Diffie–Hellman sur courbe elliptique avec de nouvelles paires de clés à chaque handshake, l’échange de clés qui apporte la confidentialité persistante à TLS ; en TLS 1.3, il s’exécute sur x25519, secp256r1 et des groupes similaires.
ECDLP (logarithme discret sur courbe elliptique)
Le problème consistant à retrouver le scalaire d à partir des points G et Q = d·G d’une courbe elliptique, dont la difficulté est l’hypothèse de sécurité sur laquelle reposent ECDSA, EdDSA, ECDH et les signatures Schnorr.
ECDSA (algorithme de signature à courbe elliptique)
La variante de DSA sur courbe elliptique, spécifiée dans FIPS 186-5 et SEC 1, dont la signature est une paire d’entiers (r, s) calculée avec un scalaire privé et un nonce secret neuf.
ECH (Encrypted Client Hello)
L’extension TLS 1.3 de la RFC 9849 qui chiffre le véritable ClientHello, nom du serveur compris, avec une clé publiée dans le DNS, et ne laisse visible sur le réseau qu’un nom public partagé.
ecrecover
Le contrat précompilé d’Ethereum à l’adresse 0x01 (et la fonction ecrecover de Solidity) qui récupère l’adresse du signataire à partir d’un condensat de 32 octets et d’une signature ECDSA (v, r, s) sur secp256k1.
Ed448
EdDSA sur la courbe Edwards448 « Goldilocks » avec SHAKE256 (RFC 8032 §5.2) : environ 224 bits de sécurité, clé publique de 57 octets, signature de 114 octets.
Ed25519
EdDSA sur la forme d’Edwards de Curve25519 avec SHA-512 (RFC 8032 §5.1) : clé publique de 32 octets, signature déterministe de 64, sécurité d’environ 128 bits.
EdDSA (algorithme de signature sur courbes d’Edwards)
Un schéma de signature de type Schnorr sur des courbes d’Edwards tordues, défini dans la RFC 8032 et approuvé dans FIPS 186-5, dont les deux instances standard sont Ed25519 et Ed448.
eIDAS
Le règlement de l’UE sur l’identification électronique et les services de confiance (n° 910/2014, modifié par le règlement 2024/1183), selon lequel les signatures électroniques qualifiées ont l’effet juridique des signatures manuscrites.
EIP-155 (protection contre le rejeu)
La modification d’Ethereum de 2016 (Spurious Dragon, bloc 2 675 000) qui intègre l’ID de chaîne au condensat de signature des transactions et à la valeur v (v = chainId × 2 + 35 ou 36), si bien qu’une transaction destinée à une chaîne est invalide sur les autres.
EIP-191 (standard des données signées)
La convention Ethereum selon laquelle les messages signés commencent par l’octet 0x19 et un octet de version, si bien qu’ils ne peuvent jamais être des transactions valides ; la version 0x45 est le format personal_sign utilisé par la plupart des portefeuilles.
EIP-712 (signature de données typées et structurées)
Le standard Ethereum de hachage et de signature de données typées et structurées avec un séparateur de domaine, qui permet aux portefeuilles d’afficher les champs aux utilisateurs et empêche de rejouer les signatures d’un contrat ou d’une chaîne à l’autre.
EIP-7702 (attribution de code aux EOA)
La mise à niveau d’Ethereum, active depuis le hard fork Pectra du 7 mai 2025, qui permet à un compte externe (EOA) de déléguer son code à un contrat par une autorisation signée dans une transaction de type 0x04.
Empreinte de clé ou de certificat
Un condensat court d’une clé publique ou d’un certificat, qui sert à l’identifier et à le comparer à l’œil ou dans une configuration, par exemple SHA256:… pour les clés SSH ou le SHA-256 des octets DER d’un certificat.
Empreinte JWK (JWK thumbprint)
Un condensat des membres obligatoires d’une JWK sous leur forme canonique JSON (RFC 7638), généralement en SHA-256 encodé en base64url, utilisé comme identifiant de clé stable pour les valeurs kid, les liaisons DPoP et ACME.
En-tête DKIM-Signature
Le champ d’en-tête (RFC 6376 §3.5) qui porte une signature DKIM en paires balise=valeur, dont v, a, c, d, s, h, bh, b et les balises facultatives i, l, t et x.
Encapsulation de signature XML (XSW)
Une classe d’attaques contre les messages signés en XML, dans lesquelles l’attaquant déplace l’élément signé et insère un élément falsifié, si bien que la signature se vérifie toujours sur l’original pendant que l’application traite l’élément falsifié.
ERC-1271 (validation des signatures par les contrats)
Le standard Ethereum par lequel les comptes de contrat intelligent valident les signatures : un vérificateur appelle isValidSignature(bytes32 hash, bytes signature) et considère la valeur de retour 0x1626ba7e comme valide.
ES256
L’algorithme JWS d’ECDSA sur la courbe P-256 avec SHA-256 (RFC 7518 §3.4) : signature de 64 octets exactement, en r‖s brut et non en DER ; algorithme COSE −7.
EUDI Wallet (portefeuille européen d’identité numérique)
Le portefeuille d’identité que chaque État membre de l’UE doit proposer à ses citoyens en vertu du règlement (UE) 2024/1183 (eIDAS 2), et qui contient des données d’identification personnelle et des attestations aux formats SD-JWT VC et mdoc.
Exigences pour les expéditeurs en masse
Les règles que Gmail et Yahoo (depuis février 2024) et Microsoft (depuis mai 2025) imposent aux expéditeurs de plus de 5000 messages par jour environ : SPF, DKIM, un enregistrement DMARC aligné et le désabonnement en un clic.
exp (claim de date d’expiration)
Le claim JWT enregistré (RFC 7519 §4.1.4) qui indique l’instant, en secondes depuis l’epoch Unix, à partir duquel le jeton ne doit plus être accepté.
Extension key_share
L’extension TLS 1.3 (51) qui transporte les valeurs publiques éphémères du client pour un ou plusieurs groupes ainsi que l’unique réponse du serveur, ce qui permet à l’échange de clés d’aboutir dès le premier aller-retour.
Extension signature_algorithms
L’extension TLS (13) dans laquelle un client ou un serveur liste les schémas de signature qu’il accepte, comme ecdsa_secp256r1_sha256, rsa_pss_rsae_sha256 et ed25519, signature_algorithms_cert (50) couvrant séparément les signatures des certificats.

É

Échange de clés (établissement de clé)
L’étape d’un protocole par laquelle deux parties obtiennent un secret partagé sur un canal non sûr, par accord de clé Diffie–Hellman ou par encapsulation de clé ; les clés de session sont dérivées de ce secret.
Échange de clés hybride
Un échange de clés qui combine un algorithme classique tel que X25519 avec un KEM post-quantique tel que ML-KEM, de sorte que la session reste secrète tant qu’au moins un des deux composants n’est pas cassé.
Épinglage de certificat ou de clé publique
Le fait de restreindre à un ensemble fixe les certificats ou clés publiques qu’un client accepte pour un hôte, au-delà de la simple validation de la chaîne, en comparant des condensats de la clé d’une AC, de celle d’un intermédiaire ou de la clé propre du serveur.

F

Falcon (FN-DSA)
Un schéma de signature compact fondé sur les réseaux NTRU, retenu par le NIST en 2022 et en cours de normalisation sous le nom de FN-DSA dans FIPS 206, encore à l’état de projet en octobre 2026.
FIDO2
Le nom générique que la FIDO Alliance donne à l’authentification sans mot de passe par clé publique, composée de l’API WebAuthn du W3C et du protocole client-authentificateur de FIDO (Client to Authenticator Protocol, CTAP 2.x).
FIPS 140-3
La norme américaine et canadienne des modules cryptographiques (2019, alignée sur ISO/IEC 19790), selon laquelle le CMVP valide des modules matériels et logiciels aux niveaux de sécurité 1 à 4.
Fonction de hachage cryptographique
Une fonction qui associe à une entrée de longueur quelconque un condensat de longueur fixe, de sorte que trouver une préimage, une seconde préimage ou une collision quelconque soit calculatoirement infaisable.
Format de clé PKCS #1
Les structures ASN.1 RSAPublicKey et RSAPrivateKey, propres à RSA, définies dans l’annexe A de la RFC 8017 et stockées en PEM sous la forme -----BEGIN RSA PUBLIC KEY----- et -----BEGIN RSA PRIVATE KEY-----.
Format de clé privée OpenSSH
Le conteneur openssh-key-v1 qu’écrit ssh-keygen par défaut depuis OpenSSH 7.8 (2018), stocké sous la forme -----BEGIN OPENSSH PRIVATE KEY----- et chiffré avec une KDF fondée sur bcrypt lorsqu’une phrase de passe est définie.
Format de signature r‖s brut (IEEE P1363)
L’encodage à longueur fixe d’une signature ECDSA ou DSA sous forme de r et s concaténés, chacun avec un remplissage à gauche jusqu’à la longueur en octets de l’ordre du groupe, utilisé par JOSE, COSE, WebCrypto et de nombreuses API de HSM.

H

Hachage des mots de passe
Le stockage d’un mot de passe sous la forme du résultat d’une fonction volontairement lente, salée et de préférence exigeante en mémoire, comme Argon2id, scrypt, bcrypt ou PBKDF2, pour qu’une base de données volée résiste aux tentatives hors ligne de deviner les mots de passe.
Handshake TLS
L’échange initial d’une connexion TLS, au cours duquel le client et le serveur s’accordent sur les paramètres, effectuent un échange de clés, procèdent à l’authentification (en général celle du serveur, par son certificat) et dérivent les clés de trafic.
HKDF
La fonction de dérivation de clé à base de HMAC, de type extraction-expansion (extract-and-expand), définie par la RFC 5869 ; elle transforme un secret partagé, comme une sortie ECDH, en une ou plusieurs clés uniformément aléatoires liées à une chaîne de contexte.
HMAC
Le code d’authentification de message à clé fondé sur le hachage de la RFC 2104 et de FIPS 198-1, calculé comme H((K ⊕ opad) ‖ H((K ⊕ ipad) ‖ m)), qui prouve l’intégrité et l’origine à quiconque partage la clé secrète.
Horodatage de confiance (RFC 3161)
L’obtention, auprès d’une autorité d’horodatage, d’un jeton signé qui lie le condensat de données à une heure de confiance, afin de pouvoir prouver qu’une signature est antérieure à l’expiration ou à la révocation d’un certificat.
HQC (Hamming quasi-cyclique)
Un mécanisme d’encapsulation de clé fondé sur les codes correcteurs, retenu par le NIST le 11 mars 2025 comme solution de secours à ML-KEM et prévu sous le nom FIPS 207 ; son projet de norme n’avait toujours pas été publié en octobre 2026.
HS256
L’algorithme JWS HMAC avec SHA-256 (RFC 7518 §3.2), dans lequel l’émetteur et le vérificateur partagent une même clé secrète d’au moins 256 bits : quiconque peut vérifier un jeton peut donc aussi en créer un.
HSM (module de sécurité matériel)
Un appareil résistant aux manipulations ou un service cloud qui génère et stocke des clés et effectue les opérations cryptographiques à l’intérieur de son périmètre, de sorte que les clés privées ne peuvent pas en être exportées en clair.
HSTS (sécurité stricte du transport HTTP)
L’en-tête de réponse HTTP de la RFC 6797 qui indique aux navigateurs de n’utiliser que HTTPS pour un hôte pendant une durée donnée, d’empêcher l’utilisateur d’ignorer les erreurs de certificat et de passer automatiquement tout lien http:// en HTTPS.

I

Identifiant détectable (clé résidente)
Un identifiant WebAuthn dont la clé privée et l’ID utilisateur (user handle) sont stockés par l’authentificateur, de sorte qu’il puisse être trouvé sans que le serveur envoie d’abord un ID d’identifiant, ce qui permet la connexion par clé d’accès sans nom d’utilisateur.
in-toto
Un framework diplômé de la CNCF pour les déclarations signées de la chaîne d’approvisionnement, dont le format d’attestation (un Statement qui lie des condensats d’artefacts à un prédicat typé) transporte les attestations de provenance SLSA et de SBOM.
Indicateurs SIGHASH
L’octet ajouté à une signature Bitcoin qui sélectionne les parties de la transaction qu’elle couvre : ALL (0x01), NONE (0x02), SINGLE (0x03), chacun pouvant être combiné avec ANYONECANPAY (0x80), plus la valeur par défaut 0x00 de Taproot.
Informations de renouvellement ACME (ARI)
L’extension ACME de la RFC 9773 (juin 2025) par laquelle une AC indique aux clients la période pendant laquelle chaque certificat devrait être renouvelé, ce qui lui permet de répartir la charge et de demander un renouvellement anticipé avant des révocations massives.
iss (claim d’émetteur)
Le claim JWT enregistré (RFC 7519 §4.1.1) qui identifie l’émetteur d’un jeton, et qu’un vérificateur doit comparer exactement à l’émetteur dont il a utilisé les clés pour vérifier la signature.

J

JA4 (empreinte de client TLS)
La méthode de FoxIO (2023) pour prendre l’empreinte des clients TLS à partir de leur ClientHello (protocole, version, SNI, nombres et condensats triés des suites de chiffrement et des extensions), conçue pour rester stable lorsque les navigateurs rendent aléatoire l’ordre des extensions.
Jeton d’accès
Les informations d’identification qu’un client OAuth présente à un serveur de ressources pour appeler une API au nom d’un utilisateur ou en son propre nom : soit une chaîne opaque vérifiée par introspection, soit un JWT autonome.
Jeton d’ID
Le JWT qu’un fournisseur OpenID Connect émet à destination d’un client pour attester qu’un utilisateur s’est authentifié ; il contient au moins les claims iss, sub, aud, exp et iat et il est signé par le fournisseur.
Jeton porteur (Bearer)
Un jeton d’accès qui donne accès à quiconque le présente, sans preuve de possession d’une quelconque clé (RFC 6750), généralement envoyé sous la forme Authorization: Bearer suivi du jeton.
JOSE (signature et chiffrement d’objets JSON)
La famille de formats de l’IETF fondés sur JSON pour signer, chiffrer et représenter des clés (JWS, JWE, JWK, JWA et JWT, RFC 7515 à 7519), ainsi que le groupe de travail qui les maintient.
JWA (JSON Web Algorithms)
La RFC 7518, qui définit les identifiants et paramètres d’algorithmes de JWS, JWE et JWK, tels que HS256, RS256, ES256, PS256, RSA-OAEP, ECDH-ES et A256GCM.
JWE (JSON Web Encryption)
Le format JOSE de la RFC 7516 pour le contenu chiffré, dont la forme compacte comporte cinq parties (en-tête, clé chiffrée, IV, texte chiffré et tag) et qui sépare la gestion des clés (alg) du chiffrement du contenu (enc).
JWK (JSON Web Key)
La représentation JSON d’une clé cryptographique (RFC 7517), avec des membres comme kty, crv, x, y, n et e pour les clés publiques et d pour la partie privée.
JWKS (jeu de clés JSON Web Key)
Un objet JSON listant des JWK publiques, servi au jwks_uri de l’émetteur pour que les parties de confiance vérifient les jetons et suivent la rotation des clés.
JWS (JSON Web Signature)
Le format JOSE de la RFC 7515 pour un contenu signé ou protégé par MAC avec des paramètres décrits en JSON, sérialisé de façon compacte sous la forme header.payload.signature (en-tête, charge utile, signature) ou en JSON avec plusieurs signatures.
JWT (JSON Web Token)
Un jeton compact et compatible avec les URL (RFC 7519) qui transporte un objet JSON de claims, signé sous forme de JWS ou chiffré sous forme de JWE, utilisé pour les jetons d’ID, les jetons d’accès et de nombreuses sessions d’API.

K

Keccak-256
La fonction de hachage Keccak d’origine, avec une sortie de 256 bits et le remplissage antérieur à la normalisation, qu’Ethereum utilise pour les adresses, les sélecteurs de fonctions et les condensats à signer ; ce n’est pas la même fonction que SHA3-256 de FIPS 202.
KEM (mécanisme d’encapsulation de clé)
Une primitive à clé publique dans laquelle Encaps transforme une clé publique en un secret partagé aléatoire accompagné d’un texte chiffré, et Decaps retrouve ce secret avec la clé privée ; elle remplace Diffie–Hellman dans l’échange de clés post-quantique.
Key binding (liaison au détenteur)
La preuve que la partie qui présente une attestation contrôle une clé privée désignée dans celle-ci, si bien qu’une attestation copiée ne peut pas être rejouée par quelqu’un d’autre ; SD-JWT la met en œuvre avec le Key Binding JWT, et mdoc avec l’authentification de l’appareil.
kid (identifiant de clé)
Le paramètre d’en-tête JOSE et membre JWK qui nomme la clé ayant signé ou chiffré un jeton, pour qu’un vérificateur trouve la bonne clé d’un JWKS en rotation.
Kyber (CRYSTALS-Kyber)
La soumission du 3e tour du NIST dont dérive ML-KEM ; déployée tôt en TLS hybride (X25519Kyber768Draft00), elle n’est pas interopérable avec ML-KEM normalisé.

L

LibrePGP
Une spécification OpenPGP maintenue par l’auteur de GnuPG (draft-koch-librepgp), qui prolonge la lignée RFC 4880bis avec des clés v5 et son propre chiffrement composite Kyber, incompatible avec les clés v6 de la RFC 9580.
Limite SPF de 10 requêtes DNS
La règle de la RFC 7208 selon laquelle l’évaluation d’un enregistrement SPF peut déclencher au plus 10 mécanismes et modificateurs qui interrogent le DNS (include, a, mx, ptr, exists, redirect), au-delà desquels le résultat est permerror.
LMS et HSS (signatures de Leighton–Micali)
Le schéma de signature avec état fondé sur le hachage de la RFC 8554 et de la NIST SP 800-208, dans lequel un arbre de Merkle de clés à usage unique de Winternitz signe un nombre fixe de messages, et HSS empile des arbres pour en signer davantage.

M

Magasin de certificats racines
L’ensemble des certificats d’AC racines qu’un système d’exploitation, un navigateur ou un environnement d’exécution approuve comme ancres de confiance pour la validation du chemin de certification, tenu par un programme de certificats racines selon sa propre politique.
Malléabilité des signatures
La propriété d’un schéma de signature ou de son encodage qui permet à quiconque de transformer une signature valide en une autre signature valide pour le même message et la même clé, sans connaître la clé privée.
MD5
La fonction de hachage de 128 bits conçue par Ron Rivest en 1991 (RFC 1321), cassée pour les collisions depuis 2004 et pour les collisions à préfixe choisi depuis 2007, et non sûre pour tout usage de sécurité dans lequel un attaquant peut influer sur l’entrée.
mDL (permis de conduire mobile)
Un permis de conduire ou une pièce d’identité officielle stockés sur un téléphone sous forme de mdoc ISO/IEC 18013-5 et présentés en personne, par NFC ou Bluetooth, ou en ligne ; chaque élément de données y est révélé séparément et signé par l’autorité émettrice.
mdoc (document mobile ISO/IEC 18013-5)
Le format d’attestation fondé sur CBOR de l’ISO/IEC 18013-5, créé pour les permis de conduire mobiles, dans lequel un émetteur signe les condensats de chaque élément dans un Mobile Security Object et l’appareil prouve la possession à l’aide de sa propre clé.
ML-DSA (FIPS 204)
L’algorithme de signature numérique fondé sur les réseaux modulaires de FIPS 204 (août 2024), issu de CRYSTALS-Dilithium : la principale signature post-quantique du NIST, avec les jeux de paramètres ML-DSA-44, ML-DSA-65 et ML-DSA-87.
ML-KEM (FIPS 203)
Le mécanisme d’encapsulation de clé fondé sur les réseaux modulaires de FIPS 203 (août 2024), issu de CRYSTALS-Kyber : l’échange de clés post-quantique standard, avec les jeux de paramètres ML-KEM-512, ML-KEM-768 et ML-KEM-1024.
mlkem768x25519-sha256
L’échange de clés hybride SSH associant ML-KEM-768, X25519 et SHA-256, normalisé par la RFC 10042, par défaut dans OpenSSH depuis la version 10.0 (avril 2025).
Mot de passe
Une chaîne secrète mémorisée par un utilisateur et vérifiée par un serveur, l’authentificateur le plus courant et le plus exposé à l’hameçonnage, que la NIST SP 800-63B-4 encadre par des règles de longueur, de listes de blocage et de stockage plutôt que de complexité.
MTA-STS (sécurité stricte du transport SMTP)
Le mécanisme de la RFC 8461 par lequel un domaine de messagerie publie en HTTPS une politique qui impose aux expéditeurs de ne livrer qu’en TLS, avec un certificat valide, aux hôtes MX listés.
mTLS (TLS mutuel)
Le TLS dans lequel le client s’authentifie lui aussi avec un certificat et une signature CertificateVerify, si bien que les deux extrémités prouvent la possession de leurs clés privées ; courant pour le trafic entre services, les appareils et, dans OAuth, les jetons liés à l’expéditeur.
Multisig Safe (compte intelligent Safe)
Le portefeuille de contrat intelligent le plus utilisé sur Ethereum, qui n’exécute une transaction que lorsqu’un seuil de propriétaires a signé son hash SafeTx EIP-712 ; les signatures peuvent être des signatures ECDSA, des signatures de contrat (ERC-1271) ou des approbations sur la chaîne.
MuSig2
Le schéma de multisignature en deux tours de BIP-327, dans lequel n signataires produisent ensemble une seule signature Schnorr BIP-340 valide pour une unique clé publique agrégée, indiscernable sur la chaîne d’une dépense à signataire unique.

N

NIST IR 8547
Le document du NIST « Transition to Post-Quantum Cryptography Standards » (transition vers les normes de cryptographie post-quantique), projet public initial de novembre 2024, qui propose de déprécier après 2030 les algorithmes vulnérables au quantique offrant 112 bits de sécurité et d’interdire tous les algorithmes vulnérables après 2035.
Niveau de sécurité (bits de sécurité)
Une mesure de la robustesse cryptographique selon laquelle s bits signifient que la meilleure attaque connue demande environ 2ˢ opérations, utilisée pour comparer les tailles de clé d’algorithmes comme AES-128, P-256 et RSA-3072.
Nom alternatif du sujet (SAN)
L’extension X.509 (OID 2.5.29.17) qui liste les noms DNS, adresses IP, adresses e-mail ou URI pour lesquels un certificat est valide, et le seul champ auquel les navigateurs comparent le nom d’hôte d’un serveur.
Nom distinctif (DN)
Le nom hiérarchique X.500 qui désigne le sujet et l’émetteur d’un certificat, construit à partir de paires attribut–valeur comme CN, O, OU, L, ST et C.
Nonce (k d’ECDSA)
Nombre utilisé une seule fois ; en ECDSA, DSA et Schnorr, c’est le secret k de chaque signature, qui doit aussi être imprévisible et uniformément distribué.
Normalisation low-S
La règle selon laquelle la valeur s d’une signature ECDSA doit se situer dans la moitié inférieure de l’intervalle (s ≤ n/2), adoptée par Bitcoin et Ethereum pour éliminer la malléabilité des signatures inhérente à ECDSA.
Nostr
Un protocole décentralisé de réseau social et de messagerie dans lequel les utilisateurs sont des paires de clés secp256k1 et chaque événement est un objet JSON identifié par son condensat SHA-256 et signé avec une signature Schnorr BIP-340.
Notarisation Apple
L’analyse automatisée d’Apple qui recherche les logiciels malveillants dans les logiciels Mac signés avec un Developer ID : les développeurs envoient leurs builds avec notarytool, Apple renvoie un ticket que Gatekeeper vérifie, et ce ticket peut être agrafé (stapled) à l’app ou au programme d’installation.
Numéro de série de certificat
L’entier positif, unique par émetteur et d’au plus 20 octets, qui identifie un certificat dans les CRL, les requêtes OCSP et les rapports d’incident.

O

OAuth 2.0
Le cadre d’autorisation de la RFC 6749 (2012) dans lequel un serveur d’autorisation délivre des jetons d’accès aux clients pour qu’ils appellent des API avec des permissions déléguées et limitées par scope, au lieu des mots de passe des utilisateurs.
OCSP (protocole de statut des certificats)
Le protocole de la RFC 6960 par lequel un client demande au répondeur d’une AC si un certificat donné est révoqué et reçoit une réponse signée (bon, révoqué ou inconnu) assortie d’une fenêtre de validité.
OID (identifiant d’objet)
Une suite d’entiers séparés par des points, unique au monde, comme 1.2.840.10045.2.1, attribuée au sein d’une arborescence d’enregistrement à délégation et utilisée en ASN.1 pour nommer des algorithmes, des courbes, des extensions et des politiques.
OIDC (OpenID Connect)
La couche d’identité au-dessus d’OAuth 2.0 (OpenID Connect Core 1.0, 2014) qui permet à un client de vérifier qui est un utilisateur grâce à un jeton d’ID signé et d’obtenir des claims de profil auprès d’un point de terminaison UserInfo.
OpenID4VP (présentations vérifiables)
Le protocole de l’OpenID Foundation (version finale 1.0, juillet 2025) par lequel un vérificateur demande des attestations à un portefeuille et reçoit une présentation ; fondé sur OAuth 2.0, il est utilisé par le portefeuille européen d’identité numérique (EUDI Wallet).
OpenPGP
La norme de l’IETF pour le chiffrement à clé publique et la signature de messages et de fichiers avec des clés gérées par l’utilisateur (RFC 9580, juillet 2024), implémentée par GnuPG, Sequoia, OpenPGP.js et d’autres.

P

P-256 (secp256r1)
La courbe elliptique du NIST sur un corps premier de 256 bits, aussi appelée secp256r1 et prime256v1, qui offre environ 128 bits de sécurité et qui est la courbe la plus déployée pour ECDSA et ECDH.
P-384 (secp384r1)
La courbe elliptique du NIST sur corps premier, avec un ordre de 384 bits, qui offre environ 192 bits de sécurité, exigée par la suite CNSA 1.0 de la NSA et courante dans les hiérarchies des administrations et des AC.
P-521 (secp521r1)
La plus grande des courbes du NIST sur corps premier, définie modulo le nombre premier de Mersenne 2⁵²¹ − 1, qui offre environ 256 bits de sécurité ; en JOSE, ES512 désigne ECDSA sur P-521 avec SHA-512, et non une courbe de 512 bits.
PAdES
Le profil ETSI des signatures PDF (EN 319 142) pour les signatures électroniques avancées au sens d’eIDAS, avec les niveaux de base B-B, B-T (signature horodatée), B-LT (données de validation intégrées) et B-LTA (horodatages d’archivage).
Paire de clés
Clé privée et clé publique liées mathématiquement, générées ensemble pour un algorithme asymétrique et, idéalement, un seul usage (signature ou accord de clé).
Partage de secret de Shamir
Le schéma d’Adi Shamir (1979) qui divise un secret en n parts au moyen d’un polynôme aléatoire : k parts quelconques le reconstituent, k − 1 n’en révèlent rien.
PASETO (jetons de sécurité multiplateformes)
Un format de jeton conçu comme une alternative plus simple à JOSE, avec des protocoles versionnés au lieu d’algorithmes négociables : les jetons v4.public sont signés avec Ed25519, et les jetons v4.local sont chiffrés avec XChaCha20 et authentifiés avec BLAKE2b à clé.
PEM
L’habillage textuel de données DER en base64 entre des lignes -----BEGIN étiquette----- et -----END étiquette-----, normalisé pour les objets PKIX dans la RFC 7468 et utilisé par la plupart des outils pour stocker certificats et clés.
permit (EIP-2612 et Permit2)
Approbation de jetons par signature : une signature EIP-712 hors chaîne, qui remplace une transaction approve sur la chaîne, autorise un spender (l’adresse autorisée à dépenser) à déplacer des jetons, soit jeton par jeton (EIP-2612), soit via le contrat Permit2 partagé d’Uniswap.
personal_sign
La méthode JSON-RPC des portefeuilles Ethereum qui signe un message avec le préfixe EIP-191 version 0x45 et renvoie une signature r‖s‖v de 65 octets ; c’est la méthode par défaut pour la connexion et la signature de messages simples.
PIV (vérification d’identité personnelle)
La norme fédérale américaine de carte à puce (FIPS 201-3, 2022) et son interface de carte (SP 800-73), dont les emplacements de clé 9A, 9C, 9D et 9E contiennent les clés d’authentification, de signature, de gestion des clés et d’authentification de la carte ; les YubiKey et d’autres jetons matériels la mettent en œuvre.
PKCE (clé de preuve pour l’échange de code)
L’extension OAuth de la RFC 7636 dans laquelle le client envoie un condensat d’un code_verifier aléatoire avec la requête d’autorisation, puis le code_verifier lui-même avec la requête de jeton, de sorte qu’un code d’autorisation intercepté est inutilisable.
PKCS #8
Le conteneur de clé privée indépendant de l’algorithme (PrivateKeyInfo, RFC 5208 ; OneAsymmetricKey, RFC 5958), stocké en PEM sous la forme -----BEGIN PRIVATE KEY----- ou, s’il est protégé par mot de passe, -----BEGIN ENCRYPTED PRIVATE KEY-----.
PKCS #12 (PFX)
Le format d’archive protégé par mot de passe de la RFC 7292, généralement enregistré en .p12 ou .pfx, qui regroupe une clé privée et sa chaîne de certificats pour les importer dans les navigateurs, Windows, macOS, Java et Android.
Portefeuille matériel (hardware wallet)
Un appareil dédié qui stocke les clés du portefeuille dans un élément sécurisé ou un microcontrôleur isolé, affiche les détails des transactions sur son propre écran et ne signe qu’après une confirmation physique.
Pré-hachage (HashEdDSA, HashML-DSA)
La signature d’un condensat du message plutôt que du message lui-même, soit implicitement (ECDSA, RSA), soit au moyen de variantes explicitement distinctes et à séparation de domaine, comme Ed25519ph et HashML-DSA.
Problème du nombre caché
Le problème de réseaux euclidiens qui consiste à retrouver un secret à partir de nombreuses relations linéaires bruitées révélant quelques-uns de ses bits ; il transforme de petits biais ou de petites fuites dans les nonces ECDSA et DSA en récupération complète de la clé privée.
Protection contre le repli (downgrade)
Les mécanismes qui empêchent un attaquant de contraindre deux parties prenant en charge une version du protocole ou un algorithme robuste à se rabattre sur une version ou un algorithme plus faible, comme la valeur sentinelle de TLS 1.3 dans ServerHello.random.
Provenance de build
Un enregistrement signé et vérifiable de la façon dont un artefact a été produit (dépôt source et commit, plateforme de build, workflow et entrées), qui permet aux consommateurs de vérifier qu’un paquet provient de la source et du pipeline attendus.
Provenance npm
La provenance SLSA signée, jointe aux paquets npm publiés depuis une CI prise en charge (en disponibilité générale depuis le 26 septembre 2023), qui relie chaque version d’un paquet à son dépôt source, à son commit et au workflow de build.
PS256
L’algorithme JWS RSASSA-PSS avec SHA-256 et MGF1-SHA-256 (RFC 7518 §3.5), qui utilise les mêmes clés RSA que RS256 avec le remplissage PSS, probabiliste et à sécurité prouvée.
PSBT (transaction partiellement signée)
Le format d’échange de BIP-174 (version 0) et de BIP-370 (version 2) qui transporte une transaction non signée et toutes les données dont les signataires ont besoin, afin que portefeuilles, appareils matériels et coordinateurs puissent signer en étapes distinctes.
Publication de confiance (trusted publishing)
La publication de paquets sur un registre depuis la CI avec des identifiants de courte durée fondés sur OIDC, au lieu d’un jeton d’API à longue durée de vie ; introduite par PyPI en avril 2023, elle est proposée par npm (en disponibilité générale depuis juillet 2025), RubyGems, crates.io et d’autres.

Q

QUIC
Le protocole de transport sur UDP (RFC 9000) qui intègre le handshake TLS 1.3 (RFC 9001), chiffre presque toutes les métadonnées de transport et porte HTTP/3.

R

Récolter maintenant, déchiffrer plus tard
La stratégie qui consiste à enregistrer aujourd’hui du trafic chiffré pour le déchiffrer dès qu’un ordinateur quantique pourra casser son échange de clés ; c’est pour cette raison que l’échange de clés post-quantique est déployé avant même que les ordinateurs quantiques existent.
Récupération de la clé publique ECDSA
Le calcul de la clé publique du signataire à partir d’une signature ECDSA et du condensat du message (SEC 1 §4.1.6), que la signature de messages Ethereum et Bitcoin utilise au lieu de transmettre la clé.
Rejeu DKIM (DKIM replay)
Le renvoi, sans modification, d’un message légitimement signé avec DKIM à de nombreux nouveaux destinataires afin qu’il bénéficie de la réputation du domaine signataire, ce que DKIM ne peut empêcher, car la signature ne couvre pas l’enveloppe SMTP.
Reprise de session TLS
Le rétablissement d’une session TLS à partir des secrets d’une connexion antérieure, qui évite l’authentification par certificat, économise des calculs et peut, en TLS 1.3, transporter des données 0-RTT.
Résistance à l’hameçonnage
Propriété d’une méthode d’authentification qui empêche un site sosie de capturer puis de rejouer les identifiants ; elle est obtenue lorsque l’authentificateur lie cryptographiquement sa réponse à l’origine réelle, comme le font WebAuthn et TLS avec certificat client.
RFC 6979 (ECDSA déterministe)
La spécification de 2013 de Thomas Pornin qui dérive le nonce k de DSA ou d’ECDSA à partir de la clé privée et du condensat du message avec HMAC-DRBG, si bien que la signature ne nécessite aucun générateur de nombres aléatoires.
Rotation des clés
Le remplacement d’une clé cryptographique par une nouvelle, selon un calendrier ou après un incident, sans interrompre la vérification pendant la transition, généralement en publiant côte à côte l’ancienne et la nouvelle clé.
RS256
L’algorithme JWS RSASSA-PKCS1-v1_5 avec SHA-256 (RFC 7518 §3.3), choix historique par défaut des fournisseurs OpenID Connect, dont les signatures sont aussi longues que le module RSA (256 octets pour des clés de 2048 bits).
RSA
Le cryptosystème à clé publique de Rivest, Shamir et Adleman (1977), dont la sécurité repose sur la difficulté de factoriser un grand module n = p·q, et qui sert aux signatures et, historiquement, au transport de clé.
RSA-OAEP
Le chiffrement RSA avec le remplissage OAEP (Optimal Asymmetric Encryption Padding, RFC 8017 §7.1), utilisé dans JWE sous les noms RSA-OAEP (SHA-1) et RSA-OAEP-256 (SHA-256) pour envelopper les clés de contenu, en remplacement du chiffrement PKCS #1 v1.5, qui est attaquable.
RSASSA-PKCS1-v1_5
Le remplissage déterministe de signature RSA de PKCS #1 v1.5 (RFC 8017 §8.2), qui enveloppe le condensat dans une structure ASN.1 DigestInfo complétée par des octets 0xFF ; c’est le RS256 des JWT et la signature RSA la plus courante dans X.509.
RSASSA-PSS
Le schéma de signature RSA probabiliste de PKCS #1 v2.1 et versions ultérieures (RFC 8017 §8.1), qui encode le condensat avec un sel aléatoire et la fonction de masquage MGF1, et dispose d’une preuve de sécurité fine qui manque à PKCS #1 v1.5.

S

S/MIME
La norme de signature et de chiffrement des e-mails par certificats X.509 et CMS (RFC 8551, S/MIME 4.0), intégrée à Outlook, Apple Mail et Thunderbird et encadrée, pour les certificats publics, par les S/MIME Baseline Requirements du CA/Browser Forum.
SAML 2.0
La norme XML d’OASIS (mars 2005) pour l’échange d’assertions signées d’authentification et d’attributs entre un fournisseur d’identité et des fournisseurs de services, qui reste l’épine dorsale de l’authentification unique en entreprise.
SBOM (nomenclature logicielle)
Un inventaire lisible par machine des composants, des versions, des licences et des relations de dépendance d’un logiciel, exprimé principalement en SPDX ou en CycloneDX, qui sert à la gestion des vulnérabilités et à la conformité.
Schémas de signature APK (v1–v4)
Les formats de signature des applications Android : signature JAR v1, signatures du fichier entier v2 (Android 7.0) et v3 (Android 9, rotation des clés) dans l’APK Signing Block, rotation ciblée v3.1 (Android 13) et v4 (Android 11) pour les installations incrémentielles.
SCT (signed certificate timestamp)
La promesse signée d’un journal CT d’inclure un certificat ou un précertificat dans son journal public, transmise aux clients dans le certificat lui-même, dans une extension TLS ou dans une réponse OCSP agrafée.
SD-JWT (divulgation sélective pour les JWT)
Le format de la RFC 9901 (novembre 2025) dans lequel un émetteur signe des condensats salés de claims, et le détenteur ne révèle que les claims choisis en envoyant les divulgations correspondantes, avec, en option, un JWT de key binding.
SD-JWT VC
L’Internet-Draft de l’IETF qui définit un profil de SD-JWT pour les attestations numériques vérifiables, avec le typ dc+sd-jwt, un claim de type d’attestation vct, le statut et la découverte des clés de l’émetteur ; l’un des deux formats d’attestation du portefeuille de l’UE.
SEC 1 ECPrivateKey
La structure de clé privée sur courbe elliptique de SEC 1 et de la RFC 5915, qu’OpenSSL écrit sous la forme -----BEGIN EC PRIVATE KEY----- et qui stocke le scalaire avec, en option, les paramètres de la courbe et le point public.
secp256k1
La courbe elliptique de Koblitz de 256 bits y² = x³ + 7 (SEC 2), choisie par Bitcoin et utilisée aussi par Ethereum et Nostr, pour environ 128 bits de sécurité.
Secure Enclave
Le coprocesseur de sécurité isolé d’Apple, intégré aux puces des iPhone, iPad, Mac et Apple Watch, qui crée des clés non exportables et signe ou déchiffre à l’intérieur de la puce, avec, en option, une autorisation par Face ID, Touch ID ou le code d’accès.
security.txt
Un fichier texte servi sous /.well-known/security.txt (RFC 9116) qui indique aux chercheurs en sécurité comment signaler des failles au propriétaire du site.
Service de métadonnées FIDO (MDS)
Le flux signé de la FIDO Alliance qui publie les déclarations de métadonnées des authentificateurs certifiés (AAGUID, certificats racines d’attestation, capacités et statut de certification) et sert à vérifier l’attestation.
SHA-1
La fonction de hachage de 160 bits de FIPS 180-1 (1995), aujourd’hui cassée en pratique pour les collisions et que le NIST retire de toute protection cryptographique d’ici le 31 décembre 2030.
SHA-2
La famille de fonctions de hachage de FIPS 180-4 (SHA-224, SHA-256, SHA-384, SHA-512, SHA-512/224 et SHA-512/256), conçue par la NSA et publiée en 2001, qui fournit aujourd’hui les fonctions de hachage par défaut presque partout.
SHA-3
La famille de fonctions de hachage fondée sur Keccak et normalisée dans FIPS 202 (2015), construite sur une éponge plutôt que sur Merkle–Damgård : SHA3-224, SHA3-256, SHA3-384, SHA3-512 et les fonctions à sortie extensible SHAKE128 et SHAKE256.
SHA-256
Le membre de 256 bits de la famille SHA-2 (FIPS 180-4), hachage par défaut de TLS, JWT, X.509, Bitcoin et de la plupart des outils d’intégrité des fichiers, avec une résistance de 128 bits aux collisions et de 256 bits à la préimage.
SHAKE128 et SHAKE256
Les fonctions à sortie extensible (XOF) de FIPS 202, qui produisent à partir de l’éponge Keccak une sortie de la longueur demandée, quelle qu’elle soit, avec une sécurité de 128 et de 256 bits respectivement pour des sorties assez longues.
Signature à l’aveugle (blind signing)
Le fait d’approuver une transaction ou un message dont l’appareil de signature ne peut pas afficher le sens (il n’en montre en général qu’un condensat ou les calldata brutes), si bien que le signataire doit faire confiance à l’ordinateur, peut-être compromis, qui l’a préparé.
Signature de code
La signature d’exécutables, de paquets, de scripts ou de micrologiciels, qui permet aux systèmes d’exploitation, aux magasins d’applications et aux utilisateurs de vérifier l’éditeur et de détecter toute altération, au moyen de certificats X.509, de clés de plateforme, d’OpenPGP ou de Sigstore.
Signature des commits Git
La signature des commits et des tags Git avec des clés OpenPGP, SSH (depuis Git 2.34) ou X.509, pour que les plateformes d’hébergement et les relecteurs puissent vérifier qui les a créés ; elle se configure avec gpg.format et user.signingkey.
Signature détachée
Une signature stockée séparément des données qu’elle signe – par exemple un fichier OpenPGP .sig ou .asc, un fichier SSHSIG ou une signature CMS sans contenu encapsulé –, si bien que le fichier d’origine reste inchangé.
Signature numérique
Une valeur calculée à partir d’un message avec une clé privée, que toute personne disposant de la clé publique correspondante peut vérifier, et qui prouve que le message n’a pas été modifié et qu’il a été signé par le détenteur de la clé.
Signature PDF
Une signature numérique intégrée à un fichier PDF (ISO 32000-2) dont le /ByteRange couvre tout sauf la valeur de signature, en général une signature CMS ou CAdES détachée accompagnée de la chaîne de certificats et d’un horodatage.
Signature sans clé (keyless signing)
Le modèle de signature de Sigstore dans lequel le signataire s’authentifie avec une identité OIDC, obtient pour une clé éphémère un certificat valable quelques minutes et s’appuie sur un journal de transparence au lieu de protéger une clé privée de longue durée.
Signature Schnorr
Un schéma de signature fondé sur le logarithme discret (Claus Schnorr, 1989), dont la réponse s = r + e·x est linéaire en la clé, ce qui permet des preuves de sécurité simples, la vérification par lots et des multisignatures natives.
Signature XML (XML-DSig)
Le standard du W3C pour la signature de documents XML (XML Signature Syntax and Processing 1.1, 2013), dans lequel un élément ds:Signature référence les données signées par URI, les canonicalise et signe un bloc SignedInfo de condensats.
Signatures à seuil
Des schémas dans lesquels une clé privée est répartie entre n parties de sorte que t quelconques d’entre elles puissent produire ensemble une signature d’apparence ordinaire, alors qu’un groupe plus restreint n’apprend rien de la clé.
Signatures BLS
Des signatures fondées sur les couplages (Boneh, Lynn et Shacham, 2001), courtes, déterministes et nativement agrégeables, utilisées surtout par le consensus de preuve d’enjeu d’Ethereum sur la courbe BLS12-381.
Signatures composites
Des signatures qui combinent un algorithme post-quantique et un algorithme classique sous une seule clé et un seul identifiant d’algorithme (par exemple ML-DSA-65 avec ECDSA P-256), de sorte qu’une signature n’est valide que si ses deux composantes le sont.
Signatures de messages HTTP
La norme de l’IETF (RFC 9421, février 2024) pour signer des composants choisis d’une requête ou d’une réponse HTTP, la signature étant transportée dans les champs d’en-tête Signature-Input et Signature.
Signatures fondées sur le hachage
Des schémas de signature dont la sécurité ne dépend que des propriétés d’une fonction de hachage, construits à partir de signatures à usage unique et d’arbres de Merkle : LMS et XMSS, avec état (SP 800-208), et SLH-DSA, sans état (FIPS 205).
Signatures hedged
Mode de signature dans lequel le nonce propre à chaque signature est dérivé de la clé privée et du message ainsi que d’un aléa frais, de sorte que le schéma reste sûr si l’un des deux, le générateur de nombres aléatoires ou la dérivation déterministe, est attaqué.
Sigstore
Un service de signature open source qui certifie des clés éphémères pour des identités OIDC (Fulcio) et journalise publiquement les signatures (Rekor), afin que les artefacts puissent être signés et vérifiés sans clé à long terme.
SIWE (Sign-In with Ethereum)
Le format de message ERC-4361 permettant de se connecter avec un compte Ethereum : un texte lisible par un humain comprenant le domaine, l’adresse, l’URI, la version, l’ID de chaîne, le nonce et la date d’émission, signé avec personal_sign.
SLH-DSA (FIPS 205)
L’algorithme de signature numérique sans état fondé sur le hachage (Stateless Hash-Based Digital Signature Algorithm) de FIPS 205 (août 2024), dérivé de SPHINCS+, dont la sécurité ne repose que sur des fonctions de hachage, au prix de signatures de 7,8 à 50 Ko et d’une opération de signature lente.
SLSA (Supply-chain Levels for Software Artifacts)
Un framework de l’OpenSSF composé de niveaux progressifs d’intégrité du build et des sources (par exemple, Build L3 signifie une provenance générée par une plateforme de build durcie et isolée), dont la spécification actuelle est la v1.2 (novembre 2025).
SNI (Server Name Indication)
L’extension TLS (RFC 6066 §3, extension 0) par laquelle le client nomme l’hôte qu’il veut joindre, ce qui permet à une seule adresse IP de servir de nombreux certificats ; elle est envoyée en clair, sauf si Encrypted Client Hello est utilisé.
sntrup761x25519-sha512
L’échange de clés SSH qui combine sntrup761 (Streamlined NTRU Prime) et X25519 et hache le résultat avec SHA-512, par défaut dans OpenSSH de la version 9.0 (2022) jusqu’à son remplacement par mlkem768x25519-sha256 dans la 10.0.
SPF (Sender Policy Framework)
La politique publiée dans le DNS, définie par la RFC 7208, qui liste les hôtes autorisés à envoyer des e-mails avec un domaine dans l’enveloppe SMTP (MAIL FROM ou HELO), et que les destinataires comparent à l’adresse IP qui se connecte.
SSH (Secure Shell)
Le protocole des RFC 4251 à 4254 pour la connexion à distance authentifiée et chiffrée, l’exécution de commandes, le transfert de fichiers et la redirection de ports, dans lequel le serveur prouve son identité avec une clé d’hôte et les utilisateurs s’authentifient avec des clés, des certificats ou des mots de passe.
SSHSIG (signatures SSH)
Le format d’OpenSSH pour signer des données arbitraires avec des clés SSH (ssh-keygen -Y sign), qui lie un espace de noms à chaque signature et sur lequel reposent les commits Git signés avec SSH et la vérification par liste de signataires autorisés (allowed signers).
STARTTLS
Une commande de protocole qui bascule vers TLS une connexion en clair déjà établie, dans SMTP (RFC 3207), IMAP, POP3, LDAP et XMPP, et qui reste exposée au repli si aucune politique n’impose TLS.
SubjectPublicKeyInfo (SPKI)
La structure ASN.1 de la RFC 5280 qui associe un identifiant d’algorithme aux bits de la clé publique, utilisée dans tout certificat X.509 et comme format de fichier standard des clés publiques (-----BEGIN PUBLIC KEY-----).
Suite de chiffrement
Une combinaison nommée d’algorithmes cryptographiques utilisée par une connexion TLS ; en TLS 1.3, elle ne désigne que l’AEAD et la fonction de hachage du handshake (par exemple TLS_AES_128_GCM_SHA256), alors qu’en TLS 1.2 les noms fixaient aussi l’échange de clés et l’authentification.

T

Taproot
Le soft fork de Bitcoin regroupant les BIP 340, 341 et 342, activé au bloc 709 632 le 14 novembre 2021, qui a ajouté les signatures Schnorr et des sorties P2TR qui s’engagent sur une clé et sur un arbre de scripts facultatif.
TLS (sécurité de la couche de transport)
Le protocole de l’IETF qui authentifie un serveur (et, en option, un client) et chiffre le flux d’octets échangé entre eux, utilisé par HTTPS, la messagerie, les API et la plupart des autres protocoles d’Internet ; version actuelle : 1.3.
TLS 1.2
La version de TLS de 2008 (RFC 5246), toujours largement prise en charge, qui a introduit les suites de chiffrement AEAD et SHA-256, mais exige deux allers-retours et autorise des options faibles que TLS 1.3 a supprimées.
TLS 1.3
La version actuelle de TLS, publiée en 2018 sous la RFC 8446 et révisée en 2026 sous la RFC 9846, avec un handshake en un seul aller-retour, une confidentialité persistante obligatoire, des suites de chiffrement exclusivement AEAD et un handshake chiffré.
Toile de confiance (web of trust)
Le modèle de confiance décentralisé d’OpenPGP, dans lequel les utilisateurs certifient mutuellement leurs clés et chacun décide du degré de confiance à accorder aux certificateurs, au lieu de s’en remettre à des autorités de certification.
TUF (The Update Framework)
Une spécification pour des mises à jour logicielles sûres, projet diplômé de la CNCF en 2019, qui répartit la signature entre les rôles root, targets, snapshot et timestamp (horodatage), avec des seuils et des dates d’expiration, pour résister à une compromission de clé.
typ (en-tête JOSE du type)
Le paramètre d’en-tête JOSE qui déclare le type de média du jeton entier, comme JWT, at+jwt, dpop+jwt ou kb+jwt, et sert au typage explicite, pour qu’un type de jeton ne puisse pas être substitué à un autre.

U

Utilisation de la clé (extension Key Usage)
L’extension X.509 (OID 2.5.29.15) dont les bits restreignent ce qu’une clé certifiée peut faire : digitalSignature, contentCommitment, keyEncipherment, keyAgreement, keyCertSign, cRLSign, entre autres.
Utilisation étendue de la clé (EKU)
L’extension X.509 (OID 2.5.29.37) qui énumère les finalités applicatives auxquelles la clé d’un certificat peut servir, comme id-kp-serverAuth, id-kp-clientAuth, id-kp-codeSigning ou id-kp-emailProtection.

V

Validation de domaine (DV)
Le niveau de validation de certificat dans lequel une AC vérifie seulement que le demandeur contrôle les noms de domaine du certificat, par des challenges DNS, HTTP ou TLS-ALPN, sans rien vérifier de l’organisation.
Validation de l’organisation (OV)
Le niveau de validation de certificat dans lequel l’AC vérifie, en plus du contrôle du domaine, l’existence juridique, le nom et l’adresse de l’organisation demandeuse, et les inscrit dans le sujet du certificat.
Validation du chemin de certification
L’algorithme de la RFC 5280 §6 qui détermine si une chaîne allant d’une ancre de confiance à un certificat d’entité finale est valide, en vérifiant les signatures, les périodes de validité, les noms, les contraintes, les politiques et la révocation.
Validation étendue (EV)
Le niveau de validation le plus strict des certificats TLS, défini par les EV Guidelines du CA/Browser Forum, où l’AC vérifie l’existence juridique, physique et opérationnelle de l’organisation et inscrit dans le certificat les détails de son enregistrement.
Vérification de l’utilisateur (UV)
Le contrôle local, par l’authentificateur, de la présence et de l’identité de l’utilisateur autorisé (par biométrie, PIN ou mot de passe de l’appareil), signalé par l’indicateur UV dans les données d’authentificateur WebAuthn.
Vérification de signature
Le contrôle à clé publique qui établit qu’une signature a été produite sur exactement ce message par la clé privée correspondant à une clé publique donnée, avec un algorithme que le vérificateur a choisi à l’avance.
VMC (certificat de marque vérifiée)
Un certificat X.509 qui lie un domaine au logo d’une marque déposée pour BIMI, émis après validation de la marque et de l’identité, et qui porte le logo SVG dans une extension logotype.

W

Web Bot Auth
Une initiative de l’IETF, fondée sur les signatures de messages HTTP (HTTP Message Signatures), qui permet aux clients automatisés, comme les robots d’indexation et les agents d’IA, de signer leurs requêtes avec une clé publiée, afin que les sites web puissent les identifier de façon fiable au lieu de se fier aux chaînes user-agent ou aux plages d’adresses IP.
WebAuthn (authentification web)
L’API de navigateur du W3C (navigator.credentials.create et get avec les options publicKey) par laquelle les sites web enregistrent et utilisent des identifiants à clé publique sur des authentificateurs ; le niveau 3 de WebAuthn est devenu une recommandation du W3C le 25 août 2026.
WKD (Web Key Directory)
Un moyen de publier des clés OpenPGP sur votre propre domaine, sous /.well-known/openpgpkey/, afin que les clients de messagerie puissent récupérer via HTTPS la clé associée à une adresse e-mail (draft-koch-openpgp-webkey-service).

X

X.509
Le format de certificat de l’UIT-T, profilé pour Internet par la RFC 5280, qui lie une clé publique à un nom de sujet et à des extensions sous la signature d’une autorité de certification émettrice.
x5c (en-tête de chaîne de certificats X.509)
L’en-tête JOSE, également membre de JWK, qui transporte une chaîne de certificats X.509 sous forme de tableau de certificats DER encodés en base64 (et non en base64url), le premier contenant la clé de signature.
X25519
La fonction Diffie–Hellman sur Curve25519 définie dans la RFC 7748, avec des clés de 32 octets et un secret partagé de 32 octets, utilisée pour l’échange de clés dans TLS 1.3, SSH, WireGuard, Signal et age.
X25519MLKEM768
Groupe d’échange de clés hybride TLS 1.3 0x11EC (RFC 10024), alliant ML-KEM-768 et X25519, choix post-quantique par défaut des navigateurs, d’OpenSSL et de Go.
XAdES
Le format ETSI des signatures électroniques avancées sur XML (EN 319 132), qui étend XML-DSig avec des propriétés signées, comme l’heure de signature et le condensat du certificat, et avec les niveaux de long terme B-T, B-LT et B-LTA.
XMSS et XMSS^MT
L’eXtended Merkle Signature Scheme (schéma de signature de Merkle étendu) de la RFC 8391 et de la NIST SP 800-208, une signature avec état fondée sur le hachage, construite sur des clés à usage unique WOTS+, avec une variante multi-arbres pour une plus grande capacité de signature.
xpub (clé publique étendue)
Une clé publique étendue BIP-32 (clé publique et code de chaîne) capable de dériver toutes les clés publiques enfants non renforcées et toutes les adresses situées sous elle, utilisée par les portefeuilles en lecture seule et les serveurs de paiement.

#

0-RTT (données anticipées TLS)
La fonctionnalité de TLS 1.3 qui permet à un client reprenant une session d’envoyer des données applicatives dès son premier envoi, chiffrées avec une clé issue d’une session précédente, au prix de la protection contre le rejeu et de la confidentialité persistante pour ces données.

Par thème

Signatures · 52 termes

JOSE et JWT · 39 termes

PKI et certificats · 69 termes

TLS · 65 termes

E-mail · 18 termes

Web3 · 33 termes

Post-quantique · 34 termes

Identité et WebAuthn · 53 termes

Chaîne d’approvisionnement · 30 termes

OpenPGP · 9 termes

Mathématiques · 48 termes