A rövid válasz az, hogy a / dev / random visszacsatolása a / dev / urandom kimenetével nem csökkenti a biztonságot. A dolgok világosabbá tétele érdekében (a megjegyzések azt mutatják, hogy nem voltam elég pontos), az a lényeg, hogy a / dev / random etetjük a / dev / urandom A ártalmatlan (bár nem növeli a biztonságot); ez is meglehetősen haszontalan (kivéve az olyan alkalmazások egyszerű támogatását, amelyek ragaszkodnak a / dev / random használatához és az alkalmatlan időben, minden ok nélkül történő blokkoláshoz.

A dolgok egyszerűsítése érdekében definiáljuk a / dev / random és a /dev/urandom:

• működő modelljét. egy belső állapot p , amely k bájtokból áll (egyes egész számokhoz k).
• További entrópia Az x t úgy injektálják, hogy a p -t helyettesítik a H re ( p , x ), ahol A H egyfajta hash függvény. Például az aktuális állapot összefűzve az új entrópiával, az eredmény kivonatolásra kerül, és a kivonatkimenet az új p.
• A kimenet a p használatával jön létre a CSPRNG bemeneteként; az első k bájtok a p új értéke, az ezt követő bájtok pedig a futás kimenete.
• / dev / random A abban különbözik a / dev / urandom -tól, hogy alkalmanként megtagadja a bájtok kiadását, amíg új entrópiát nem adnak be (vagy nem gyűjtenek a hardverből).

(A fenti egy koncepcionális modell, amely a jelenlegi vita szempontjából elég közel van a tényleges megvalósításhoz.)

Az egész biztonsága a p entrópiájától függ; durván szólva arról, hogy a támadók mennyi p t nem ismerik. A támadók tudják, hogy a p méret k , ezért megpróbálhatják durva erővel kitalálni a p t, amelynek költsége körülbelül 2 ^{8 k -1} átlagosan. A CSPRNG kriptográfiailag biztonságos nak tekinthető, mivel a kimenet sok bájtjának elemzése nem ad információt más kimeneti bájtokról - különösen nem ad információt a p ről (sem a futás előtt vagy után).

Most feltételezzük, hogy az x t a támadó választja. Amíg a H biztonságos hash függvényként viselkedik, a H ( p , x ) ugyanazzal az entrópiával rendelkezik, mint p - a támadónak még mindig nincs információja a p ről a művelet után. Szigorúan véve "tércsökkentő" hatás lehet, kb. 2-es méretig ^{8 k / 2} , ha a támadónak megengedett a 2. "entrópia-adagolás" trükk elvégzése. ^{8 k / 2} alkalommal. Ha a k elég nagy (mondjuk 32, 256 bites belső állapot esetén), a fennmaradó hely mérete még mindig elég nagy a biztonsághoz, és ezt a helyzetet egyébként sem lehet elérni .

Mivel a CSPRNG nem ad információt a p ről, az adott CSPRNG kimenete nem lehet rosszabb a biztonság szempontjából, mint egy támadó által vezérelt x . Ez az a rész, amelyet akadémikus formában legbonyolultabb formalizálni (ennek megfelelő leírása néhány oldalba telik). Intuitív módon a CSPRNG, amikor a bemenet k bájtjait használja, és a kimenet k bájtjait veszi, véletlenszerű orákulumként viselkedik.

Ezért a / dev / random a / dev / urandom kimenetéből nem csökkenti a biztonságot.

Ez természetesen arra az elképzelésre támaszkodik, hogy az állapotfrissítési funkció (entrópia injekcióhoz) és a CSPRNG egyaránt "ideális" funkció. Ha nem, akkor Ön mindenképpen kárhoztatott (a / dev / random automatikus blokkolási viselkedése ebben az esetben nem mentene meg téged).

Sajnos néhányan, akik a / dev / random -ot részesítik előnyben, FIPS és Common Criteria. [SZERKESZTÉS: Nem találok rá hivatkozást, de az alján talál egy nem hivatalos forrást.] Tehát, ha azt szeretné, hogy a szoftvere FIPS / CC tanúsítvánnyal rendelkezzen, akkor nem tudja használni / dev / urandom . Bizonyítania kell , hogy pontos becslést tart az entrópiájáról, és akkor blokkolnia kell , ha az entrópia kevés.

Rövid háttér:

Az összes determinisztikus véletlenszám-generátor csak olyan véletlenszerű, mint a magja. Az entrópia annak becslése, hogy mennyire véletlenszerű (vagy váratlan , vagy kiszámíthatatlan ). Az RNG entrópiájának növelése érdekében be kell keverni egy külső forrásból származó véletlenszerűséget. Ha kiszámíthatatlan adatforrásokhoz van hozzáférése (gyakran az emberi beviteli eszközök időzítése vagy termikus zaj), akkor mindenképpen töltse be a / dev / random fájlba, hogy növelje a magjának entrópiáját.

A Linux kernel automatikusan összekeveri a véletlenszerűség annyi forrását, ahány hozzáféréssel rendelkezik, a csomagok időzítése, a billentyűleütések időzítése, a folyamatütemező véletlenszerűsége, a mellékelt hardveres véletlenszám-generátorok fogyasztói alaplapokon). Tehát ez nagyszerű.

Az egyetlen eset, amiről tudomásom van arról, hogy a / dev / random gyenge-e, a fej nélküli virtuális gépeknél van, ahol a kiszámíthatatlanság miatt szó szerint nincs mit húzni. .

Rendben, térjünk rá a tényleges kérdésre:

Biztos szeretnék lenni abban, hogy egy démon, például rngd vagy haveged a véletlenszerűség visszaállításához a / dev / random -ba - még akkor is, ha a / dev / urandom -ra épülnek, mint például a rngd a legtöbb esetben - nem mutat gyengeségeket.

A kérdésem a következő: honnan veszik véletlenszerűségüket a rngd , a haveged és a / dev / urandom között? Tényleg új véletlenszerűség jön a gépen kívülről, vagy csak a / dev / random újrakeveredése?

Nem tudok beszélni rngd vagy haveged -kal, de tudom, hogy Linux rendszeren a / dev / urandom RNG a / dev / random paranccsal (lásd: ezt a fantasztikus dumálást, amelyből az alábbiakban kölcsönvettem egy képet), és a FreeBSD-n / dev / urandom szó szerint egy mutató vissza a / dev / random -ra, tehát minden valószínűség szerint csak a / dev / random -t táplálja vissza önmagának.

Nem vagyok elég szakértő ahhoz, hogy tudjam, hogy ez gyengeségeket okoz-e vagy sem, de természetesen nem tesz jót.

A "no / dev / urandom" egyetlen említése, amelyet a FIPS dokumentumokban találok, egy 2014-es tervezet volt, amelyet soha nem hoztak nyilvánosság elé. Tartalmazta a lábjegyzetet:

2. megjegyzés: Feltételezzük, hogy a / dev / urandom generátor nem nyújt entrópiát, hacsak nem kifejezetten úgy van kialakítva, hogy mindenkor minimum 112 bites rendelkezésre álló entrópiát biztosítson.

Ezután felsorolja, hogyan garantálhatja ezt az entrópiát. Ez sokkal kevésbé merev, mint amennyire elhittem. Remek, ma megtanultam!

Ne tegyen halat a disznóhús-adatoknak a / dev / random stb. betáplálásával. Ha szeretné, lecserélheti a / dev / random szimbólumot a / dev / urandom linkre

Használhat haveged -t vagy hasonlót, de semmilyen külső bemenet nélkül ne használjon semmit. (Vigyázzon, főleg a havaged esetén is, ha virtualizált hardvert futtat)

/ dev / random meglehetősen robusztus a rossz entrópiával rendelkező bemenet ellen, de ha túl sok hülyeséget táplál, ki tudja mi történik?

/ dev / urandom jól ismert és tesztelt. Ha linkeled a / dev / random-ot, akkor valószínűleg nem lesznek problémáid. Ha rossz dolgokat művel, problémái lehetnek!

Továbbá: Miért szeretne felelősséget vállalni: "Az első biztonságos kapcsolat szerverünkhöz az újraindítás után majdnem egy másodpercet vesz igénybe !!!" / "Generálás sok tanúsítvány lassú "vagy" Az a dolog, amit a véletlenszerű dolgainkkal tettél, teljesen elromlott! Minden kulcsunk elromlott, az összes adatainkat ellopták! MIT TETT? "

Döntsön okosan!