Diskussion:/dev/random

Implementierung abseits Linux

Der Artikel steht unter "Unix" aber die einzige Quelle ist der "Linux Programmer's Guide".

Wie funktioniert /dev/random unter:

• HPUX
• AIX
• Solaris
• FreeBSD
• NetBSD
• OpenBSD
• MacOSX
• OS/400

Wenn es überall gleich implementiert ist, kann man es ja schreiben und eine Quelle angeben.

Und dann gibt es ja noch weitere, z.B. /dev/urandom, das ist auch nicht angesprochen.

Ich finde diesen Einwand unpassend um den Artikel derart zu kennzeichnen. Natürlich muss das nicht überall gleich implementiert sein, schließlich handelt es sich hier um freien Quelltext. Ich denke, es ist auch nicht dringend erforderlich da diverse Distributionen abzuklappern. Das wäre meiner Ansicht nach die einzige "Quelle" um die Information, die Du forderst zu erlangen, was sich allerdings rein theoretisch mit jeder Version ändern könnte.

/dev/random sollte so funktionieren wie im Artikel beschrieben. Ich denke auch nicht, dass da weitere Quellen fehlen. Die Information im Artikel ist also soweit richtig und der Hinweis auf "wichtige" oder "fehlende" Informationen hier fehl am Platz.--85.177.179.203 21:03, 22. Jan. 2008 (CET)

SunOS 5.10, genauso wie beschrieben (quelle: manpage) --80.171.42.111 19:43, 11. Feb. 2008 (CET)

Ist erledigt - habe den Artikel überarbeitet. --Gms 15:11, 14. Sep. 2008 (CEST)

Ist nicht erledigt - Abschnitt 2 bezieht sich rein auf die Linux-Implementierung. Kann man machen, sollte es dann aber auch angeben. Abschnitt 1 ist gut. --2001:638:401:102:250:56FF:FEB2:39C6 10:40, 30. Jul. 2015 (CEST)

Hardware -Zufallszahlen

Ist /dev/random wirklich immer ein Hardware-Zufallszahlengenerator? Soweit ich weiss, ist /dev/random auf jedem Linux-System vorhanden, es wäre mir jeoch neu, wenn alle diese Computer tatsächlich einen Hardware Zufallszahlengenerator eingebaut haben... Ich habe deswegen den Verdacht, dass /dev/random auf 99% aller handelsüblichen Computer KEIN Hardware-Zufallszahlengenerator ist. 88.65.64.144 13:27, 23. Jan. 2008 (CET)

die zufallszahlen werden von der software berechnet. aber auf grundlage von hardware-Interrupts. also tastatur, maus etc. (daher auch die empfehlung beim erstellen von pgp-keys man solle tastatur und maus benutzen damits schneller geht) --80.171.42.111 19:47, 11. Feb. 2008 (CET)

Implemetierung des fast perfekten One-Time-Pad

Ist ja irre, mit ein paar Zeilen Quellcode, lässt sich mit Linux das fast perfekte One-Time-Pad realisieren. Das folgende Programm erzeugt so viele „echte“ Zufallszahlen wie die zu verschlüsselnde Datei (erster und einziger Parameter im Programmaufruf) Zeichen (Bytes) enthält. Die Zufallszahlen werden mit XOR mit den Zeichen der Datei verknüpft und die Zufallszahlen werden in die Datei mit der Endung '.encr' und die verschlüsselten Datens in die Datei mit der zusätzlichen Endung '.enc' geschrieben.

Wird der Quellcode in einer Datei prog.c gespeichert und mit gcc übersetzt, kann etwa mit dem Aufruf

./a.out prog.c

der Quellcode verschlüsselt werden. Auf der Tastatur müssen einige Zufallsanschläge gemacht werden, damit der das Zufallsgerät '/dev/random' genügend Zufallszahlen produziert.

#include <stdio.h>
#include <string.h>

