Zur sicheren Schlüsselgenerierung braucht GPG Zufallsdaten, die bei einem Desktop-System durch Tastatureingaben und Mausbewegungen abgefragt werden. Auf einem Server, zu dem man meist nur über SSH verbunden ist, kann dies zu einem kleinen Problem werden, wenn folgende Meldung während der Schlüsselgenerierung auftaucht:
Es sind nicht genügend Zufallswerte vorhanden. Bitte führen Sie andere Arbeiten durch, damit das Betriebssystem weitere Entropie sammeln kann!
oder auf Englisch
Not enough random bytes available. Please do some other work to give the OS a chance to collect more entropy!
Im Extremfall kann es mehrere Stunden dauern, bis GPG dann endlich fertig wird. Beschleunigen lässt sich dies effektiv über folgende Befehle (Ubuntu oder Debian vorausgesetzt):
aptitude install rng-tools rngd -r /dev/urandom
Nein, nein, nein nein!
Die Meldung hat schon ihren Sinn, und mit deinem „Trick“ benutzt du Pseudo-zufallszahlen, an genau der Stelle, wo man echte Zufallszahlen braucht. Genau so erzeugt man schlechte Schlüssel.
Das einzige was hilft, ist den Rechner irgendwie rumrödeln zu lassen. (Festplattenzugriffe gehen auch statt Mausbewegungen und Tastatureingaben, um mehr Entropie zu erzeugen.) Z.B. mit crashme (Sollte es als Paket geben.)
Es sollte jedem klar sein, dass die Meldung ihre Daseinsberechtigung hat. Aus der rngd-Manpage:
„This daemon feeds data from a random number generator to the kernel’s random number entropy pool, after first checking the data to ensure that it is properly random.“
Aus der urandom-Manpage:
„A read from the /dev/urandom device will not block waiting for more entropy. As a result, if there is not sufficient entropy in the entropy pool, the returned values are theoretically vulnerable to a cryptographic attack on the algorithms used by the driver. Knowledge of how to do this is not available in the current unclassified literature, but it is theoretically possible that such an attack may exist.“
Ich erachte die Kombination aus der vorhandenen Entropie und der lediglich theroetisch existierenden Angriffsmöglichkeit auf die aus /dev/urandom generierten Zufallszahlen für meine „schlechten“ Schlüssel als sicher genug.
Für alle, die auf Nummer Sicher gehen wollen oder generell gewisse Paranoia haben, ist stundenlanges Warten oder dein Vorschlag vielleicht eine Alternative (Hast du crashme als als Entropiequelle bereits getestet? Woher bekommt Crashme echten Zufall?). Eine Warnung für alle, die sich wirklich darauf einlassen wollen (aus der Paketbeschreibung von crashme):
„**WARNING** While Linux has been known to survive days and weeks of crashme, IT IS NOT GUARANTEED THAT YOUR SYSTEM WILL SURVIVE! DO NOT USE THIS PROGRAM UNLESS YOU REALLY WANT TO CRASH YOUR COMPUTER“
Hallo,
vielleicht doch jemand, der weiterhelfen kann.
Es geht um Schlüsselgenerierung mittels GPG auf einem headless.
rngd -r /dev/urandom
wird mit
can’t open /dev/random: Permission denied
quittiert.
Alle sonstigen Hinweise, wie für mehr Entropie gesorgt werden könnte haben keinen Effekt.
Einige behaupten, das hier würde was bringen:
find / -xdev -type f -exec sha256sum {} >/dev/null \; 2>&1
Aber Fehlanzeige! Die Schlüsselgenerierung dauert beharrlich so um die 2 Minuten.
Haben Sie eine Idee?
Grüße,
Sascha
Ich nehme an, Distribution ist Ubuntu? Mal ein „sudo rngd -r /dev/urandom“ probiert?
Pingback: Linksammlung | Eigener Server in 24h