Entropy Mixing

Wyobraź sobie dwa zapisy tego samego zdarzenia. Mają różne nazwy plików, ale drugi nie dodaje niezależnej niewiadomej. Podobnie mogą być powiązane czasy nadejścia pakietów i dostępów do dysku. NIST SP 800-90B ostrzega, że oszacowań entropii zależnych źródeł nie można po prostu dodawać. Najpierw trzeba ustalić, co pozostaje niepewne, gdy atakujący zna również pozostałe wejścia. [1]

Hash to obliczony odcisk danych. Jeśli jednak atakujący zna wszystkie wejścia, obliczy ten sam wynik. Ani długi hash, ani dodana publiczna stała nie zrobią z tych danych sekretu. RFC 4086 odróżnia mieszanie dostępnej niepewności od deterministycznego wytwarzania kolejnych wartości. Dobrze zaprojektowane mieszanie wykorzystuje to, co źródła rzeczywiście dostarczają; nie zastąpi brakującej entropii. [2]

XOR porównuje bity: jednakowe dają zero, różne jedynkę. Dlatego X XOR X = 0 — połączenie wartości z jej kopią usuwa tu całą niepewność. Jeśli natomiast jedno wejście jest jednostajnie losowe i niezależne od drugiego, wynik pozostaje jednostajny. RFC 4086 pokazuje w ten sposób znaczenie założeń. Nie jest to instrukcja budowy własnego generatora do portfela. [2]

Oceniając rozwiązanie, zapytaj, skąd pochodzą wejścia i co może z nimi zrobić atakujący. HKDF, metoda wyprowadzania kluczy kryptograficznych, używa pomocniczego wejścia o nazwie salt. Nie musi ono być tajne, ale RFC 5869 zakłada jego niezależność od danych początkowych klucza i wymaga, aby aplikacja uniemożliwiała atakującemu jego wybór lub zmianę. Salt jest tu nazwą parametru. Lista źródeł ani losowo wyglądający wynik nie gwarantują bezpieczeństwa, gdy jedno ze źródeł zawiedzie. [4]

NIST SP 800-90B przyjmuje główne źródło szumu. Pozwala dołączyć do jego danych wyniki innych źródeł, jeżeli całość przechodzi przez zatwierdzony sposób przetwarzania, zwany conditioning. W tym trybie nie przyznaje jednak tym źródłom dodatkowej entropii. Więcej wejść nie zwiększa więc automatycznie uznanej wartości. To reguła konkretnej oceny, a nie twierdzenie, że pozostałe źródła nigdy nie pomagają. [1]

Różnicę widać w OpenSSL 3.5, bibliotece kryptograficznej, z której programy mogą korzystać między innymi do szyfrowania i generowania liczb losowych. Funkcja RAND_add() miesza dane z bufora, czyli przeznaczonego na nie obszaru pamięci. num określa liczbę odczytywanych bajtów, a randomness szacuje ich entropię w bajtach od zera do num. Wielkość obszaru pamięci nie dowodzi poprawności tego szacunku. Domyślny generator zwykle sam się inicjalizuje i automatycznie uzupełnia entropię ze źródeł systemowych. [3]

Dostarczenie generatorowi świeżej entropii nazywa się reseedingiem. To coś innego niż dodanie dowolnych danych. Dokumentacja OpenSSL 3.5 wyjaśnia, że w trybie FIPS, działającym według reguł dla modułów kryptograficznych, dane aplikacji nie są uznawane za zaufane źródło entropii. Miesza się je tylko jako dodatkowe wejście i nie zalicza jako pełny reseed. Samo wywołanie RAND_add() nie dowodzi więc takiego odnowienia. [3]

HKDF opisany w RFC 5869 dzieli pracę na HKDF-Extract i HKDF-Expand. Pierwszy krok skupia dostępną entropię wejścia w kluczu pośrednim, drugi wyprowadza z niego dane wymaganej długości. Nie pozyskuje w ten sposób kolejnego niezależnego sekretu. Parametr info pozwala powiązać wynik z jego zastosowaniem, na przykład wskazać przeznaczenie wyprowadzanego klucza. Taki kontekst nie zastępuje dobrych danych początkowych ani nie dowodzi powstania entropii. [4]