Diskussion:/dev/random

Implementierung abseits Linux

Letzter Kommentar: vor 16 Jahren3 Kommentare3 Personen sind an der Diskussion beteiligt

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)Beantworten

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

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

Hardware -Zufallszahlen

Letzter Kommentar: vor 17 Jahren2 Kommentare2 Personen sind an der Diskussion beteiligt

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)Beantworten

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)Beantworten

Implemetierung des fast perfekten One-Time-Pad

Letzter Kommentar: vor 16 Jahren2 Kommentare2 Personen sind an der Diskussion beteiligt

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)Beantworten

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)Beantworten

spezielle Datei?

Letzter Kommentar: vor 12 Jahren2 Kommentare2 Personen sind an der Diskussion beteiligt

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)) Beantworten

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)Beantworten