Résumé

  • La RFC 9106 décrit Argon2 1.3, ses entrées, ses paramètres, une méthode de choix et des vecteurs de test ; elle ne certifie aucune flotte d’authentification.
  • La preuve exploitable associe le tuple stocké à la latence, à la mémoire réelle, à la concurrence, aux files d’attente, à la politique de surcharge et à la progression de la migration.

À faible trafic, une vérification Argon2id paraît rassurante : sel unique, 64 Mio, trois passes, quatre lanes, résultat correct. Une heure plus tard, une vague légitime de connexions empile les mêmes appels. La question n’est plus de savoir si un calcul aboutit, mais combien peuvent coexister avant que la mémoire, la bande passante ou le délai ne cèdent.

La RFC 9106 place elle-même cette question au cœur du choix. Elle demande la mémoire abordable par appel, puis le temps abordable par appel. Elle propose de varier t et, si une seule passe dépasse déjà la limite, de réduire m. Le coût défensif est donc une décision prise dans une enveloppe de service, pas un chiffre sacré détaché de la machine.

Cette enveloppe est liée au calcul. Le mot de passe, le sel, le nombre de lanes p, la longueur du tag, la mémoire m, les passes t, la version et le type entrent dans le hachage initial. Argon2 organise des blocs de 1 Kio en lanes indépendantes mais synchronisées. Les segments d’une même tranche peuvent être calculés en parallèle, puis les lanes se rejoignent. Des passes supplémentaires reparcourent la matrice. Dire seulement « Argon2id » masque donc l’essentiel du coût.

Le sel recommandé est long de 16 octets et distinct pour chaque mot de passe. Il empêche deux secrets identiques de partager une cible pré-calculée commune. Il n’est ni une clé secrète ni un substitut à la mémoire. Pour rejouer correctement une vérification et la faire évoluer, il faut conserver le schéma, la version et le facteur de coût avec chaque enregistrement.

Les deux recommandations uniformes rendent le compromis visible. La première emploie 2 Gio, une passe et quatre lanes. La seconde, destinée aux environnements contraints en mémoire, emploie 64 Mio, trois passes et quatre lanes. La RFC présente aussi des exemples chronométrés sur un processeur 2 GHz. Ils décrivent une hypothèse précise, pas le comportement d’un conteneur, d’une VM, d’un allocateur ou d’un nœud soumis à d’autres tâches.

Les vecteurs de test répondent à une autre question. Avec des entrées fixes — par exemple 32 Kio, trois passes et quatre lanes — ils permettent de reproduire des blocs intermédiaires et le tag final. C’est une preuve de conformité arithmétique. Elle ne mesure ni le p99, ni le pic de mémoire résidente, ni l’annulation, l’effacement, la contention ou le refus d’allocation.

Sous concurrence, une multiplication simple entre mémoire configurée et appels actifs donne seulement une borne de planification. L’empreinte réelle dépend de la bibliothèque, de l’allocateur, du recyclage, du NUMA, du CPU et surtout de la bande passante mémoire. Il faut observer le système. Il faut aussi écrire la règle de surcharge : mise en file, rejet, limitation, délai, délestage ou fermeture sûre. Un repli discret vers un paramètre moins coûteux changerait la promesse de sécurité ; laisser le processus s’épuiser transformerait une défense en outil de déni de service.

La migration est un second test de réalité. Le NIST demande de conserver l’algorithme et le facteur de coût par mot de passe afin de pouvoir les relever avec le temps. Cette structure rend la migration possible. Elle ne prouve pas que les comptes inactifs, les chemins de récupération ou les échecs de réhachage ont quitté l’ancien réglage. La métrique honnête est une distribution des tuples encore vivants.

Même une mesure parfaite du vérificateur ne fixe pas le prix d’une attaque. La qualité des mots de passe, la portée d’une fuite, le matériel et l’énergie de l’adversaire, la présence d’une clé secrète et la limitation en ligne restent inconnues. La RFC est d’ailleurs un document informatif de l’IRTF, pas une spécification Standards Track. Elle fournit une fonction et une analyse ; elle n’a pas observé le service qui souhaite s’en réclamer.

L’article BTW sur la RFC 9807 reste voisin sans être identique. OPAQUE place la KSF côté client et analyse l’invisibilité du mot de passe, la garde de la racine OPRF et la réinscription. Ici, le sujet est le vérificateur serveur ordinaire : mémoire, passes, lanes, appels simultanés, migration de la population et comportement à saturation.

Le reçu à conserver comprend donc type et version, politique de sel, m, t, p, longueur du tag et secret optionnel ; bibliothèque et classe matérielle ; percentiles à chaud et à froid ; pics mémoire par appel et par processus ; concurrence active ; âge de la file ; refus, délais et annulations ; pression CPU et mémoire ; distribution des anciens paramètres ; résultats de réhachage ; limitation et récupération. Le succès d’un appel n’est que la première ligne.

Sources

Spécification et statut : RFC 9106, fiche RFC Editor, fiche Datatracker et article Argon2. Historique : Password Hashing Competition. Exigences de vérification : guide NIST sur les authentificateurs et analyse NIST des mots de passe. Frontière voisine : RFC 9807. Cadre analytique : Minimum Initial Specification, Reality Layers et Running-Code Primacy.