Entropy Mixing

Imaginez deux enregistrements du même événement. Leurs noms de fichiers diffèrent, mais le second n’ajoute pas d’inconnue indépendante. De même, les heures d’arrivée des paquets et d’accès au disque peuvent être liées. NIST SP 800-90B prévient qu’on ne peut pas simplement additionner les estimations d’entropie de sources dépendantes. Il faut d’abord établir ce qui reste incertain lorsque l’attaquant connaît aussi les autres entrées. [1]

Un hash est une empreinte calculée à partir de données. Mais si l’attaquant connaît toutes les entrées, il peut calculer le même résultat. Ni un hash long ni une constante publique ajoutée ne les rendent secrètes. RFC 4086 distingue le mélange de l’incertitude disponible de la production déterministe de valeurs supplémentaires. Un mélange bien conçu exploite ce que les sources apportent réellement ; il ne remplace pas l’entropie manquante. [2]

XOR compare des bits : s’ils sont identiques, le résultat vaut zéro ; sinon, un. Ainsi, X XOR X = 0 : combiner une valeur avec sa copie élimine ici toute incertitude. En revanche, si une entrée est uniformément aléatoire et indépendante de l’autre, le résultat reste uniforme. RFC 4086 montre ainsi l’importance des hypothèses. Ce n’est pas une recette pour fabriquer son propre générateur de portefeuille. [2]

Pour évaluer une méthode, demandez-vous d’où viennent ses entrées et ce qu’un attaquant peut leur faire. HKDF, une méthode de dérivation de clés cryptographiques, utilise une entrée auxiliaire appelée salt. Elle n’a pas besoin d’être secrète, mais RFC 5869 suppose son indépendance vis-à-vis des données initiales de la clé et exige que l’application empêche un attaquant de la choisir ou de la modifier. Salt est ici un nom de paramètre. Ni la liste des sources ni un résultat d’apparence aléatoire ne garantissent la sécurité si une source tombe en panne. [4]

NIST SP 800-90B part d’une source de bruit principale. Elle permet de lui ajouter les sorties d’autres sources si l’ensemble passe par une méthode de traitement approuvée, appelée conditioning. Dans ce cadre, aucune entropie supplémentaire n’est toutefois attribuée à ces autres sources. Multiplier les entrées n’augmente donc pas automatiquement la valeur reconnue. Il s’agit d’une règle propre à cette évaluation, pas d’une affirmation selon laquelle les autres sources ne peuvent jamais aider. [1]

La distinction apparaît dans OpenSSL 3.5, une bibliothèque cryptographique que les programmes peuvent utiliser pour le chiffrement et les nombres aléatoires. Sa fonction RAND_add() mélange des données stockées dans un tampon, une zone de mémoire réservée à cet usage. num indique le nombre d’octets lus ; randomness estime leur entropie en octets, de zéro à num. La taille de la zone mémoire ne prouve pas cette estimation. Le générateur par défaut s’initialise normalement et renouvelle son entropie automatiquement depuis les sources système. [3]

L’apport d’entropie fraîche à un générateur se nomme réensemencement, ou reseeding. Ce n’est pas la même chose qu’ajouter des données quelconques. Selon la documentation OpenSSL 3.5, en mode FIPS, qui suit des règles pour les modules cryptographiques, les données fournies par l’application ne sont pas reconnues comme une source d’entropie fiable. Elles sont seulement mélangées comme entrée supplémentaire et ne comptent pas comme un réensemencement complet. Un appel à RAND_add() seul ne prouve donc pas ce renouvellement. [3]

Dans RFC 5869, HKDF répartit le travail entre HKDF-Extract et HKDF-Expand. La première étape concentre l’entropie disponible dans une clé intermédiaire ; la seconde en dérive des données de la longueur demandée. Elle ne recueille pas un nouveau secret indépendant. Le paramètre info peut lier le résultat à son usage, par exemple préciser à quoi doit servir une clé dérivée. Ce contexte ne remplace pas des données initiales de qualité et ne prouve pas la création d’entropie. [4]