main(int narg, char *argv[]){
	int i,c;
	unsigned char cc;
	int cnt=0;
	FILE *fpdev;
	FILE *fpread;
        FILE *fpenc;
	FILE *fprnd;
	
	fpdev = fopen("/dev/random", "rb");
	
        if (narg == 2){
	  fpread = fopen(argv[1],"r");
          fpenc  = fopen(strcat(argv[1],".enc"), "wb");
          fprnd  = fopen(strcat(argv[1],"r"), "wb");	  
	  while ( (c = fgetc(fpread)) != -1 )
	  {
		cc = fgetc(fpdev);
		fputc(cc ^ (unsigned char)c, fpenc);
		fputc(cc, fprnd);
          }
	  fclose(fpread);
	  fclose(fpenc);  fclose(fprnd);
	  fclose(fpdev);
	}
}

Mit „sha1sum“ kann eine Prüfsumme der Datei erstellt werden und eventuell an die zu verschlüsselnde Datei angehängt werden. Eine gezielte Manipulation der Daten wäre damit praktisch ausgeschlossen. Die Prüfsumme der Datei mit den Zufallszahlen wäre nahezu perfektes Passwort, das ganz bestimmt niemand erraten wird. Mit echten Würfeln, elektronischem Rauschen, radioaktiven Zerfällen oder ähnlichem wäre es jedenfalls garantiert auch nicht sicherer. --84.59.233.108 15:41, 15. Dez. 2008 (CET)

Allerdings muss der Anwender mehr oder minder darauf vertrauen, dass die C-Bibliotheken nicht manipuliert sind. Falls die Zufallszahlen etwa über das Internet übertragen werden, statt nur, wie eigentlich vorgesehen, von dem Programm verarbeitet zu werden, wäre die Sache natürlich unsicher. Dies zeigt, dass die Sicherheit auch bei vorliegendem Quellcode der Anwendung nicht so einfach zu prüfen ist. Hoffnungslos wird die Sache bei einer komplexen Software wie PGP, die in C geschrieben wurde. Wenn eine Stromchiffre wie RC4 mit Java_(Programmiersprache) implementiert wird, sind Manipulationen fast auszuschließen, wenn der Compiler und die Laufzeitumgebung (JRE) direkt von Sun Microsystems heruntergeladen wird. Jetzt könnte allerdings die gesamte Eingabe über die Tastatur abgehört werden. Die doppelte Verschlüsselung mit dem oben beschriebenen Programm und einer Java-Implementierung einer Stromchiffre erreicht einen hohen Grad an Sicherheit. 88.68.115.253 10:39, 16. Dez. 2008 (CET)

spezielle Datei?

Ist nunmehr dieser Axel-Springer-Unfug der "speziellen Datei" (Computerbild) auch in die Wikipedia eingezogen. Wer von einer speziellen Datei spricht, der möge bitte erklären, was das ist, auch, was eine allgemeine und was der Unterschied zu beiden ist. Ich könnte weder das eine noch das andere erklären. Einen ganz bestimmten (speziellen) Zweck erfüllt letzlich jede Datei, mithin ist die Attributierung "speziell" redundant und damit Unfug. (nicht signierter Beitrag von 94.134.16.84 (Diskussion) 13:21, 20. Mär. 2012 (CET))

D' Accord! Die Wahrheit ist, daß /dev/random - wie alles andere auch, was in der /dev-Hierarchie herumschwirrt - ein sogenanntes device file ist: eine Datei, über die ein Treiber (hier der Zufallszahlengenerator) mit den ihn benutzenden Programmen kommuniziert. Unter Unix und derivativen Systemen lautet ein Designprinzip alles ist eine Datei und deshalb ist dieser Weg - Treiber stellt ein device file als Schnittstelle zur Verfügung, das von Anwendungssoftware gelesen (=Ausgabe des Treibers lesen) oder beschrieben (=Nachrichten an den Treiber schicken) werden kann - ziemlich üblich. Auch viele andere Treiber verwenden ihn und stellen entweder ein character-oriented file (random, urandom, Terminal-Emulatoren und ähnliche) oder ein block-oriented file (zB. Festplatten) zur Verfügung. Ich ändere den Artikel dahingehend mal ab.

--bakunin (Diskussion) 12:33, 17. Apr. 2013 (CEST)

spezielle Datei, die zweite

