Résumé

  • RFC 9923 décrit FNV comme une famille de hachage non cryptographique, rapide et compacte ; elle n'est pas recommandée lorsque la résistance calculatoire aux collisions ou aux préimages est requise.
  • Son modèle de sécurité montre qu'une concentration provoquée dans quelques compartiments peut dégrader recherches et mises à jour, notamment dans une structure susceptible de porter certaines informations de RIB, sans provoquer une panne franche.
  • Le contrôle durable est une procédure mesurée : conserver les paramètres de l'époque active, détecter la concentration, changer de fonction ou d'offset_basis, rehacher l'état, puis vérifier la distribution et la latence obtenues.

Un service peut rester exact et devenir indisponible

Prenons un scénario construit pour lire le RFC, pas le récit d'un incident. Une application de réseau répond à ses sondes. Les données de sa table sont intactes. Une requête finit par trouver le bon élément. Pourtant, quelques compartiments portent des chaînes toujours plus longues ; les mises à jour les plus lentes dépassent leur budget ; les files CPU s'allongent. La moyenne reste présentable parce que la majorité des compartiments ne pose aucun problème.

Une supervision binaire conclurait que le service est disponible. Pour l'opération qui attend derrière une chaîne surchargée, ce verdict ne décrit rien d'utile. Dans une voie de contrôle, un index de cache, une table de symboles ou une structure liée au routage, l'exactitude comporte une échéance. Une réponse juste mais trop tardive peut produire la même conséquence qu'une absence de réponse.

RFC 9923 donne à ce risque une base précise. FNV, pour Fowler/Noll/Vo, a été conçu pour la vitesse, une petite empreinte de code et une bonne dispersion. Le document cite notamment les URL, noms d'hôte, noms de fichiers, textes, adresses IP et adresses MAC. Les chaînes proches les unes des autres constituent justement un domaine où la dispersion de FNV peut être utile. Rien dans la qualification « non cryptographique » n'annule cette valeur.

La qualification borne plutôt la promesse. FNV calcule un index reproductible avec peu de travail. Il ne paie pas le coût nécessaire pour rendre impraticable la recherche d'une collision, d'une première préimage ou d'une seconde préimage. Le RFC déconseille donc FNV lorsque cette difficulté calculatoire est une exigence et, de manière générale, dans un dispositif de sécurité exposé à un adversaire actif capable d'exploiter son faible facteur de travail.

Le résultat ne transporte pas ses conditions de calcul

Le texte porte principalement sur FNV-1a. Le calcul part d'un offset_basis. Pour chaque octet, il applique un XOR avec l'état courant, puis une multiplication par le FNV_Prime correspondant, modulo la largeur choisie. Les largeurs spécifiées sont 32, 64, 128, 256, 512 et 1024 bits. L'expérience opérationnelle ayant montré une meilleure dispersion de petites entrées qu'avec l'ordre FNV-1, FNV-1a est proposé pour l'usage général de la famille.

Une valeur hexadécimale isolée ne dit pas quel objet a été réellement haché. L'ordre des champs, les séparateurs, la normalisation de texte, la longueur, la largeur du résultat et la valeur initiale font partie de l'entrée effective. Deux systèmes peuvent nommer le même enregistrement tout en hachant des octets différents. Ils peuvent aussi obtenir la même valeur sans que cela prouve une identité d'auteur, une provenance, une autorisation ou une égalité sémantique.

L'offset_basis illustre ce besoin de précision. RFC 9923 indique que presque toute valeur non nulle convient dans le cas général, mais que deux calculs fondés sur des valeurs différentes ne sont pas interopérables. Un basis non standard, inconnu d'un attaquant, peut gêner une préparation hors ligne de collisions. Cette protection vaut dans des circonstances limitées ; elle ne transforme pas le paramètre en clé d'authentification. Un acteur qui observe les sorties ou mesure les effets de nombreux essais peut encore apprendre le comportement du tableau.

La représentation des octets devient elle aussi contractuelle. Pour un stockage persistant ou une interopérabilité entre plateformes, le RFC impose une représentation petit-boutiste. Des processus partageant la mémoire sur des processeurs compatibles peuvent employer de façon cohérente leur ordre naturel. En revanche, une fonction qui renvoie un entier sur une machine gros-boutiste peut apparaître inversée face au vecteur d'octets normalisé. Un échec de comparaison peut donc appartenir à la couche de représentation, pas à celle de l'objet.

La collision n'est pas encore l'attaque

Le modèle de la section sécurité est volontairement dépouillé. Une table comporte n compartiments. L'élément i est placé selon hash(i) mod n, puis les éléments qui partagent un compartiment sont chaînés. Une table de symboles de compilateur ou certaines informations d'une Routing Information Base dans un routeur pourraient employer cette organisation. Quand une chaîne devient longue, lire ou modifier l'un de ses éléments demande davantage de temps.

Une collision n'établit aucune intention hostile. Un espace de sortie fini contient nécessairement des répétitions, et la réduction modulo le nombre de compartiments ajoute des convergences. Un facteur de charge trop élevé, un dimensionnement insuffisant, une population légitime asymétrique ou un défaut de redimensionnement peuvent créer le même symptôme. L'exploitation doit connaître la forme normale de sa propre table avant de qualifier l'écart.

Le cas offensif apparaît lorsque la source contrôle assez les entrées pour façonner la distribution. Si la fonction, le basis et la règle de compartiment sont connus, un adversaire peut tester des candidats hors ligne et réunir des valeurs distinctes qui aboutissent au même index. Il envoie ensuite cet ensemble et concentre le coût sans devoir explorer le service en direct. Cacher le basis peut bloquer ce calcul préalable si l'adversaire n'observe ni résultat ni effet.

