Code d'authentification de message (MAC).

Un Message Authentication Code (MAC) est un tag de longueur fixe calculé sur un message à l'aide d'une clé secrète symétrique, de sorte que sa vérification nécessite la même clé. Il fournit intégrité et authenticité, mais pas la non-répudiation, car les deux parties détiennent la clé. Les constructions courantes incluent HMAC (basé sur le hash, RFC 2104), CMAC (CBC-MAC, NIST SP 800-38B), GMAC (utilisé dans GCM), Poly1305 (combiné à ChaCha20 dans ChaCha20-Poly1305, RFC 8439) et KMAC (bâti sur Keccak/SHA-3, NIST SP 800-185).

Si HMAC existe plutôt qu'un naïf MAC = H(key ‖ message), c'est parce que les hachages de type Merkle–Damgård tels que MD5, SHA-1 et SHA-256 sont vulnérables aux attaques par extension de longueur : un attaquant qui connaît un tag valide peut ajouter des données et calculer un tag valide pour le message allongé sans la clé. La structure imbriquée H(key ⊕ opad ‖ H(key ⊕ ipad ‖ msg)) de HMAC déjoue cette attaque et bénéficie d'une preuve de sécurité formelle.

Les MAC doivent être vérifiés en temps constant — comparer les tags octet par octet avec retour anticipé divulgue leur longueur par le biais du temps de réponse, ce qui a permis la falsification de 2009 contre Keyczar. Ils sont au cœur de l'authentification des enregistrements TLS, d'IPsec AH, de JWT HS256, de la signature de requêtes API et de tous les modes AEAD. Un MAC calculé sur le texte chiffré (encrypt-then-MAC) est préférable au MAC-then-encrypt, qui a contribué aux attaques par oracle de remplissage comme Lucky Thirteen.

flowchart LR
  subgraph Expéditeur
    M1[Message] --> T1["MAC(key, message)"]
    K1[Clé secrète partagée] --> T1
    T1 --> S[Envoyer message + tag]
  end
  subgraph Destinataire
    S --> R["Recalculer MAC(key, message)"]
    K2[Clé secrète partagée] --> R
    R --> C{"Comparaison en temps constant<br/>avec le tag reçu"}
    C -->|Égal| OK[Accepter : authentique et intact]
    C -->|Différent| NO[Rejeter : falsifié ou altéré]
  end