Offenbar wurde die Ersetzung der "speziellen Datei" schmerzlich vermißt, denn Benutzer:Plankton314 ersetzte mein "device file" durch "Gerätedatei". Es stimmt schon, daß "device file" in der deutschen WP auf "Gerätedatei" weiterleitet, aber: /dev/random IST MITNICHTEN EINE GERÄTEDATEI, weil es nämlich kein "Gerät" gibt, das dieser Datei entsprechen würde! Ich habe die Tatsache, daß in der EDV Englisch die Umgangssprache ist und die meisten Bezeichnungen in Englisch erfolgen, nicht erfunden, aber im Sinne der Verständlichkeit sollte man sich dran halten. Man findet in medzinischen Themen auch keine Eindeutschungen und die Schulterluxation findet man zwar unter Schulterluxation, nicht aber unter Schulterauskegelung und auch Schulterausrenkung ist lediglich eine Weiterleitung auf "..luxation".

Es ist völlig lächerlich, englische Fachausdrücke auf Deutsch zu übersetzen, dabei kommt je nachdem entweder Unverständliches oder Irreführendes heraus. Karl Kraus sagte einmal ("Hier wird deutsch gespuckt", in: Glossen zur Sprache, 1915):

Sie verstehen ihre eigene Sprache nicht, und so würden sie es auch nicht verstehen, wenn man ihnen verriete, daß das beste Deutsch aus lauter Fremdwörtern zusammengesetzt sein könnte, weil nämlich der Sprache nichts gleichgültiger sein kann als das "Material" aus dem sie schafft. Wenn's ihnen Spaß macht, mögen die Leute, die sich selbst diese Zeit noch vertreiben müssen, da selbst diese Zeit versäumt hat, sie zu vertreiben, in ihren Journalen, Büros und Restaurants Abteil für Coupé, Schriftleitung für Redaktion oder Schlackwurst für Zervelat sagen [....] und die spezifische Farbe der Stupidität wird weder von der Dummheit noch von der Einfalt je ersetzt werden können.

Alternativ kann man natürlich statt vom Stackpointer auch vom "Kellerstapelspeicherzeiger" (IBM, Handbuch der Datenverarbeitung, 1978) reden und erklären, daß Drucker nicht durch Escape-Sequenzen, sondern durch "Fluchtfolgen" gesteuert werden (Handbuch eines Mannesmann-Druckers, ca. 1980). Ich bin sicher, jeder Laie, der mit "Escape-Sequenzen" nichts anfängt, weiß bei "Fluchtfolgen" rein intuitiv sofort bescheid.

Noch eine Kleinigkeit: /dev/random ist eine Datei, kein normales Wort. Deshalb wird sie als solche auch durch die Formatierung durch entweder <code>..</code> oder <span style="font-family:monospace;">..</span> gekennzeichnet. Das ist - auch innerhalb des Artikels, etwa bei der Erläuterung von /dev/urandom - überall in der WP üblich. Warum diese Formatierung ausgerechnet beim ersten Vorkommen des Begriffs falsch sein sollt und rückgängig gemacht wurde, würde mich interessieren. --bakunin (Diskussion) 16:32, 17. Apr. 2013 (CEST)

Ob dieser Sermon über die Verwendung von Fremdwörter jemandem hilft, ist fraglich.

Warum für einen Begriff, für den sogar ein eigener Artikel unter deutschem Lemma existiert, die wortwörtliche Übersetzung ins Englische verwenden? [[Gerätedatei|device file]] - also bitte.

Weil die deutsche Übersetzung Humbug ist. Ein "device" ist nun mal nicht dasselbe wie ein "Gerät", genauso wie auch die Mediziner - siehe mein angeführtes Beispiel oben - auch von "Luxation" reden und "Ausrenkung" nur als Redirect (nebenbei: warum nicht die wörtliche Übersetzung "Umrichtung"?) zulassen. Ich dachte eigentlich, das recht ausführlich erläutert zu haben, aber scheinbar kann man das mit dem einen Wort "Sermon" abqualifizieren.

