Poate că toți utilizatorii Linux cunosc astfel de fișiere pseudo-dispozitiv ca / dev / random și / dev / urandom. Aceste dispozitive sunt interfața cu generatorul de numere aleatoare (RNG, generator de numere aleatoare).
Numerele aleatoare (sunt, de asemenea, un set imprevizibil de biți) sunt foarte importante în criptografie. Acestea sunt cărămizile de bază pentru protocoalele criptografice. Calitatea (unicitatea, imprevizibilitatea) acestor numere depinde de puterea tuturor tipurilor de certificate TLS, tastelor SSH și GPG, tastelor TLS simetrice sesiune etc. De asemenea, numere aleatorii sunt baza pentru generarea UUID, PID, numere de secvență TCP și multe altele.
RNG generează numere aleatorii pe baza datelor din pool-ul de entropie din kernel-ul Linux. Umplerea piscinei este, de asemenea, implicat RNG și acest lucru se face pe baza unor evenimente aleatorii în sistem, cum ar fi unitățile de sincronizare și tastatură, mișcările mouse-ului, (Întreruperi de intreruperi), traficul de rețea.
Piscina de entropie are o capacitate fixă de 4096 de biți:
Mărimea bazinului nu poate fi schimbată, este greșită în kernel.
Vizualizați cantitatea curentă de date din bazin:
Volumul disponibil al entropiei se modifică în mod constant, în funcție de viteza de alimentare și, respectiv, de consum.
De fapt, folosind / dev / random și / dev / urandom, aplicațiile din spațiul utilizatorilor primesc aceste numere aleatoare \ date.
/ dev / random este sursa de date aleatorii de cea mai înaltă calitate pe care le poate furniza kernelul. Dar, în același timp, este blocarea, ceea ce înseamnă că citirea aplicației de la / dev / random se va agăța în așteptarea datelor dacă fondul de entropie este gol.
Este foarte recomandat pentru orice chei lungi, de exemplu, pentru ca certificatele TLS să utilizeze / dev / random din moment ce doar garantează calitatea numerelor aleatoare. Dar, majoritatea aplicațiilor, cum ar fi Apache, Nginx, sshd și despre Dumnezeu ssh-keygen, folosesc / dev / urandom. Aici, în principiu, este clar că Apache, Nginx, sshd nu dorește să blocheze atunci când generează chei de sesiune. Dar faptul că ssh-keygen și openssl utilizează implicit / dev / urandom este uimitor. Și pentru openssl, puteți specifica dispozitivul când generați chei (un exemplu de mai jos), dar pentru ssh-keygen, nu am găsit capacitatea de a suprascrie comportamentul.
În general, indiferent de locul unde aplicațiile dvs. citesc, nu trebuie să permiteți golirea bazinului de entropie, iar apoi / dev / urandom va fi fericit.
Cantitatea de material de semințe necesar pentru a genera o cheie criptografică. De exemplu, o cheie privată 3072-bit RSA sau Diffie-Hellman are o dimensiune cheie eficientă de 128 biți (necesită aproximativ 2 ^ 128 operații pentru a rupe), astfel încât un generator cheie are nevoie doar de 128 biți (16 octeți) de material de semințe de la / dev / aleatoriu.
De exemplu, openssl utilizează numai 2048 de surse din / dev / random pentru a genera o lungime a cheii RSA de 10240 de biți:
Cea mai bună soluție este folosirea unui hardware special (TPM, Trusted Platform Module) sau a unui procesor de instrucțiuni, cum ar fi RDRAND (există procesoare Intel IvyBridge și Haswell).
Verificați prezența unor astfel de dispozitive pe server folosind utilitarul rngd din pachetul rng-tools
Dacă rngd găsește suportul media acceptat, atunci sunteți norocos și puteți începe serviciul rngd. În cazul meu, nu sunt)
Pe Internet, puteți găsi recomandări în care se recomandă specificarea / dev / urandom ca sursă de entropie pentru rngd. Adică, sursa de entropie a nucleului va fi de fapt nucleul în sine). Aceasta este o idee destul de dubioasă și nu aș face acest lucru și nu vă sfătuiesc. Dar, de dragul experimentului, am efectuat teste, iar rezultatele (care sunt mai mici) nu sunt, de asemenea, foarte rele.
Baza este algoritmul HAVAGE, care generează entropie pe baza contoarelor și a procesoarelor. Datorită complexului, dispozitivului multi-nivel al procesoarelor, același cod este întotdeauna executat pentru momente diferite și această constanță nu este baza algoritmului HAVAGE.
În practică, acesta este un daemon pentru spațiul utilizator care, ca și rngd, umple bazinul de entropie de bază prin intermediul interfeței ioctl / dev / random. în timp ce nu are nevoie de sursa de entropie ca rngd.
Pentru centos pachetul este disponibil de la epel.
După instalare, trebuie să porniți serviciul. Cu parametrii impliciți, hasged va încerca să păstreze piscina de entropie de bază la un nivel nu mai mic de 1024.
Fără rngd și hasged, comanda (de mai jos va fi clar ce face):
Nu sa terminat pentru o zi!
rngd cu / dev / urandom ca sursă de entropie
(ceva ce nu ți-am recomandat)
Test (cel mai rău dintre cele 3 rezultate):
Aici trebuie să te uiți la succese. eșecuri. și de viteza canalului de intrare.
În același timp, utilizarea procesorului prin procesul rngd: 57%
Test (cel mai rău dintre cele 3 rezultate):
În același timp, procesul de utilizare a procesului a avut loc: 12%
Nu este recomandat să se folosească hasged în interiorul VM, deoarece există ceva de genul că contoarele procesorului nu sunt la fel de exacte (tip rotunjite), ceea ce afectează calitatea entropiei.
Modul tru este de a folosi virt-ioRNG (qemu-kvm) - un dispozitiv paravirtual care va lua entropia din bazinul gazdă. Dar, aceasta este o poveste complet diferită ...)
Distribuiți acest link:
Trimiteți-le prietenilor: