Presušuje li VPN entropiju? Šta entropy_avail zapravo pokazuje

Nestajanje slučajnosti u jezgru privlačno je objašnjenje za spor VPN i gotovo uvijek pogrešno za simptom koji ljudi prijavljuju. Host koji čeka na slučajni izlaz zastane u određenom trenutku, obično rano pri podizanju ili tokom obrade ključeva. Tunel koji se brzo poveže i zatim sporo prenosi zapravo opisuje propusnost. Razdvojite ta dva zapažanja prije nego instalirate demon da popravite broj koji niste do kraja pročitali.

Zašto mit opstaje

Oba problema su stvarna i izdaleka izgledaju isto. Zastoji pri pokretanju na tek podignutoj virtuelnoj mašini zaista se događaju, a spor uspostavljeni tunel jednako je stvaran. Greška je pretpostaviti da drugi uzrokuje prvi jer se kriptografija pojavljuje negdje u obje priče. Ništa u riječi enkripcija ne implicira da svaki preneseni bajt troši svjež bajt šuma iz okoline.

Ovi generatori ne rade tako. Kriptografska biblioteka drži generator sa sjemenom i crpi izlaz iz njega, ponovo ga zasijavajući po vlastitoj politici, pa je skup trenutak zasijavanje, a ne stalni prenos.

Šta generator radi po paketu

U OpenSSL 3 zadana hijerarhija generatora gradi se od DRBG instanci koje zasijavaju i ponovo zasijavaju prema konfiguraciji i stanju. U OpenVPN 2.6 AEAD putanja podataka izvodi svoj nonce iz rednog broja paketa u kombinaciji s implicitnom vrijednošću po sesiji, dok starija CBC putanja crpi pseudoslučajni IV po paketu. Nijedan obrazac ne podržava pravilo da premještanje gigabajta troši gigabajt svježeg šuma jezgra. Oba podržavaju ideju da su generisanje ključeva i rukovanja mjesto gdje je zasijavanje važno.

Slučaj CBC vrijedi imenovati jer izgleda kao mit a nije: njegov IV po paketu dolazi iz generatora biblioteke po vlastitom rasporedu ponovnog zasijavanja, nikada iz poziva jezgra po paketu. Kada neko navede cijenu entropije po bajtu, pitajte koje su verzije biblioteke i koje kodne putanje mjerili.

Gdje se čekanje zapravo vidi

Postavite vremenske oznake oko faza, a ne oko sesije: pokretanje, provjera identiteta, promjena ključa i prenos. Čekanje prije nego tunel postane upotrebljiv drugačija je žalba od niske stalne brzine, i samo jedna od njih ukazuje na slučajnost. Na Linuxu normalan zahtjev getrandom() može blokirati dok se slučajni izvor jezgra ne inicijalizuje, zato je verzija ovog problema pri podizanju stvarna na virtuelnim mašinama i ugrađenim pločama koje rano imaju malo čime hraniti bazen.

Dvije jeftine komande pripadaju na početak te zbirke i rješavaju laka pitanja prije nego tablica uopće zatreba. Brojač koji čitaju je entropijsko knjigovodstvo, a ne mjerač propusnosti, i jedan snimak ne može pokazati da je proces blokiran, koliko je čekao ni koje sučelje pozivaju njegove bibliotečne funkcije. Uzorak uzet nakon oporavka obično potpuno promaši zastoj, pa držite verziju jezgra uz očitavanje.

cat /proc/sys/kernel/random/entropy_avail
uname -r

Uskladite ispravku s očitavanjem

Ako jezgro zaista čeka inicijalizaciju, gledajte podržanu putanju zasijavanja na platformi, a ne tunel. Virtuelnoj mašini može se dati hostom osiguran slučajni uređaj, poput virtio-rng, a priprema slike je važna jer sjeme kopirano nepromijenjeno u mnoge goste nije neovisna inicijalizacija. Ako biblioteka prijavi neuspjehe zasijavanja nakon podizanja, pregledajte njezin konfigurirani izvor i ponašanje pružatelja umjesto da mijenjate postavke jezgra.

ss -tin dst 203.0.113.7
sar -n DEV 1 5

Dokumentacija OpenSSL generatora opisuje kako ta hijerarhija dobija ulaz i kada se ponovno zasijavanje događa, što je daleko uža tvrdnja od mita i vrijedi samo za tu implementaciju. Entropijski demon nije univerzalna brzinska popravka, a instaliranje da bi brojač porastao mijenja sigurnosnu pretpostavku bez dokazivanja kašnjenja. Za propusnost slijedite putanju podataka: jedna zasićena nit, ponovna slanja, vanjski gubici i odbacivanja redova zahtijevaju svaki svoju ispravku, a veličine međuspremnika rješavaju međuspremanje utičnica s vlastitim dokazima iz redova.