Auch wenn kein physikalisches Gerät dahinter steht, so kann der Pool aus dem die Werte entnommen werden doch als virtuelles Gerät verstanden werden. Weiterhin ist der Zufallsgenerator nun mal als Gerätetreiber implementiert und stellt diese beiden Dateien zur Verfügung. Demzufolge kann man sie auch Gerätedateien nennen.

Wie man dem Artikel selbst entnehmen kann, ist der Pseudo-Zufallszahlengenerator keineswegs immer als Gerätetreiber implementiert (eingebaut?), sondern "Bestandteil des Kernels" in Solaris (und, soweit ich das sehen kann, in AIX 6.1 TL3 ebenfalls). Der Grund, warum das (und viele andere Dateien, etwa die Einträge für Volume Groups unter AIX) in UNIX "device" bzw. "device file" genannt wird, ist, daß es eine bestimmte Art von Datei ist, nicht, daß ein Gerätetreiber oder gar ein Gerät dahintersteht. Man braucht ein solches device file nicht nur, damit der Service (denn das ist ein Service, den der Kernel zur Verfügung stellt) einen definierten Zugriffspunkt im Filesystem hat (ansonsten hätte man einen Satz von System Calls dafür gebraucht), sondern auch, damit man diesen Service mit Major- und Minor-number (wäre Dir "größere und kleinere Zahl" lieber?) versehen kann.

Natürlich wurde diese Schnittstelle von den Unix-Erfindern ursprünglich dafür geschaffen, eine einheitliche Verwaltung für unterschiedlichste Komponenten (auch physische - also körperliche - Geräte) zu haben. Aber das Wort "device" hat eben im Englischen eine wesentlich breitere Bedeutung als "Gerät" im Deutschen: das kann ein Gerät genauso wie "Hilfsmittel", "Anordnung", "Kunstgriff" (siehe dict.leo.org) oder eine Methode (this algorithm is a device for effectively computing the ...) bezeichnen.

Aus dem Grund habe ich jetzt "Pseudo-device" verwendet, allerdings das Lemma von Benutzer:Ath verlinkt, da das besser als meines paßte.

--bakunin (Diskussion) 07:14, 21. Apr. 2013 (CEST)

Und zur Formatierung: Jedes mal wenn der Begriff im Artikel verwendet wird, wird er anders formatiert. Ich habe nur gesehen, dass er im nächsten Abschnitt ohne tt verwendet wird und habe das übernommen. Wenn es dich stört, vereinheitliche es. -- Plankton314 (Diskussion) 17:25, 17. Apr. 2013 (CEST)

Kein Problem, Habe ich gemacht.

--bakunin (Diskussion) 07:14, 21. Apr. 2013 (CEST)

/dev/urandom

Die Beschreibung von urandom ist definitiv mißleitend: http://www.2uo.de/myths-about-urandom/ Hier nochmal explizit bestätigt von Kroah-Hartmann und Torvalds: https://plus.google.com/111049168280159033135/posts/AJkqHReK9x9 (nicht signierter Beitrag von 176.198.227.115 (Diskussion) 22:16, 10. Mär. 2014 (CET))

Einmal abgesehen davon, daß der gesamte Zufallszahlen-Generator nicht von Torvalds, sondern Theodore Ts'o programmiert wurde (und zwar in Kernelversion 1.3.30, was ihn wohl zur größeren Autorität in Sachen /dev/random vs. /dev/urandom macht), sagt das Linux Programmers Manual (Section 4) so ziemlich das Gegenteil von dem, was Du behauptest, nämlich (zitiert nach angeführter Quelle, Hervorhebung von mir):

When read, the /dev/random device will only return random bytes within the estimated number of bits of noise in the entropy pool. /dev/random should be suitable for uses that need very high quality randomness such as one-time pad or key generation. When the entropy pool is empty, reads from /dev/random will block until additional environmental noise is gathered.

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 non-classified literature, but it is theoretically possible that such an attack may exist. If this is a concern in your application, use /dev/random instead.

Man kann nun gegen die zusammenfassende Formulierung, die ich ursprünglich verwendet habe, nämlich daß /dev/random Zufallszahlen höherer Qualität produziere, einwenden, daß sie stark verkürze. Das tut sie in der Tat. Allerdings tut sie das, ohne den Inhalt der wohl wesentlichsten in Frage kommenden Quelle - der Systemdokumentation - zu konterkarieren, während Deine Einlassung jedenfalls durch diese nicht gedeckt ist.

