Haveged: Unterschied zwischen den Versionen
Zeile 1: | Zeile 1: | ||
'''topic''' - Kurzbeschreibung | '''topic''' - Kurzbeschreibung | ||
== Beschreibung == | == Beschreibung == | ||
= TMP = | |||
; Zufallszahlen sind gerade in der modernen Kommunikation ein wichtiger Faktor | |||
* werden unbedingt für die Kryptographie benötigt | |||
; Erzeugung von Zufallszahlen | |||
* dedizierten Hardware | |||
* "zufällige" Ereignisse wie Interrupts z.B. weil der Mauszeiger sich bewegt | |||
; Verbrauch von Zufallszahlen | |||
* wenn Kryptographie-Schlüssel erzeugt werden | |||
* Inzwischen verbraucht aber auch jeder Prozeßstart 16 Bit Zufall, weil die glibc dies aus /dev/random liest | |||
;: Wenn zu wenig Zufall vorhanden ist | |||
* die Entropie also gering ist, warten diese Prozesse, bis wieder Zufallsbit aus /dev/random zur Verfügung stehen | |||
* Es kommt also zu einer schlechteren Performance, Prozesse benötigen länger zum Starten, kryptographische Vorgänge dauern länger | |||
; Server sehen wenige echte Zufallsquellen zur Verfügung | |||
* Fehlende Benutzerinteraktion | |||
; Virtuelle Maschinen haben es da noch schwerer | |||
; Der Dämon haveged löst dieses Problem | |||
* indem er Zufallszahlen tatsächlich unvorhersagbar zufällig produziert und nicht pseudozufällig wie /dev/urandom | |||
* Er bedient sich dabei Gleichlaufschwankungen moderner CPU-Caches | |||
; Haveged läuft als Dämon | |||
* Überwacht die verfügbare Anzahl von Zufalls-Bit | |||
* Wird ein eingestellter Schwellwert unterschritten, erzeugt haveged neue Zufalls-Bit | |||
; Dies ist sehr effizient und resourcenschonend | |||
* Der Zugewinn durch die höhere Entropie überwiegt | |||
* bei weitem die Last, die haveged zusätzlich auf das System bringt | |||
== Installation == | == Installation == | ||
== Anwendungen == | == Anwendungen == |
Version vom 20. März 2023, 20:05 Uhr
topic - Kurzbeschreibung
Beschreibung
TMP
- Zufallszahlen sind gerade in der modernen Kommunikation ein wichtiger Faktor
- werden unbedingt für die Kryptographie benötigt
- Erzeugung von Zufallszahlen
- dedizierten Hardware
- "zufällige" Ereignisse wie Interrupts z.B. weil der Mauszeiger sich bewegt
- Verbrauch von Zufallszahlen
- wenn Kryptographie-Schlüssel erzeugt werden
- Inzwischen verbraucht aber auch jeder Prozeßstart 16 Bit Zufall, weil die glibc dies aus /dev/random liest
- Wenn zu wenig Zufall vorhanden ist
- die Entropie also gering ist, warten diese Prozesse, bis wieder Zufallsbit aus /dev/random zur Verfügung stehen
- Es kommt also zu einer schlechteren Performance, Prozesse benötigen länger zum Starten, kryptographische Vorgänge dauern länger
- Server sehen wenige echte Zufallsquellen zur Verfügung
- Fehlende Benutzerinteraktion
- Virtuelle Maschinen haben es da noch schwerer
- Der Dämon haveged löst dieses Problem
- indem er Zufallszahlen tatsächlich unvorhersagbar zufällig produziert und nicht pseudozufällig wie /dev/urandom
- Er bedient sich dabei Gleichlaufschwankungen moderner CPU-Caches
- Haveged läuft als Dämon
- Überwacht die verfügbare Anzahl von Zufalls-Bit
- Wird ein eingestellter Schwellwert unterschritten, erzeugt haveged neue Zufalls-Bit
- Dies ist sehr effizient und resourcenschonend
- Der Zugewinn durch die höhere Entropie überwiegt
- bei weitem die Last, die haveged zusätzlich auf das System bringt
Installation
Anwendungen
Fehlerbehebung
Syntax
Optionen
Parameter
Umgebungsvariablen
Exit-Status
Konfiguration
Dateien
Sicherheit
Siehe auch
Dokumentation
RFC
Man-Pages
Info-Pages
Links
Einzelnachweise
Projekt
Weblinks
Testfragen
Testfrage 1
Antwort1
Testfrage 2
Antwort2
Testfrage 3
Antwort3
Testfrage 4
Antwort4
Testfrage 5
Antwort5