Véletlen számok linux (rng) vagy how-fill
Talán minden Linux-felhasználó ismer olyan pszeudo-eszközfájlokat, mint / dev / véletlen és / dev / urandom. Ezek az eszközök a véletlenszám-generátor (RNG, véletlenszám-generátor) interfésze.
A véletlen számok (ezek egyben kiszámíthatatlan bitkészletek is) nagyon fontosak a kriptográfiában. Ezek a kriptográfiai protokollok alapvető téglái. Ezeknek a számoknak a minősége (egyedülállósága, kiszámíthatatlansága) a TLS-tanúsítványok, SSH és GPG kulcsok, session szimmetrikus TLS-kulcsok stb. A véletlenszerű számok alapul szolgálnak az UUID-ok, a PID-ek, a TCP-szekvencia-számok és még sok más.
Az RNG véletlen számokat generál a Linux kernel entrópiatartalmából származó adatok alapján. A medence kitöltését az RNG is kezeli, és ez a rendszerben véletlenszerű események, például billentyűzet és lemezidőzítések, egérmozgások, megszakítások, hálózati forgalom alapján történik.
Az entrópia medence állandó kapacitása 4096 bit:
A medence méretét nem lehet megváltoztatni, a csepp a kernelben.
Az aktuális adatmennyiség megtekintése a medencében:
Az elérhető entrópia mennyisége folyamatosan változik, a feltöltés és a fogyasztás sebességétől függően.
Valójában a / dev / random és / dev / urandom segítségével a felhasználói térben lévő alkalmazások megkapják a legtöbb véletlen számot \ data.
/ dev / véletlenszerűen a kernel által nyújtott legmagasabb minőségű véletlenszerű adatok forrása. De ugyanakkor blokkolja azt, ami azt jelenti, hogy a / dev / véletlenszerűen leolvasott alkalmazás lefagy az adatok várakozásakor, ha az entrópia pool üres.
Nagyon ajánlott minden hosszú élettartamú kulcs számára, például a TLS-tanúsítványokhoz a / dev / véletlen használatát csak garantálja a véletlen számok minőségét. De a legtöbb alkalmazás, mint az Apache, a Nginx, az sshd és az Isten ssh-keygen, openssl használja / dev / urandom. Itt elvileg világos, hogy Apache, Nginx, sshd nem akar blokkolni, amikor létrehozza a munkamenet kulcsokat. De az a tény, hogy az ssh-keygen és az openssl az alapértelmezett / dev / urandom-t használja, elképesztő. Az openssl esetében megadhatod az eszközt a kulcsok generálásakor (alább egy példa), de az ssh-keygen esetében nem találtam olyan képességet, hogy felülírja a viselkedést.
Általánosságban, függetlenül attól, hogy hol olvassák be az alkalmazásokat, ne engedje, hogy az entrópia medence kiürüljön, majd a / dev / urandom boldog lesz.
A kriptográfiai kulcs előállításához szükséges maganyag mennyisége. Például egy 3072 bites RSA vagy Diffie-Hellman privát kulcs 128 bites kulcskulccsal rendelkezik (kb. 2 ^ 128 műveletet igényel), így a kulcsgenerátor csak 128 bites (16 bájt) dev / véletlenszerű.
Például az openssl csak 2.048 forrásanyagot használ a / dev / véletlenszerűen, hogy 10240 bit RSA kulcshosszat hozzon létre:
A legjobb megoldás a speciális hardver (TPM, Trusted Platform Module) vagy utasításkezelő, például az RDRAND (Intel IvyBridge és Haswell processzorok) használata.
Ellenőrizze az ilyen eszközök jelenlétét a kiszolgálón az rng-tools csomag rngd segédprogramjával
Ha rngd megtalálja a támogatott médiát, akkor szerencsés, és elindíthatja az rngd szolgáltatást. Az én esetemben nem ők)
Az interneten olyan ajánlások találhatók, ahol a / dev / urandom megadását javasolják az rngd entrópiájának forrásaként. Vagyis az mag entrópiájának forrása valójában maga a mag). Ez meglehetősen kétes ötlet, és ezt nem tennék, és nem javasolnám. De a kísérlet kedvéért elvégeztem a teszteket, és az eredmények (amelyek alacsonyabbak) szintén nem nagyon rosszak.
Ennek alapja a HAVAGE algoritmus, amely a számlálókon és a processzorállapotokon alapuló entrópiát generál. A processzorok összetett, többszintű eszköze miatt ugyanazt a kódot mindig különböző időpontokban hajtják végre, és ez nem állandó a HAVAGE algoritmus alapja.
A gyakorlatban ez egy felhasználói tér démon, amely, mint az rngd, kitölti a core entropia medencét a ioctl felületen keresztül / dev / random. míg az entrópia forrása nem szükséges az rngd-nek.
Centos számára a csomag az epel-től kapható.
Telepítés után csak el kell indítania a szolgáltatást. Az alapértelmezett paraméterek mellett a törés megpróbálja megtartani a mag entrópia medencéjét 1024-nél alacsonyabb szinten.
Nélkül rngd és haveged, a parancs (alatta lesz világos, mit csinál):
Nem ér véget egy nap!
rngd / dev / urandom mint entrópia forrása
(amit nem ajánlottam neked)
Teszt (a 3 legrosszabb eredménye):
Itt kell nézni a sikereket. hibák. és a bemeneti csatornára.
Ugyanakkor a processzor felhasználása az rngd eljárással: 57%
Teszt (a 3 legrosszabb eredménye):
Ugyanakkor a CPU CPU kihasználtsága megtörtént: 12%
Nem ajánlott a VM belsejében való használatát, mert van valami hasonló, mint a CPU számlálók nem olyan pontosak (típus kerekítve), és ez befolyásolja az entrópia minőségét.
A lényeg az, hogy a virt-ioRNG-t (qemu-kvm) használják - egy paravirtual eszköz, amely az entrópiát a gazdagépből veszi át. De ez teljesen más történet ...)