Ich schlage deshalb vor, die ursprüngliche Forumlierung wieder einzusetzen. --bakunin (Diskussion) 15:55, 17. Mär. 2014 (CET)

Die Systemdokumentation ist schlicht irreführend. Lies doch den verlinkten Artikel mal. Da sind wiederum Kryptographen verlinkt, die deutlich mehr Ahnung haben als Ts'o. (nicht signierter Beitrag von 217.237.185.168 (Diskussion) 07:00, 20. Mär. 2014 (CET))

Ich bin auf der Seite der anonymen Benutzer hier. Aktueller Stand der Forschung ist, dass /dev/urandom sicher genug ist, auch für kryptographische Anwendungen. --Der Messer ^{meckern? - loben?} 10:15, 20. Mär. 2014 (CET)

Naja, aber im Gegensatz zu gewissen anderen Artikeln stimmen wir hier nicht über den vermeintlich korrekten Inhalt ab und schreiben dann das rein, was die Mehrheit für passend erachtet.--Plankton314 (Diskussion) 10:37, 20. Mär. 2014 (CET)

Was ist Sache?

1. Das urandom-Device ist auf allen möglichen *nix-System implementiert und hier wird nur über die Linux-Implementation gesprochen. Das sollte - egal, wie es nun im Artikel landet - mal klargestellt werden.
2. Im aktuellen Linux-Kernel 3.14-rc6 liefern random und urandom auf fast die gleiche Weise Zahlen. Sie entstehen, indem der Entropie-Pool (mit echt zufälligen Bits) gehasht wird und der Wert anschließend nochmal mit/über sich selbst gefaltet wird. urandom liefert nun auch weiter Zahlen, wenn der Pool erschöpft ist, d.h. alle enthaltenen Bits bereits zur Generierung herangezogen wurden.^[1]

Von diesem Zeitpunkt an hat man einen deterministischen PRNG, dessen Sicherheit auf dem Hash (als der kryptographischen Primitive) beruht. Ab hier ist es nun zwar theoretisch möglich, die Zahlen vorherzusagen, aber nur mit vielen "Wenn"s und "Aber"s. Geht man davon aus, dass die Hash-Funktion sicher ist, könnte man durchaus sagen, dass die erzeugten Zufallszahlen nicht echt, aber zumindest nach aktuellen Stand der Kryptographie sicher sind.

Vor diesem Hintergrund ist die man-Page nun nicht falsch oder veraltet, sondern sieht das ganze nur aus einem wirklich sehr theoretischen Blickwinkel.--Plankton314 (Diskussion) 10:37, 20. Mär. 2014 (CET)

Ich habe auf die usrprüngliche Formulierung von Plakton314 (teil-)revertiert, weil mir diese Diskussion langsam auf den Geist geht. Selbst wenn man den von der IP geschilderten Sachverhalt als richtig anerkennt (was man nicht muß - siehe oben), so leitet sich daraus bestenfalls ab, daß /dev/random und /dev/urandom unter Linux gleich gut (oder schlecht) hinsichtlich der Qualität der Zufallszahlen sind. Für die Formulierung "...bevorzugtes Device" gibt es absolut keinen Grund, das ist im besten Falle TF und im schlechtesten - angesichts der ständigen Hinzufügungen des "bevorzugten Devices" - Vandalismus. --bakunin (Diskussion) 16:36, 4. Apr. 2014 (CEST)

Artikel löschen oder auf englische Version verweisen

Da der Artikel weder die jüngsten Entdeckungen bezüglich NSA-Manipulationen noch die neuesten Änderungen an der Routine enthält und auch die früher angemahnten systemspezifischen Implementationen weiter ausblendet, sollte dieser wegen offensichtlicher Irreführung gelöscht werden oder hilfsweise auf die bessere englische Version verwiesen werden. Oder haben die angesprochenen Dienste etwas gegen Aufklärung?2003:71:EF24:7197:8953:F4B4:ED98:C656 19:10, 26. Mai 2018 (CEST)