Entropy Mixing — це спільна обробка генератором кількох вхідних даних. Метою може бути використання невизначеності різних джерел замість залежності лише від одного. Але додаткові дані не дорівнюють додатковій ентропії: копія відомої інформації не додає нового секрету. Безпека залежить від конкретних джерел і перевіреного способу їх поєднання.
Уявіть два записи однієї події. Назви файлів різні, але другий запис не додає незалежної невідомої. Так само можуть бути пов’язані час надходження пакетів і час доступу до диска. NIST SP 800-90B застерігає: оцінки ентропії залежних джерел не можна просто додавати. Спершу треба з’ясувати, що залишається невизначеним, коли нападник знає й решту входів. [1]
Хеш — це обчислений відбиток даних. Проте якщо нападник знає всі входи, він обчислить той самий результат. Ані довгий хеш, ані додана публічна константа не зроблять дані таємними. RFC 4086 розрізняє змішування наявної невизначеності й детерміноване створення подальших значень. Правильно спроєктоване змішування використовує те, що джерела справді дають; воно не замінює відсутню ентропію. [2]
XOR порівнює біти: однакові дають нуль, різні — одиницю. Тому X XOR X = 0: поєднання значення з його копією тут прибирає всю невизначеність. Якщо ж один вхід рівномірно випадковий і незалежний від іншого, результат залишається рівномірним. Так RFC 4086 показує важливість передумов. Це не інструкція для саморобного генератора гаманця. [2]
Оцінюючи конкретне рішення, запитайте, звідки надходять входи й що нападник може з ними зробити. HKDF, метод виведення криптографічних ключів, використовує допоміжний вхід salt. Він не обов’язково має бути таємним, але RFC 5869 передбачає його незалежність від початкових даних ключа та вимагає, щоб застосунок не дозволяв нападнику його вибрати чи змінити. Salt тут є назвою параметра. Перелік джерел або випадковий вигляд результату самі по собі не гарантують безпеки при відмові джерела. [4]
NIST SP 800-90B виходить з основного джерела шуму. До його даних можна приєднати результати інших джерел, якщо вони разом проходять схвалену обробку, що називається conditioning. Проте в цьому режимі додаткова ентропія їм не зараховується. Більше входів не означає автоматичного збільшення визнаної величини. Це правило конкретної оцінки, а не твердження, що інші джерела ніколи не допомагають. [1]
Різницю видно в OpenSSL 3.5 — криптографічній бібліотеці, яку програми можуть використовувати для шифрування й випадкових чисел. Функція RAND_add() домішує дані з буфера, тобто відведеної ділянки пам’яті. num визначає кількість байтів для читання; randomness оцінює їхню ентропію в байтах від нуля до num. Розмір ділянки пам’яті не підтверджує цю оцінку. Типовий генератор зазвичай сам ініціалізується й автоматично поповнює ентропію із системних джерел. [3]
Поповнення генератора свіжою ентропією називають reseeding. Це відрізняється від додавання довільних даних. За документацією OpenSSL 3.5, у режимі FIPS, який дотримується правил для криптографічних модулів, дані застосунку не визнаються довіреним джерелом ентропії. Їх лише домішують як додатковий вхід і не зараховують як повний reseed. Сам виклик RAND_add() тому не доводить такого оновлення. [3]
HKDF з RFC 5869 ділить роботу на HKDF-Extract і HKDF-Expand. Перший крок зосереджує доступну ентропію входу в проміжному ключі, другий виводить із нього дані потрібної довжини. Новий незалежний секрет при цьому не отримується. Параметр info дозволяє пов’язати результат із використанням, наприклад указати призначення виведеного ключа. Такий контекст не замінює якісних початкових даних і не доводить появи ентропії. [4]
Для повної картини прочитайте також Cryptographic Entropy, CSPRNG, True Random Number Generator, Seed Generation. На цю статтю також посилаються Dice Roll Entropy, True Random Number Generator.