Twój HSM już ma TRNG. Nadal niczego nie potrafi udowodnić.

1. „Mamy prawdziwą losowość” to nie jest argument bezpieczeństwa

Linux już ma /dev/random, getrandom() i instrukcje procesora takie jak RDRAND. Większość HSM-ów, TPM-ów i dostawców chmurowego KMS ma wbudowane własne sprzętowe TRNG. Mówienie inżynierowi bezpieczeństwa „nasza entropia jest prawdziwa” obok tego nie jest wyróżnikiem: ich entropia zwykle też jest prawdziwa.

Prawdziwe pytanie brzmi inaczej: co się stanie, jeśli to jedno źródło okaże się wadliwe, ma tylną furtkę, albo po prostu jest błędne, i skąd ktokolwiek by o tym wiedział? Dual_EC_DRBG był oficjalnym standardem PRNG NIST z podejrzewaną tylną furtką przez lata, zanim ktoś to udowodnił. Jądro Linuksa do dziś nie ufa samemu RDRAND, tylko domieszkowuje go do puli entropii zamiast używać bezpośrednio.

2. Nie zastępuj swojego RNG. Domieszkuj do niego niezależny.

Galactropy nie jest zamiennikiem Twojego HSM-a czy TPM-a. To drugie, fizycznie niezależne źródło entropii: szum radiowy próbkowany sprzętem SDR i kondycjonowany SHA-512, wplatany w pulę już zasilającą generowanie kluczy. To standardowa praktyka łączenia źródeł entropii: dopóki choć jedno z domieszkowanych źródeł jest naprawdę nieprzewidywalne, wynik połączenia też taki jest, niezależnie od tego, co dzieje się z pozostałymi.

3. Niezależność nie wystarczy. Musi być też weryfikowalna.

RNG w HSM-ie czy chmurowym KMS to zamknięta skrzynka: ufasz certyfikatowi dostawcy i niczemu więcej. Każda partia entropii wygenerowana przez węzły Galactropy jest sprawdzana testami Dieharder, ENT i rngtest, łączona w łańcuch podpisami Ed25519 i zakotwiczana w blockchainie Bitcoina przez OpenTimestamps, więc zapisu nie da się po cichu zmienić później, ani nam, ani nikomu innemu.

4. Domieszkowanie zajmuje jedną linijkę

Pobierz surowe bajty z publicznego API i wprowadź je do istniejącej puli entropii przed wyprowadzeniem kluczy:

curl -s "https://galactropy.com/raw?bytes=512" >> /dev/urandom