Le mélange d’entropie transforme plusieurs entrées en un état ou résultat commun. Il faut distinguer données fournies, entropie démontrée et expansion déterministe ultérieure. Deux noms d’interfaces ne représentent pas nécessairement deux sources indépendantes.
NIST SP 800-90B souligne que l’entropie conjointe de sources dépendantes peut être difficile à estimer. Les instants d’arrivée des paquets et d’accès au disque peuvent être liés. Leurs estimations séparées ne s’additionnent donc pas sans modèle documenté. [NIST SP 800-90B — Additional noise sources]
RFC 4086 utilise XOR comme exemple simple de mélange. Une entrée uniforme indépendante conserve l’uniformité du résultat, mais une copie de la même entrée donne X XOR X = 0. Cela illustre la dépendance, sans constituer une recette de portefeuille. [RFC 4086 — Mixing and randomness requirements]
Un mélange robuste peut concentrer l’incertitude disponible ; le hachage déterministe d’entrées connues reste prévisible. RFC 4086 distingue mélange et expansion. La longueur du résultat et l’ajout d’une constante connue ne démontrent pas une quantité équivalente d’entropie nouvelle. [RFC 4086 — Mixing and randomness requirements]
NIST SP 800-90B autorise la concaténation de bruits supplémentaires avec la source principale via un conditionnement approuvé, sans leur créditer d’entropie supplémentaire dans ce cadre. C’est une règle d’évaluation, pas l’affirmation que d’autres sources ne peuvent jamais aider. [NIST SP 800-90B — Additional noise sources]
Dans OpenSSL 3.5, RAND_add() mélange num octets ; randomness estime l’entropie en octets entre zéro et num. La longueur du tampon ne justifie pas cette estimation. Le générateur par défaut s’initialise et se réensemence normalement automatiquement depuis les sources système. [OpenSSL 3.5 — RAND_add and FIPS reseeding]
La documentation OpenSSL 3.5 précise qu’en mode FIPS les données applicatives sont seulement une entrée supplémentaire, pas une source d’entropie fiable. Leur mélange ne constitue pas un réensemencement complet. Un appel à RAND_add() seul ne démontre donc pas ce renouvellement. [OpenSSL 3.5 — RAND_add and FIPS reseeding]
RFC 5869 distingue HKDF-Extract et HKDF-Expand. Le premier concentre l’entropie d’entrée ; le second dérive la longueur demandée. Le paramètre info lie le résultat au contexte applicatif ; il ne remplace pas un bon matériau initial et ne prouve pas une entropie nouvelle. [RFC 5869 — HKDF extraction, expansion and independence]
Une revue doit identifier origine des entrées, dépendances, capacités de l’attaquant et mécanisme concret. RFC 5869 traite explicitement l’indépendance et la manipulation du sel. Une liste de sources ou un test d’apparence aléatoire ne prouve pas la sécurité après défaillance d’une source. [RFC 5869 — HKDF extraction, expansion and independence]
Pour une vision complète, lisez aussi Cryptographic Entropy, CSPRNG, True Random Number Generator, Seed Generation. Cette entrée est également citée par Dice Roll Entropy, True Random Number Generator.