Une boucle d'observation rend cette défense moins solide. L'acteur qui soumet de nombreuses entrées variables et voit lesquelles provoquent une dégradation peut accumuler des groupes de collisions au fil des essais. RFC 9923 souligne que ce mécanisme adaptatif peut exister même avec une fonction cryptographique. Celle-ci rend la construction directe beaucoup plus difficile ; elle ne supprime pas l'apprentissage par interaction avec une table finie.

Le mot d'ordre « garder la graine secrète » ne suffit donc pas. Le RFC décrit une réponse qui consiste à détecter un nombre excessif de collisions, changer la fonction de hachage ou l'un de ses paramètres, rehacher les éléments déjà présents, puis poursuivre avec la nouvelle configuration. Pour FNV, changer d'offset_basis est un exemple. Le texte précise que des routeurs déployés commercialement recourent à cette technique pour atténuer des collisions internes excessives, sans identifier de constructeur. Cette phrase ne permet aucune attribution plus précise.

Changer de basis ouvre une nouvelle époque

Le paramètre ne change pas seul. Chaque élément que le service doit encore retrouver a désormais une autre destination. Soit tous les éléments migrent, soit la voie de lecture sait consulter deux époques pendant la transition. Les écritures concurrentes ont besoin d'une destination définie. La date à laquelle la nouvelle table devient autoritative doit être explicite. La mémoire, le CPU et les files doivent pouvoir absorber la reconstruction.

Un retour arrière pose les mêmes questions dans l'autre sens. Les éléments créés après le début du basculement peuvent n'exister que dans la nouvelle table. Sans double écriture, journal de migration ou point d'eau, revenir à l'ancien basis les rend invisibles. Les suppressions, doublons, reprises après erreur et lectures concurrentes doivent être exercés avant qu'un adversaire ne choisisse le moment du test.

La difficulté augmente lorsque la valeur FNV sort du processus. Inscrite dans un format de fichier, utilisée comme identifiant stable, transmise par API ou comparée par un pair, elle transporte une dépendance à la largeur, au basis, à l'ordre des champs et à l'endianness. Un changement destiné à sauver une table locale devient alors une migration d'interopérabilité. Le rétablissement ne doit pas altérer silencieusement le sens externe.

Un reçu de reprise après collision relie les deux époques. Avant l'action, il conserve les octets d'entrée, la variante FNV, la largeur, le prime, l'offset_basis, la représentation, la taille de table et la règle de placement. Il ajoute la distribution d'occupation, le nombre de collisions, le facteur de charge, les distributions de latence en lecture et en mise à jour, l'état CPU et file, la fenêtre d'observation, la population d'entrées et la règle qui a déclenché la déclaration.

Pour l'époque suivante, il enregistre la fonction ou le basis retenu, la version de l'implémentation, les heures de début et de fin, le traitement des opérations concurrentes, le nombre d'éléments déplacés, le pont de compatibilité, le point de retour et tout état non migré. Les mêmes mesures sont reprises après basculement. La fin d'un programme de rehachage ne prouve pas la reprise si les données ne sont plus joignables ou si la latence n'a pas retrouvé son budget.

Le reçu doit aussi dire ce qu'il ne conclut pas. Une égalité FNV n'authentifie pas une personne, ne prouve pas l'origine, n'autorise pas une route, ne protège pas contre l'altération et ne garantit pas l'égalité de deux objets métier. Chacune de ces propositions exige sa propre preuve. La meilleure façon de conserver FNV est de ne pas lui demander davantage que son rôle d'index.

Les références normatives gardent un objet limité

FNV apparaît dans des RFC Standards Track sans que son rôle s'élargisse. RFC 7357 fournit un exemple où FNV-32 aide un RBridge TRILL d'entrée à choisir pseudo-aléatoirement un RBridge de sortie parmi plusieurs candidats. Des équipements d'entrée différents n'ont même pas besoin d'utiliser la même fonction. Il s'agit de répartir un choix, pas d'authentifier la destination.

RFC 7873 propose comme exemple simple un DNS Client Cookie calculé à partir des adresses du client et du serveur et d'un secret client avec FNV64. Il présente aussi une construction plus coûteuse avec HMAC-SHA256. Les DNS Cookies apportent une protection limitée face à certains attaquants hors chemin ; ils ne remplacent ni l'authentification d'origine de DNSSEC ni la sécurité générale des transactions. Le secret, les entrées, les contrôles de protocole et le modèle de menace forment la propriété utile.

RFC 6234 donne le contraste cryptographique. Les Secure Hash Algorithms visent à rendre impraticable la recherche d'une préimage ou de deux messages produisant le même condensat, et participent aux signatures, aux HMAC et à la dérivation de clés. Cela ne commande pas d'employer une fonction cryptographique pour tout index. Cela commande de définir d'abord la propriété à protéger.

Le statut de RFC 9923 doit être lu avec la même rigueur. C'est une Independent Submission Informational, ni Standards Track ni expression du consensus IETF. RFC 7841 explique que le stream et le statut signalent l'origine et le type de revue, et qu'un numéro RFC ne certifie pas l'aptitude au déploiement. L'inverse serait tout aussi faux : un autre chemin de publication n'efface pas les mécanismes documentés. Il oblige le lecteur à les vérifier dans leur périmètre.

Running-Code Primacy prend ici une forme très concrète. Le document publie l'algorithme, les constantes, la représentation et les limites. L'opérateur mesure la table, teste son hypothèse de menace et exécute la reprise. La publication appartient à la couche documentaire ; le comportement du système en marche appartient à la couche décisive.

Sources