mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Anregungen fuer einen Rauschgenerator


Autor: Michael G. (linuxgeek) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi Forum,

ich wuerde gerne einen (guten) USB-Rauschgenerator realisieren, wie 
koennte man das am Besten bewerkstelligen? Also ich rede jetzt weniger 
vom Schnittstellenteil als mehr vom Erzeugen des Rauschens selber. 
Anregungen sind willkommen, konnte leider nicht viel zu dem Thema hier 
finden.

Gruesse,
Michael

Autor: Helmi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Du kannst eine Rauschspannung mittels einer Z-Diode und nachfolgendem 
Verstärker erzeugen. Ich nehme wohl richtig an das du keine 
Pseudo-Rauschfolge mit Schieberegister erzeugen möchtest.

Gruss Helmi

Autor: Michael G. (linuxgeek) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nein, ich moechte "echtes" Rauschen erzeugen und zwar eines, das mir 
eine moeglichst gleichverteilte, zufaellige Bitfolge erzeugt. Also mit 
anderen Worten einen Zufallszahlengenerator ;)

Autor: Paul Baumann (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Basis-Emitterstrecken von Schalttransistoren machen auch ganz schön 
"Krawall".

MfG Paul

Autor: Detlef _a (detlef_a)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Helmi wrote:
> Du kannst eine Rauschspannung mittels einer Z-Diode und nachfolgendem
> Verstärker erzeugen.

Hab ich mal probiert. Die Schaltung war nicht sehr gut geschirmt, hat 
wunderbar gerauscht und 'hinter' dem Rauschen war prima Radio zu 
verstehen. Lieber digital mit Tiefpaßfilter. Gibt auch fertige ICs.

Cheers
Detlef

Autor: Helmi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Hab ich mal probiert. Die Schaltung war nicht sehr gut geschirmt, hat
>wunderbar gerauscht und 'hinter' dem Rauschen war prima Radio zu
>verstehen. Lieber digital mit Tiefpaßfilter. Gibt auch fertige ICs.


Auch das gequatsche im Radio kann man ja als zufällig betrachten.

Gruss Helmi

Autor: Michael G. (linuxgeek) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Gibt es irgendwo Beispielschaltungen? Is nen bissel duenn was ich 
gefunden habe. Das Beste waere es wohl das Rauschen analog zu erzeugen 
und dann zu digitalisieren.

Vielleicht kann ich es ja auf dieser Schaltung hier aufbauen:
http://www.hcrs.at/BILDER/NOISE2.GIF

Das Prob ist wohl dass da noch ein Verstaerker hinten dran muss...

Autor: Helmi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wenn man sich die Verstärkungsfaktoren der Transitoren anschaut sollte 
das eigentlich mit einem vernüftigen Pegel schon hinten rauskommen.

Allerdings könntest du anstelle des Transitorverstärkers einen OP 
nehmen.

Guss Helmi

Autor: Helmi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert

Autor: Michael G. (linuxgeek) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hmm... thanks. Ich hatte obige Schaltung (HCRS) schonmal aufgebaut, 
allerdings scheine ich das wohl nicht korrekt gemacht zu haben... leider 
;) Vom Prinzip her sind die alle aehnlich. Ich hatte ein 5V Bus-powered 
device im Sinn das ist nen bissel nen Prob die haben alle so hohe 
Betriebsspannungen und der von HCRS sogar 18V...

Autor: Helmi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Die höhere Spannung kommt dadurch zu stande das das Rauschen in der 
Z-Diode durch den Avalanche-Effekt hervorgerufen wird.
Deshalb nimmt man für den Rauschgenerator Z-Diode mit mehr als 6.8 V

http://de.wikipedia.widearea.org/wiki/Zener-Diode


Man könnte die Spannung für die Z-Diode mit einer kleinen Ladungspumpe
heraufsetzen. Den anschliessenden Verstärker könnte man dan wieder bei 
5V betreiben.

Gruss Helmi

Autor: Michael G. (linuxgeek) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Gibt es irgendwo Beispielschaltungen?

Autor: GM-Zählrohr (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Nein, ich moechte "echtes" Rauschen erzeugen und zwar eines, das mir
>eine moeglichst gleichverteilte, zufaellige Bitfolge erzeugt. Also mit
>anderen Worten einen Zufallszahlengenerator ;)

Ich könnte dir ein GM-Zählrohr anbieten (was sonst). In Verbindung mit 
einer Schaltung (HV- Erzeugung) einem Thorium-Glühstrumpf (als 
Strahlenquelle – gibt es im Campingbedarf), einer Bleiabschirmung 
(evtl.) sowie eines Zählers ist es sicher möglich damit einen 
Zufallsgenerator zu bauen. Bekannt ist, wie häufig Isotope zerfallen. 
Wann das genau geschieht gilt meines wissen nach noch als rein zufällig.
Jeder Physikstudent wird dir allerdings wahrscheinlich einige Argumente 
aufzählen können, wieso dieser Aufbau dann doch nicht so 100%e 
Zufallsergebnisse bringt. Ganz abgesehen vom Aufwand.

Ich würde es in deinem Fall es dann doch mit der Z-Diode (mit möglichst 
guter Schirmung) oder einem mathematischen Modell versuchen.
Beispiele wurden ja gepostet - ohne Abschirmung wird aus der Z-Dioden 
Variante natürlich doch nur ein Radio (Diodendetektor).
Gruß

Autor: Michael G. (linuxgeek) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Wann das genau geschieht gilt meines wissen nach noch als rein zufällig.

Nicht ganz, das ist ueblicherweise ein Poisson-Prozess, der ist 
Bernoulli-verteilt. Ich brauch was gleichverteiltes...

Autor: Andreas Schwarz (andreas) (Admin) Benutzerseite Flattr this
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Analoge gleichverteilte, zufällige Messwerte zu bekommen dürfte 
praktisch unmöglich sein. Die Gleichverteilung musst du per 
Nachverarbeitung erzeugen, bei einer symmetrischen 
Wahrscheinlichkeitsdichte im einfachsten Fall durch einen Komparator -> 
1/0. Um eine ordentliche Qualität zu erreichen braucht es aber mehr 
Aufwand.

Was möchtest du denn machen? Wie schnell brauchst du die Zahlen, und 
wozu?

Autor: Michael G. (linuxgeek) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich hab z.B. Erzeugung von seeds usw. im Sinn... wozu man halt 
ueblicherweise Zufall braucht. Aber es sollte halt fuer kryptografische 
Verfahren brauchbar sein. Naja ich seh schon das is alles nicht so 
einfach, leider... :(

Der resultierende Bitstring sollte halt optimalerweise bei einer Laenge 
von n Bits etwa n/2 0 und n/2 1 haben, und P(n_i = 1) = 1/2. OK das 
duerfte wohl nur naeherungsweise machbar sein, aber ansonsten isses 
ziemlich witzlos ;)

Autor: Andreas Schwarz (andreas) (Admin) Benutzerseite Flattr this
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Es gibt verschiedene Verfahren um aus teilweise zufälligen Zahlen den 
"echten" Zufall zu extrahieren. Z.B. indem man eine Anzahl von Bits mit 
einer Hash- oder Verschlüsselungsfunktion "mischt" und nur einige wenige 
Bits aus dem Ergebnis verwendet (je nachdem wie viel Entropie man in den 
Eingangsdaten zu haben glaubt).

Der im Linux-Kernel integrierte Zufallsgenerator arbeitet so ähnlich. 
Man kann ihn auch von außen mit Daten füttern, falls einem die normale 
Entropiesammlung mit Maus-, Tastatur- und Netzwerk-Events zu langsam 
geht. Dafür wäre so eine Rauschquelle brauchbar.

Autor: Michael G. (linuxgeek) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Da kannste auch gleich z.B. nen AES als Zufallsquelle benutzen... der 
verhaelt sich in obiger Hinsicht uebrigens recht optimal.

Autor: Andreas Schwarz (andreas) (Admin) Benutzerseite Flattr this
Datum:

Bewertung
0 lesenswert
nicht lesenswert
AES kann man nicht als Zufallsquelle benutzen. Du kannst damit ausgehend 
von einem zufälligen Seed gute Pseudouzfallszahlen erzeugen, aber 
irgendwo muss dieser Seed herkommen. Ich dachte genau darum geht es dir?

Autor: Jorge (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Es gibt doch gar keinen Zufall. Zufälle gibt es nur aus der Perspektive 
des Beobachters, wenn ein Wissen über die zugrundeliegende Kausalität 
fehlt oder zu schwierig ist. </kluggsch....>

In diesem Zusammenhang gilt radioaktiver Zerfall als Z...

http://de.wikipedia.org/wiki/Zufall

Du könntest per XOR-rückgekoppeltem Schieberegister eine MLS-Sequenz 
erzeugen (kein Zufall), damit stimmen dann wenigstens deine 
Randbedingungen.

Auch ein durchlaufender Mikrosekundenzähler - Fraktion des Timers - wird 
gerne verwendet. Der Auslesezeitpunkt bestimmt dann die Zufallszahl bzw 
Startsequenz.

Autor: Michael G. (linuxgeek) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Dass es keinen Zufall gibt ist mir auch klar. Ich definiere Zufall 
jedoch so, dass das System hinreichend komplex sein muss, so dass keine 
Vorhersage mehr getroffen werden kann.

Autor: Jorge (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Ich definiere Zufall jedoch so, dass das System hinreichend komplex sein >muss, 
so dass keine Vorhersage mehr getroffen werden kann.

Schon klar :-). Es lohnt sich auch nicht wirklich meinen Humor 
nachzuvollziehen. Eine Z-Diode bzw. eine Basis-Emitter Strecker in 
Sperrrichtung zu betreiben ist jedenfalls ein guter Ansatz finde ich. 
Das könnte man einfach auf einen Komparator geben und derweil msecs 
zählen ungefähr wie oben schon beschrieben.

Autor: Stefan B. (stefan) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Im Artikel Zufallszahlen sind auch ein paar praktische Hinweise drin 
u.a. der Link zum Open Random Bit Generator

Autor: spess53 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi

Zur Anregung: Funkamateur 1/07 'XR232- echter Zufallsgenerator für die 
serielle Schnittstelle'

MfG Spess

Autor: Stefan B. (stefan) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
spess53 wrote:
> Zur Anregung: Funkamateur 1/07 'XR232- echter Zufallsgenerator für die
> serielle Schnittstelle'

Siehe auch unter der Homepage des Autors:
http://www.kielnet.net/home/julien.thomas/tech/XR232WEB.htm

Autor: Michael G. (linuxgeek) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Yups da war ich grad... ziemlich interessant. Da koennte man jetzt 
eigentlich noch ne USB-Fassung draus machen und die Sache waere 
geritzt... schaut gut aus. Ich finde aber auch die Fassung interessant 
mit einer MCU und einem Kondensator und einer Hashfunktion, wobei ich 
mit PICs nix anfangen will, sowas muesste man dann fuer einen AVR 
realisieren, z.B. einen kleinen Tiny :D

Autor: Hagen Re (hagen)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
In der Kryptographie benötigst du keinen echten Zufallsgenerator. Man 
benötigt einen Datenstrom von Bits die für den Angreifer nicht 
reproduzierbar sind. Das können echte Zufallsbits sein es müssen sie 
aber nicht sein. Die Nicht-Reproduzierbarkeit hat nichts mit Zufall zu 
tuen. Du kannst also auch durch einen Menschen auf der Tastatur oder per 
Maus ausreichend lange Daten sammeln und diese mit geeigneten Verfahren 
in der Entropie verbesseren -> YARROW von Bruce Schneier zb. Das ist 
dann wenn überhaupt nur reproduzierbar von dieser einen Person. Es ist 
kein Zufall und denoch sicher da es durch Angreifer nicht reproduzierbar 
ist. Der große Vorteil dabei ist das man besser beweisen kann das diese 
Daten auch wirklich sicher und pseudorandom sind als wenn sie durch 
einen echten Zufallsgenerator durch Rauschen erzeuigt wurden. Denn auch 
wenn uns die Physik belerht das Temperaturschwankungen einer Diode nicht 
reproduzierbares Rauschen=Zufall darstellt, so kannst du denoch ncht die 
korrekte Funktionsweise dieser Diode über die Zeitspanne ihrer Benutzung 
als Zufallsgenerator sicherstellen noch beweisen. Denn du kannst die 
Zufälligkeit der Daten die durch diese Diode erzeugt wurde noch 
reporduzieren oder unterscheiden von eben Nicht-Zufälligkeit weil die 
Diode einen Schaden erlitten hat oder sie nichtzufällige Störstahlungen 
eingefangen hat. Defakto hat also das gesamte kryptographische Verfahren 
eine Sicherheit die zufällig ist und nicht berechenbar.

Gruß Hagen

Autor: mr.chip (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wenn man vom Rauschen immer nur das LSB nimmt, dann hätte man doch eine 
nahezu perfekte Zufallsfolge, oder etwa nicht?

Autor: berddulak (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
-> Mausbewegung auswerten
Warum nimmt man nicht die x-, und y-offsets in Funktion der Zeit?
Jeder Mensch fährt doch mit der Maus andere Wege und in anderer 
Geschwindigkeit .. ?
Müsste doch halbweg "zufällig" sein ..

Gruss

Autor: Andreas Schwarz (andreas) (Admin) Benutzerseite Flattr this
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hagen Re wrote:
> In der Kryptographie benötigst du keinen echten Zufallsgenerator.

Doch!

> Man
> benötigt einen Datenstrom von Bits die für den Angreifer nicht
> reproduzierbar sind. Das können echte Zufallsbits sein es müssen sie
> aber nicht sein. Die Nicht-Reproduzierbarkeit hat nichts mit Zufall zu
> tuen.

Um nicht reproduzierbar zu sein muessen diese Daten ausreichend 
Entropie, also ECHTEN Zufall enthalten. Ob die Entropiesammlung durch 
Timing von Tastatur-Interrupts, Diodenrauschen oder durch Ausdenken 
einer Buchstabenkombination im Kopf erfolgt spielt keine Rolle, solange 
das Ergebnis ausreichend Entropie enthaelt. Man kann einen sicheren 
Schluessel nicht rein deterministisch erzeugen.

> Du kannst also auch durch einen Menschen auf der Tastatur oder per
> Maus ausreichend lange Daten sammeln

Das ist der Zufallsgenerator.

> und diese mit geeigneten Verfahren
> in der Entropie verbesseren -> YARROW von Bruce Schneier zb.

Es kann immer nur maximal so viel Entropie rauskommen wie vorne 
reingeht. Wenn du Yarrow mit 56 Bit Entropie fuetterst und damit einen 
128 Bit Schluessel erzeugst, dann ist der Schluessel effektiv nur 56 Bit 
lang. Darauf wird IIRC auch nochmal explizit im Yarrow-Paper 
hingewiesen.

Hatten wir die selbe Diskussion nicht schonmal?

Autor: Andreas Schwarz (andreas) (Admin) Benutzerseite Flattr this
Datum:

Bewertung
0 lesenswert
nicht lesenswert
mr.chip:
Nur so perfekt wie der Komparator im A/D-Wandler und das Rauschen. 
Irgend eine Systematik wird man da immer finden. Um das zu vermeiden 
verarbeitet man die Daten wie schon gesagt weiter. Z.B. nimmt man 
mehrere Abtastwerte, einen durchlaufenden Zaehler, verknuepft beides mit 
SHA1, MD5, AES (oder irgend einer anderen Einwegfunktion die die Bits 
unumkehrbar verwuerfelt), und nimmt davon dann jeweils nur ein paar Bit, 
je nachdem wie zufaellig das Rauschen am Eingang ist.

Autor: Esko (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Michael:
Wenn du etwas ziemlich fertiges suchst und nicht allzuviel basteln 
willst, dann ist LavaRnd eine gute Möglichkeit. Dort wird das rauschen 
eines CCD aka Webcam benutzt und mit einem Linuxtreiber nochmal gemischt 
und verkürzt.
http://www.lavarnd.org/what/process.html

Autor: Michael G. (linuxgeek) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ihr weicht vom Thema ab...

Also: Hagen: Was Du schreibst ist grossteils Kaese, daher werde ich das 
mal nicht weiter kommentieren -- sorry. Nur soviel: Eine nicht 
reproduzierbare Bitfolge ist per Definition eine Zufallsfolge.

Andreas: AES kann man zwar benutzen, faellt aber nicht in die Kategorie 
einer Einwegfunktion.

Esko: Das Rauschen von einem CCD-Sensor erscheint mir nicht gut genug, 
davon abgesehen habe ich keine Webcam.

Ich werde mir wohl mal diese Schaltung bauen und sehen, wie es ist:
http://www.kielnet.net/home/julien.thomas/tech/XR232WEB.htm

Interessanter fuer mich waere es mal Rauschen in den ADC zu fuettern und 
dann nur das niederwertigste Bit auszuwerten. Die so gewonnenen Daten 
kann man ja immernoch mal aufbereiten, auch wenn ich glaube, dass das 
fast nicht noetig sein wird. Ich finde nur leider keine 
Beispielschaltung, um z.B. das Rauschen einer Diode zu nutzen. Weiteres 
Problem ist die hohe Spannung... haette mir gerne ein bus-powered device 
gebaut.

Autor: whatever (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das Ding hier funktioniert bei mir recht gut:
http://us1.webpublications.com.au/static/images/ar...

C1 nicht vergessen! Der erhöht die Ausgangsspannung um ca. 30 dB 
(angeblich...)

Autor: Michael G. (linuxgeek) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hmm... schaut doch schonmal ganz gut aus... (= Aber ich fuerchte 
bus-powered is dann nicht, braucht man wohl zwangslaeufig ne eigene 
Spannungsversorgung. Ich werde mir das mal aufbauen und ansehen, thx.

Autor: Paul Baumann (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Eine Z-Diode als Rauschquelle habe die Leute schon vor 2 Tagen 
vorgeschlagen..... ;-)

Paul

Autor: Michael G. (linuxgeek) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ja das weiss ich auch mir geht's um konkrete Schaltungen... und ich 
weiss nich aber 18V Betriebsspannung erscheint mir ein bisschen hoch, 
bei dem, was ich gefunden habe. Mal sehen was aus der 
Transistorschaltung rauskommt.

Autor: Hagen Re (hagen)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Nur soviel: Eine nicht
>reproduzierbare Bitfolge ist per Definition eine Zufallsfolge.

Falsch, die Frage ist nämlich für wen sie nicht reproduzierbar ist und 
wie hoch der technische, zeitliche Aufwand wäre sie denoch für 
denjenigen der sie eben nicht reproduzieren können darf zu knacken.

Wenn ich eine absolut deterministische Folge von Pseudozufallsbits 
erzeuge bei dem der Seed als Geheimnis nur mir bekannt ist und der PRNG 
mathematisch als sicher bewiesen wurde dann kannst du rein garnichts aus 
dieser Zufallsfolge reproduzieren. Da die Schranken dieses RNGs so hoch 
gewählt wurden hast du defakto auch praktisch gesehen nie die 
Möglichkeit diese Folge zu knacken. Zb. benutzt man einen BBS-RNG -> 
Blum Blum Shub Generator -> Quadratische Reste Generator mit 1024 Bit -> 
2^1024 Bit Periode. Wenn ich dir nicht die Startparameter verrate dann 
ist diese Folge mathematisch betrachtet identisch zu einer echten 
Zufallsfolge. Aber mit dem Unterschied das ich das auch mathem. als 
sicher beweisen kann im Gegensatz zu einen echten RNG. Denn ich kann 
jeerzeit mit den gleichen, nur mir bekannten Startparametern, diese 
Folge reproduzieren und damit auch technisch alle Komponneten 
verifizieren. Ich könnte sogar dir diese Startparamater geben und du 
benutzt sie auf deiner Hardware und kann somit verifizieren das unsere 
beiden Hardware bei gleicher erzeugter Folge, korrekt und Fehlerlos 
funktionieren. Das ist ne ganz andere Sicherheitsstufe in der 
Kryptographie als sich auf das fehlerlose Funktionieren einer 
Rauschdiode verlassen zu müssen.

Aber egal: wir hatten diese Diskussion tatsächlich schonmal und auch 
damals rannte ich gegen Mauern ;) Nur soviel: Kryptographie ist deshalb 
sicher weil wir jedes Quentchen an Daten und Algortihmus per 
mathematischen Beweis als sicher beweisen könne und zusätzlich jeden 
Status wiederholt reproduzieren können, wie bei einem Expermient auch 
notwendig.

Gruß Hagen

Autor: Michael G. (linuxgeek) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das einzige Problem ist nur dass diese Seeds i.d.R. zu klein sind. Und 
dann stellt sich die Frage: Wie generiere ich den Seed. Letztlich 
brauchst Du doch einen Zufallsgenerator. Wenn ich 128 seed-Bits 
generiere kann ich auch gleich die Schluesselbits generieren. Und 
Bauteilrauschen ist nicht reproduzierbar.

Und noch was: Ich weiss zwar, dass es Deine Lieblingsbeschaeftigung ist, 
Hagen, aber ich moechte das hier nicht in eine Diskussion um Krypto 
ausarten lassen, dass Rauschgeneratoren benoetigt werden und sinnvoll 
sind steht ausser Frage, daher will ich das hier nicht diskutieren.

Autor: Michael G. (linuxgeek) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hm, da rauscht leider garnichts... Aufbau scheint augenscheinlich 
korrekt.

Autor: Helmi (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
@Michael G. (linuxgeek)

Probier die Schaltung mal aus. Also bei mir rauschst gewaltig.
Du darfts allerdings keine Z-Diode < 6.8V nehmen die tuens nicht.

Gruss Helmi

Autor: beru (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wie wäre es mit dem LSB des Mikrofoneingangs der Soundkarte? Zur not 
vielleicht noch ein kleines Kabel als Antenne dranlöten.

Autor: Michael G. (linuxgeek) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nein, ich brauch eine Standalone-Loesung.

Und Nachtrag fuer Hagen nochmal: Hab meinen Professor heut nochma 
erzaehlt, was Du weiter oben in den Raum gestellt hat und er war 
ebenfalls der Meinung dass das Krampf ist ;) Und nicht dass Du mir jetzt 
kommst der sei inkompetent, gell?

Helmi: Schau ich mir heute abend mal an, thx.

Autor: Helmi (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
@Michael G. (linuxgeek)


Hier noch ein Bildchen vom Signal

Gruss Helmi

Autor: Michael G. (linuxgeek) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Fuer was ist eigentlich der Timer da? Kann man den durch einen NE555 
ersetzen?

Michael

Autor: Arno H. (arno_h)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,
das ist eine Ladungspumpe zur Erzeugung einer höheren Spannung aus den 
5V, um die Z-Diode spannungsmäßig in den Durchbruchbereich zu bringen.
Alles was an C1 halbwegs stabile 9 - 10Volt bringt, ist geeignet.

Arno

Autor: Helmi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Michael G. (linuxgeek)

Der ist dafür da eine Ladungspumpe zu betreiben.
Wie Ich erwähnte muss die Z-Dioden Spannung grösser als 6.8V sein.
Die ladungspumpe stockt die Betriebsspannung von 5V die du aus dem USB 
bekommst auf ca. 8 .. 9V auf. Mess da mal nach an der Z - Diode.
Wie gesagt bassiert das rauschen der Z-Diode auf dem Avalanche Effekt 
und der tritt erst bei Spannungen >= 6.8V auf daher die 
Spannungserhöhung.

Gruss Helmi

Autor: Michael G. (linuxgeek) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
OK, ich hab leider nicht die richtigen Z-Dioden da, Du meinst ja nehme 
ich mal an die Durchbruchspannung... das mit der Ladungspumpe ist aber 
ein guter Trick dann kann ich mir ja vielleicht doch ein bus-powered 
device draus machen :D

Autor: Helmi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Richtig

Z-Dioden von 6.8 , 7.5 , 8.2 sind geeignet.

Ich habs heute nachmittag mit einer 8.2V Z-Diode getestet

Gruss helmi

Autor: T. H. (pumpkin) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Michael G., du widersprichst dir selbst. Auf der einen Seite möchtest du 
einen echten Zufall generieren und lehnst gute Vorschläge mit der 
Begründung "nicht zufällig genug" ab, auf der anderen Seite sinnierst du 
darüber mit einer Ladungspumpe ein getaktetes Element in die Schaltung 
zu bringen.

Autor: Michael G. (linuxgeek) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Allright, sieht vielversprechend aus. Dann werd ich heut das ganze mal 
mit nem Mikkicontroller und nem USB-UART drum herum planen und dann 
sehen wir mal weiter. Nachdem Du die Schaltung ja getestet hast nehme 
ich mal an, dass es funktioniert und ich spare mir mal einen Testaufbau. 
Wenn ich sowieso Teile holen muss kann ich alles so besorgen wie ich's 
brauch...

Greets,
Michael

Autor: Helmi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@T. H. (pumpkin)

Falsch !

Die Ladungspumpe dient lediglich eine höhere Spannung zu erzeugen und 
hat mit Rauschspannungs generierung nix zu tun die würde wenn man eine 
höhere Spannung als 6.8V hat auch funktionieren. Die Spannung ist 
zusätzlich noch gefiltert damit keine Störungen in die Rauschquelle 
kommen.

Gruss Helmi

Autor: Michael G. (linuxgeek) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hatte ich irgendwas anderes behauptet? Der Zweck scheint klar...

Autor: Helmi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Michael G. (linuxgeek)

Beweis durch Foto !

Wenn du noch Bauteile besorgen muss dann nimm wie im Schaltplan 
angedeutet einen besseren OP als den LM324. Stichwort: Rail to Rail Op. 
z.B. TS912 oder OPA2340 und einen TLC555 als Timer

Ausserdem empfehle ich dir eine Saubere Masseführung damit dir die 
Ladungspumpe nicht ins Signal streut.

Gruss Helmi

Autor: Michael G. (linuxgeek) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
OK, ich werde Dir das Design nochmal einstellen dann kann ich es noch 
verbessern. Beweis fuer was? Etwas, das ich nicht gesagt habe, kann ich 
kaum durch ein Foto beweisen, oder?

Autor: Helmi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Michael G. (linuxgeek)

Ich meinte mein Foto vom Signal

Gruss Helmi

Autor: Michael G. (linuxgeek) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Achso... sag ma kannst Du mir evt. das .sch-File schicken? Ansonsten 
muss ich den Plan naemlich nachzeichnen - Fehlerquelle.

Greets,
Michael

Autor: Helmi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ja kann ich morgen machen sitz zur Zeit an einem anderen PC wo ich das 
File nicht drauf habe

Gruss Helmi

Autor: Michael G. (linuxgeek) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sch...ade hm... muss ich's halt doch nachzeichnen. Na mal sehen stell's 
trotzdem mal ein weiss nich wie weit ich komme

Autor: Michael G. (linuxgeek) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
OK ich wart mal auf Dich mit der Schaltung, hab erstmal das drumherum 
gemacht... ;)

Autor: René D. (Firma: www.dossmatik.de) (dose)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich hatte in meiner Ausbildung Professor Leimer von der HTWK-Leipzig. 
Dieser Prof. Leimer hatte in einer DDR Zeitschrift einen Artikel über 
einen Rauschgenerator geschrieben. Leider habe ich diesen Artikel nicht 
mehr.
Ich glaube, dass die Zeitschrift Radio Fernsehen Elektronik hieß, bin 
mir aber nicht sicher.

Autor: Helmi (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
@Michael G. (linuxgeek)

Hallo Michael

Hier das RAUSCH.SCH u. RAUSCH.BRD File wie gestern Abend versprochen

Gruss Helmi

Autor: Michael G. (linuxgeek) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Thx Hemli... leider hat mir der Depp vom Conrad NE555 statt nem LC555 
verkauft und ich hab das zu spaet bemerkt... dann werde ich das jetzt 
doch aendern muessen weil deswegen will ich nicht nochmalk hinfahren. 
Muss ich das noch entsprechend aendern.

Zur theoretischen Untersuchung der Qualitaet der generierten 
Zufallszahlen zieh ich mir mal Knuth Band 2 Kapitel 1 rein ;) Da werden 
statistische Verfahren zur Gueteuntersuchung von Zufallszahlen 
vorgeschlagen.

Ach ja, wuerdest Du den kompletten ADC-Wert oder nur ein Bit auswerten 
und wenn ja, welches? Mein Matheprofessor meinte ich soll das empirisch 
herausfinden, vielleicht hast Du ja einen Vorschlag.

Gruss,
Michael

Autor: Helmi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Michael G. (linuxgeek)


Ich habs hier bei mir auch nur mit einem NE555 getestet
Der vorteil der CMOS version liegt :
1. In der hoeheren Ausgangssmplitude -> hoehere Spannung an C7
2. Im niederigen Stromverbrauch

Wie gesagt im meinem aufbau steckte eine 8V2 Z-Diode
Welche hast du denn jetzt da ?

Wenn du nur ein Bit auswerten willst kannst du die Verstaerkung des 2. 
Op ja hoeher ansetzen und den Ausgang direkt auf einem Port legen.

Beim ADC hast du alle moeglichkeiten offen

Zur Qualitaet der Zufallszahlen kann ich dir leider nix sagen sorry.

Gruss Helmi

Autor: Andreas Schwarz (andreas) (Admin) Benutzerseite Flattr this
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hagen Re wrote:
>>Nur soviel: Eine nicht
>>reproduzierbare Bitfolge ist per Definition eine Zufallsfolge.
>
> Falsch, die Frage ist nämlich für wen sie nicht reproduzierbar ist und
> wie hoch der technische, zeitliche Aufwand wäre sie denoch für
> denjenigen der sie eben nicht reproduzieren können darf zu knacken.
>
> Wenn ich eine absolut deterministische Folge von Pseudozufallsbits
> erzeuge bei dem der Seed als Geheimnis nur mir bekannt ist

Der Seed ist der Knackpunkt. Wenn n Bit Entropie als Seed reingehen 
können auch aus dem besten PRNG nur höchstens n Bit Entropie 
herauskommen. Die Qualität des Seeds begrenzt die Qualität der 
Pseudozufallszahlen. Um diese Entropie für den Seed zu erzeugen braucht 
man einen echten Zufallsgenerator.

> Aber egal: wir hatten diese Diskussion tatsächlich schonmal und auch
> damals rannte ich gegen Mauern ;) Nur soviel: Kryptographie ist deshalb
> sicher weil wir jedes Quentchen an Daten und Algortihmus per
> mathematischen Beweis als sicher beweisen könne

Schön wäre es. Das mag für RSA und das OTP zutreffen, aber finde mal 
einen Beweis für die Sicherheit von AES oder SHA1...

Autor: Andreas Schwarz (andreas) (Admin) Benutzerseite Flattr this
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Michael G. wrote:
> Ach ja, wuerdest Du den kompletten ADC-Wert oder nur ein Bit auswerten
> und wenn ja, welches?

Schau dir an wie es im Open Random Bit Generator gemacht wird.

Autor: Torben (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Die Schaltung koennte man auch X mal aufbauen und messen. In dem MC 
startet man noch einen Zähler, addiert die Messwerte und addiert den 
Zählerwert.

Autor: Michael G. (linuxgeek) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Torben, was meinst Du?
Helmi: Hab es noch nicht aufgebaut, aber ich hab ne 7.8 und ne 8. 
irgendwas gekauft. Ach ja, die beiden Timer sind nicht pin-kompatibel so 
wie ich das gesehen habe, oder?

Sobald die Sache laeuft werde ich das Ganze mal mathematisch analyieren 
und dann sehen wir auch, ob die Sache wirklich gut ist, erst dann ist 
naemlich der Kryptologe wirklich zufrieden damit. Schiere Annahmen 
alleine sind mir hier etwas zu vaage ;) Immerhin muss ich doch noch nen 
bissel den Informatiker raushaengen lassen hehe :D

Wenn man wirklich die Zufallsfolge komplett auf irgendwelche Muster 
ueberpruefen will, wird das sehr aufwendig, hab das heute mal so 
angesponnen. Daher hat Onkel Knuth, der Gute, sicher was dazu zu sagen 
(=

Gruss,
Michael

Autor: Helmi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Michael G. (linuxgeek)

Was hast du nun gekauft beim big blue C

NE555 oder TLC555    (beide sind Pin kompatible)
NE555 = Bipolare Version
TLC555 = CMOS Version

LC555 gibts nicht (zumindest mir nicht bekannt)

Schaetze mal du meinst 6.8 und 8.2 V Z-Diode
 muesste beides gehen
mein Favorit waere allerdings 7.5V

Tja als Elekrtotechniker hat man mit Zufallszahlen halt weniger am Hut 
wie als Informatiker

Viel Spass noch
Helmi

Autor: Michael G. (linuxgeek) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Den NE555, den haette ich aber auch noch da gehabt ;) Na was soll's... 
ich schreib nen Artikel auf meiner Page zu der Sache. Wenn Du mir Deinen 
Namen sagst kann ich Dich dankend erwaehnen... Knuth hat in seinem The 
Art Of Computer Programming einige statistische Analysen fuer 
Zufallszahlen vorgestellt. Wenn ich das mal ausgearbeitet habe und den 
Generator dahingehend gestestet habe kannst Du auch Aussagen darueber 
machen wie Gut der Zufall dann tatsaechlich ist, oder ob doch 
irgendwelche Muster auftreten.

Lg,
Michael

Autor: Helmi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Michael G. (linuxgeek)


Ooh Danke der Ehre

Helmi  -- >  Helmut Lenzen

thx Michael

wie heisst denn deine Page ?

Autor: Michael G. (linuxgeek) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
coremelt.net ;)
Das mit den Zufallszahlen wird aber wohl mein erster etwas 
wissenschaftlicherer Artikel dort. Hm ich ueberlege mir ob ich das TeXen 
soll... aba dann isses nich grad so gut fuer HTML ;)

Naja sagen wir mal nachdem Du die Grundschaltung vorgeschlagen hast, 
hast Du ja einen nicht unwesentlichen Beitrag geleistet...

Autor: Peter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
In dem Buchlein Minispione Band II gab es eine Schaltung, wie man rosa 
und weißes Rauchen generiert.

Autor: Michael G. (linuxgeek) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Es gibt wohl ein paar...
Ach ja Helmi: Ich hab etliches durch SMD ersetzt in Deiner Schalung. Ich 
hoffe jetzt dass auf ne 6.5cm x 5cm Platine zu bekommen mit USB-Wandler 
und Mikrocontroller ;)

Autor: Helmi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Michael G. (linuxgeek)

Wenn Ich das vorher gewusst hätte , hätte ich sie dir in SMD layoutet.
Die Bauteile waren zuerst auch in SMD
Normalerweise mach ich auch das meiste in SMD


Gruss Helmi

Autor: Michael G. (linuxgeek) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hmm... ok egal nun ;)

Autor: Michael G. (linuxgeek) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Saukrass... mal so ein kleiner Gedanke wie man "optimal" pruefen wuerde, 
ob eine Zufallsfolge wirklich gut ist. Nehmen wir an, wir haben 1000 
Bits gewuerfelt. Optimal waere natuerlich, wenn alle Bits mit einer 
Wahrscheinlichkeit von P(Bit ist 1) = 0.5 und P(Bit ist 0) = 0.5 
auftreten. Dass heisst natuerlich auch, dass bei 1000 Bits etwa 1000/2 
Nullen und Einsen auftreten sollten. Das alleine reicht natuerlich noch 
als Kriterium bei Weitem nicht aus, denn die Folge koennte ja so 
verteilt sein: 101010...10 und somit waere das Kriterium erfolgreich, 
aber unzureichend.

Was macht man also, man prueft nun, ob saemtliche Zwei-Tupel ebenfalls 
gleich verteilt sind, d.h. 00, 01, 10, 11 mit jeweils 1/4 
Wahrscheinlichkeit. Die Anzahl, solche Tupel zu bilden, ist

Das muss man nun mit saemtlichen n-Tupeln machen, sinnvollerweise hoch 
bis zu den 500-Tupeln, also insgesamt:

Das ist ne Menge Holz, naemlich:

Also satte 2^1000 Tests! Das hat mir mein Prof heute gesagt und ich 
dachte das kann nich stimmen, aber jetzt isses plausibel. Es ist also 
klar dass man statistische Verfahren zur Analyse braucht ;)

Ach ja noch ein Gedanke: Man sollte sich die Zufallsfolge als einen 
"Haufen" voller Muenzen vorstellen, aus denen man alle moeglichen 
n-Tupel auf ihr Vorkommen prueft. Man nimmt wahllos z.B. 2 heraus und 
notiert sich den Wert, usw, usf. Systematisch wenn man das macht kommt 
man auf das Urnenexperiment und genannten Binomialkoeffizient.

Michael

Autor: Michael G. (linuxgeek) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Kaum wird's ein bisschen mathematisch sind sie alle weg ;) Schaemt Euch 
:D

Autor: Torben (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Torben, was meinst Du?
>Helmi: Hab es noch nicht aufgebaut, aber ich hab ne 7.8 und ne 8.
>irgendwas gekauft. Ach ja, die beiden Timer sind nicht pin-kompatibel so
>wie ich das gesehen habe, oder?

Ich meinte damit Helmi's Rauschgenerator mehrmals aufzubauen und jeweils 
mit einem ADC zu messen. Die gemessenen Werte könnte man addieren und um 
eine noch höhrere Zufallswahrscheinlichkeit zu erreichen könnte man den 
8 o. 16Bit Timer im Überlaufbetrieb laufen lassen und zu den ADC Werten 
addieren.

Ich vermute nur das ein 8 / 10 ADC zuwenig Auflösung hätte und mehrere 
24 Bit AD Wandler besser wären.

Autor: Michael G. (linuxgeek) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Solche Operationen bringen in aller Regel garnichts -- eher das 
Gegenteil ist der Fall. Siehe z.B. Knuth's "Super Random number 
generator". Du laeufst bei solchen Dingen naemlich Gefahr, dass Deine 
Zufallsfolge degeneriert. Wird der Zufall gleich zu Beginn gut 
generiert, sind solche "Tricks" nicht notwendig und auch eine 
Nachbearbeitung wird nicht noetig sein.

Autor: Paul Baumann (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bau das Ding endlich und rechne nicht so viel. Versuch macht kluch. ;-)

Erwarten wird Dich wahrscheinlich das:
 http://de.wikipedia.org/wiki/Normalverteilung

;-))

Duck und weg
Paul

Autor: Michael G. (linuxgeek) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Naja wenn dem so waere, waere der Generator nutzlos, aber dann wuesste 
man dann ja auch, was immerhin eine Erkenntnis ist. Naja und was bringt 
Dir ein Zufallszahlengenerator von dem Du nichts ueber die Qualitaet 
aussagen kannst? Ich meine wenn Pseudozufall ausreicht kannste ja gleich 
ein arithmetisches Verfahren benutzen. Und keine Angst ich bau die 
Schese schon noch ;) Hab nen "bisschen" viel zu tun im Moment.

Michael

Autor: Paul Baumann (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Linuxgeek
...das war doch nicht so ernst gemeint. Ich wollte Dir nicht aus den 
"Schlips" treten. :-))
Wenn ich mich richtig erinnere, habe ich sogar irgendwo (wenn ich nur 
wüßte, wo) eine Patentschrift gelesen, wo sich der Autor auch das 
Zufallsprinzip mit der Z-Diode als Rauschquelle angemeldet hatte.
Ich selbst habe auch eine ähnliche Schaltung im Gang, die als 
"elektronisches Feuer" mit 4 gelben und roten Leuchtidioten auf der
Modellbahn meine Schlackegrube "brennen" läßt. Das Signal sieht auf dem 
Oszi so zufällig aus, daß ich es nur mit Mühe und Not triggern lassen 
kann.

MfG Paul

Autor: Christian Berger (casandro) Flattr this
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Servus,

das Diodenrauschen soll angeblich nicht langzeitstabil funktionieren.

Was man aber machen kann ist Widerstandsrauschen auszunutzen. Entweder 
das thermische Rauschen (etwas klein) oder das Rauschen durch einen 
Kohlewiderstand. In jeden Falle kannst Du das relativ einfach mit einem 
OP-Verstärker verstärken, oder bei einigen Controllern den integrierten 
Comparator.

Eventuell kannst Du aber auch Inverter nehmen und die als Oszillator 
verwenden. Im Prinzip sollten die mit unterschiedlichen, schwankenden 
Frequenzen schwingen. Wenn Du die Ausgänge XOR-verknüpfst und schnell 
abtastest, kannst Du Zufallsbits erzeugen. Wobei ich aber nicht weiß, 
wie viel Enthropie pro Bit enthalten ist.

Zur Weiterverarbeitung würde ich folgendes machen:

Man verwendet ein großes Schieberegister (evtl im Controller.) mit 
möglichst vielen Bits. Man verschaltet es als 
Pseudozufallszahlengenerator, taktet aber die Bits, welche man von der 
Schaltung bekommt noch mit rein. Somit werden die eingehenden Bits immer 
schön mit in den Entropiepool gemischt.
Zusätzlich braucht man nun einen Zähler, welcher bei jedem Takt um die 
Enthropiemenge des Zufallsexperimentes erhöht wird. Fordert der Rechner 
nun Bits an, so wird die Enthropiemenge dieser Bits von dem Zähler 
abgezogen. Erreicht der Zähler 0, so werden keine Bits mehr ausgegeben. 
Erreicht er die maximale Informationsspeicherkapazität des 
Schieberegisters so zählt er nicht weiter.

Die Enthropie einer Quelle kann man relativ einfach abschätzen. Du 
nimmst ein Bit von Deiner Quelle, schiebst das in ein (kleines) 
Schieberegister. Dann führst Du eine Statistik darüber, wie häufig 
bestimmte Inhalte des Schieberegisters auftreten, dann schiebst Du 
wieder ein Bit rein, etc...
Im Optimalfall sollten alle Kombinationen (fast!) gleich häufig 
auftreten.

Autor: Michael G. (linuxgeek) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi Christian,

danke fuer Deine Anregungen aber fuer mich hoert sich das nicht so gut 
an. Ich will ja keinen Pseudozufallsgenerator bauen. Eventuell bereite 
ich die Daten rechnerseitig nochmal etwas nach, falls dies wirklich 
noetig ist. Das kann ich aber erst sagen, wenn ich die ausfuehrlich 
untersucht habe. Immo bin ich noch beim Layout. Die Ergebnisse werden 
auf meiner Homepage nachlesbar sein.

Gruesse,
Michael

Autor: Christian Berger (casandro) Flattr this
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Naja, es geht hier ja nicht um einen Zufallszahlengenerator, sondern 
darum, wie Du die Daten weiterverarbeiten kannst. Das kannst Du im 
Prinzip auch in einem Mikrocontroller machen.

Autor: Michael G. (linuxgeek) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Falls dies noetig ist, koennen wir nochmal drueber reden... ;)

Autor: Christian Berger (casandro) Flattr this
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Meiner Meinung nach ist das immer notwendig. Denn dein 
Zufallszahlengenerator kann ja kurzzeitige Irregularitäten (statische 
Aufladung, eingekoppeltes Netzbrummen, etc) haben.

Autor: Michael G. (linuxgeek) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das waere schlecht, aber das Gehaeuse wird natuerlich ausreichend 
geschirmt. Und die Spannungsversorgung kommt ueber den USB-Bus. Ich kann 
ja eine Option daraus machen, z.B. die gewonnene Entropie nochmal zu 
verhashen oder sowas... aber dann Rechner/Treiberseitig.

Lg,
Michael

Autor: AVRFan (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Meiner Meinung nach ist das immer notwendig. Denn dein
>Zufallszahlengenerator kann ja kurzzeitige Irregularitäten (statische
>Aufladung, eingekoppeltes Netzbrummen, etc) haben.

Hm, interessanter Aspekt. Kann man mögliche "kurzzeitige 
Irregularitäten" denn irgendwie erkennen?  Gut, wenn man dazu imstande 
ist, gibt es kein Problem, denn dann kann man die entstehenden "zu wenig 
zufälligen" Bits einfach wegwerfen.  Aber wenn man es nicht kann: was 
ist dann?

Autor: Michael G. (linuxgeek) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Also "on the fly" kann man sowas eher nicht erkennen, denn Du darfst 
nicht vergessen, die Wahrscheinlichkeiten fuer jedes Einzelexperiment 
sind voneinander unabhaengig gleich -- bzw. sollen es sein 
optimalerweise. Das heisst auch, dass ich vorhergehende Ereignisse nicht 
dazu benutzen kann, um auf Folgeereignisse zu schliessen, das wuerde ja 
eine Abhaengigkeit implizieren, die es nicht gibt. Und wenn Du mit einem 
Wuerfel sechs mal keine 6 wuerfelst, wird die Wahrscheinlichkeit, dass 
Du beim siebten mal eine wuerfelst, nicht groesser.

Jedoch ist die Wahrscheinlichkeit, dass Du eine spezielle Folge 
erwischst, nur 1/(alle moeglichen Folgen). Bei 1024 gewuerfelten Bits 
also die Nullfolge zu erwischen 0...0 ist sehr unwahrscheinlich, P = 
1/(2^1024). Ich habe vor mit einem Tool die Qualitaet einer solchen 
Folge zu pruefen, diverse Tests, u.a. den Chi-Quadrat-Test usw. Dass 
dieser aber auch akkurat ist, benoetigt man eine recht grosse Folge.

Man kann ja, falls wirklich mal etwas dummes passiert, im Treiber einen 
oberflaechlichen, strichprobenartigen Test (also nicht so extensiv) 
implementieren, der dann Folgen, die aus der Reihe tanzen, einfach 
verwirft. Das duerfte das Vertrauen in den Generator nochmals steigern, 
sollte aber nur in sehr wenigen Ausnahmefaellen moeglich sein.

Denn Du musst ueberlegen, selbst die besten (echten) Wuerfel koennten 
Dir eine Folge wie 1, 2, 3, 4, 5, 6 liefern, denn diese Folge ist nicht 
mehr oder weniger Wahrscheinlich als jede andere Folge aus 6 Wuerfen. 
Das Thema ist echt nicht trivial, jetzt bin ich aber beim Knuth als 
entscheidende Kompetenz dafuer ;)

Lg,
Michael

Autor: urfwanker (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Michael

Deine Tupeltests für die Rauschfolge laufen im Endeffekt auf eine DFT 
bzw. optimaler auf eine FFT hinaus, die wiederum ergeben sollte, dass es 
sich um weisses Rauschen handelt, da bleibt kein Peak verborgen, auch 
kein Einstrahlen vom NE555.

Autor: Michael G. (linuxgeek) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Es kann schon mal sein, dass man mal eine laengere Folge an Nuller oder 
Einsen wuerfelt, warum auch nicht, es gibt ja nur zwei Moeglichkeiten ;) 
Ich arbeite ein gutes Set an statistischen und probabilistischen Tests 
aus und wenn eine Folge diese besteht dann betrachtet man sie als 
hinreichend zufaellig. Wollte man wirklich eine perfekte Pruefung, 
muesste man wie oben beschrieben alle moeglichen Tupel aller moeglichen 
Groessen auf ihre Verteilung pruefen, dies ist aber schlicht und 
ergreifend durch die kombinatorische Explosion unmoeglich. Und selbst 
wenn ich N Tests anwende und die verlaufen alle gut, ist immernoch nicht 
sicher, dass bei einem N+1-ten Test die Folge total versagt, denn jeder 
Test prueft ein bisschen andere Aspekte.

Es gibt z.B. bei einer 1024-bittigen Folge etwas ueber eine halbe 
Millionen moeglichkeiten, daraus 2-Tupel zu bilden. Greift man sich nun 
einige Tausend dieser Tupel, erwartet man, dass die vier Klassen 00, 01, 
10, 11 in etwa zu je 1/4 vertreten sind. Der "Trick" dabei ist halt, ich 
greife zufaellig hinein. Eventuelle Muster bzw. Regelmaeszigkeiten 
koennen verdammt gut versteckt sein. Aber wenn man die Tests gut genug 
ausfeilt und ausserdem unterschiedliche anwendet, schrumpft die 
Wahrscheinlichkeit, dass es sich um eine nicht zufaellige Folge handelt, 
schon betraechtlich. Ausserdem weiss man ja, wie die Entropie erzeugt 
wurde, also dass da generell mal nichts gedreht wurde oder die Folge aus 
einem seminumerischen Algorithmus mit irgendwelchen Periodizitaeten oder 
moeglicherweise komischen Symmetrien stammt.

Und sollte es sich dann erweisen, dass solche Symmetrien doch vorhanden 
sind, kann man immernoch eingreifen und diese noch herauskaemmen ;)
Knuth hat eine ganze Reihe an Tests vorgestellt in seinem Buch, das 
Kapitel ueber Zufallszahlen ist 170 Seiten gross (= Manche eignen sich 
nicht so gut, da sie eher fuer stetige Zahlen gedacht sind, es gibt aber 
auch eine Reihe an diskreten Tests. Ein oder zwei davon kann man ja in 
den Treiber einbauen, um schon systemseitig gewissen Konditionen 
vorzubeugen und eventuelle Stoerungen, die doch mal auftreten koennen, 
zu erkennen und auszubuegeln.


Lg,
Michael

Autor: Florian Rist (Firma: TU Wien) (frist)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,
ich glaub der Link wurde noch nicht genannt: http://www.random.org

AFAIK gibt's da auch viele Infos zur Analyse und über Tests.

Grüße
Flo

Autor: Michael G. (linuxgeek) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Thx, da sind z.B. auch Real Time Tests vorgestellt... cool, sowas kann 
man z.B. in den Treiber einbauen (=

Autor: Christian Berger (casandro) Flattr this
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ein wichtiger Punkt ist auch, dass Dir dein Zufallsexperiment (Diode, 
Widerstand, etc) Dir eventuell weniger als ein Bit (oder Shannon) pro 
Bit Eingangsdaten liefert. Das kannst du mit einem nachgeschalteten 
Pseudozufallszahlengenerator schön ausgleichen. Nimm einfach an, jedes 
Eingangsbit hat 0,1 Bits Zufall, und Du bist auf der sicheren Seite. 
Auch wenn beispielsweise Deine Diode zu langsam ist.

Autor: Michael G. (linuxgeek) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Ein wichtiger Punkt ist auch, dass Dir dein Zufallsexperiment (Diode,
> Widerstand, etc) Dir eventuell weniger als ein Bit (oder Shannon) pro
> Bit Eingangsdaten liefert.

Erklaerung? Kann ich nicht nachvollziehen. Wenn ich den A/D-Wandler 
nehme und so ne Wandlung im Bereich von etlichen Mikrosekunden liegt 
warum sollte ich da nicht immer ein Zufallsbit bekommen?

Aber falls dergleichen wirklich etwas passiert werde ich im Treiber die 
Daten eventuell noch aufbereiten, das werde ich nicht in der Firmware 
machen. Dafuer habe ich ja die Gewaltenteilung ;)

Michael

Autor: Christian Berger (casandro) Flattr this
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Michael G. wrote:

> Erklaerung? Kann ich nicht nachvollziehen. Wenn ich den A/D-Wandler
> nehme und so ne Wandlung im Bereich von etlichen Mikrosekunden liegt
> warum sollte ich da nicht immer ein Zufallsbit bekommen?

Naja, stell Dir mal vor, die höchsten Frequenzen Deines Signales liegen 
unterhalb der halben Abtastfrequenz Deines AD-Wandlers. Dann hängen die 
Bits voneinander ab. Nehmen wir mal den Extremfall. Dein Signal ist so 
stark tiefpassgefiltert, dass es über 10 Taktzyklen weniger als ein MSB 
schwankt. Du hast dann plötzlich weniger als ein Bit pro Taktzyklus.

> Aber falls dergleichen wirklich etwas passiert werde ich im Treiber die
> Daten eventuell noch aufbereiten, das werde ich nicht in der Firmware
> machen. Dafuer habe ich ja die Gewaltenteilung ;)

Finde ich sehr unelegant.

> Michael

Servus
  Casandro

Autor: Michael G. (linuxgeek) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das MSB werde ich garnicht verwenden. Und warum sollte das ungelegant 
sein. OK eine gewisse Vorfilterung kann man ja schon mit der MCU machen 
aber aufwaendige Algorithmen duerften den AVR ueberfordern.

Ausserdem habe ich sowieso pro Taktzyklus kein Bit, das dauert eine 
komplette A/D-Wandlung lange. Ich verstehe immernoch nicht ganz, was Du 
meinst.

Michael

Autor: Christian Berger (casandro) Flattr this
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Michael G. wrote:
> Das MSB werde ich garnicht verwenden.

Ich meinte das LSB.

> Und warum sollte das ungelegant
> sein. OK eine gewisse Vorfilterung kann man ja schon mit der MCU machen
> aber aufwaendige Algorithmen duerften den AVR ueberfordern.

Nö, erstens schafft der AVR das locker. Zweitens sollte dieser Prozess 
ständig durchgeführt werden (nicht nur wenn Du Zufallszahlen brauchsts) 
und drittens möchtest Du ja einen Zufallszahlengenerator bauen, der 
Zufallszahlen ausspuckt. Ansonsten könntest Du ja auch eine 
USB-Soundkarte benutzen und dann aus den Werten deine Zufallszahl 
berechnen.

Die Hauptprobleme wirst Du wahrscheinlich eh mit USB haben.

> Ausserdem habe ich sowieso pro Taktzyklus kein Bit, das dauert eine
> komplette A/D-Wandlung lange. Ich verstehe immernoch nicht ganz, was Du
> meinst.

Mit Taktzyklus meine ich eine A/D-Wandlung.

Ich zeichne das hier mal auf: (stark vergrößertes Signal)

Abtastwerte->
|   |   |   |   |   |   |   |   | Spannungspegel \/
+---+---+---+---+---+---+---+---+
|   |   |   |   |   |   |   |   |  000001
+---+---+---+---+---+---+---+---+
|   |   |   |   |   |   |   |   |  000010
+--_+---+__-+---+---+-_-+-_-+---+
| / \_-_/  --_  |   _/ \_/ \__-_|  000011
+---+---+---+-\_+--/+---+---+---+
|   |   |   |   \_/ |   |   |   |  000100
+---+---+---+---+---+---+---+---+
|   |   |   |   |   |   |   |   |  000101
+---+---+---+---+---+---+---+---+
|   |   |   |   |   |   |   |   |  000110
+---+---+---+---+---+---+---+---+
|   |   |   |   |   |   |   |   |  000111
Erg:1   1   1   0   1   1   1   1

Das eingezeichnete Signal ist tiefpassgefiltertes Rauschen. In der 
Realität ist jedes Rauschen so gefiltert. Es sind also hohe Frequenzen 
oder schnelle Änderungen stark gedämpft. Jetzt kann es sein, dass sich 
somit das Signal nicht genügend schnell ändert.

> Michael

Autor: Esko (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Christian Berger (casandro)
> das Diodenrauschen soll angeblich nicht langzeitstabil funktionieren.

Wo hast du denn das her? Dann könnten ja die Chiphersteller ihre Dioden 
verbessern indem sie vorher "abgenutzt" werden. Das halte ich für sehr 
unwahrscheinlich.


> Man verwendet ein großes Schieberegister (evtl im Controller.) mit mög-
> lichst vielen Bits. Man verschaltet es als Pseudozufallszahlengenerator,
> taktet aber die Bits, welche man von der Schaltung bekommt noch mit rein.

Du meinst dass die aktuelle ausgelesenen Bits in den Registern die 
Adressierung der nächsten ausgelesenen Daten bestimmt!?
Das halte ich für keine gute Idee.
Das läuft auf eine Hash Funktion heraus die sich auf bewährtem Weg (mit 
bekannten Algorithmen) deutlich besser herstellen lässt.
Indem man kryptographische Sachen undurchschaubar macht werden sie oft 
nicht besser sondern schlechter. Siehe Enigma: Dort wurde der zu 
verschlüsselnde Buchstabe zweimal durch eine Walze geschickt. Man dachte 
je komplizierter der Weg desto besser. Das Gegenteil war der Fall. Der 
Schlüsselraum verkleinerte sich um 10^13 !


> Ein wichtiger Punkt ist auch, dass Dir dein Zufallsexperiment (Diode,
> Widerstand, etc) Dir eventuell weniger als ein Bit [Zufallszahlen] pro
> Bit Eingangsdaten liefert.

Das ist absolut korrekt und ein sehr wichtiger Hinweis.
Es ist sicher - trotz der sehr guten Filterung der Speisespannung - dass 
die Frequenz des 555 durchschlägt, wenn auch nur minimal. Dadurch ergibt 
sich eine Periodizität und damit eine Entropieverkleinerung.


> Das kannst du mit einem nachgeschalteten Pseudozufallszahlengenerator
> schön ausgleichen.

Nein!
Die Folge muss zwangsläufig verkürzt werden um die "verlorene" Entropie 
wieder wettzumachen.


Michael G.
> Man kann ja, falls wirklich mal etwas dummes passiert, im Treiber einen
> oberflaechlichen, strichprobenartigen Test (also nicht so extensiv)
> implementieren, der dann Folgen, die aus der Reihe tanzen, einfach
> verwirft.

Ob das möglich ist? Die Quintessenz des Zufalls ist ja eben dass er sich 
in kein Muster fügt. Wenn man nun Zahlen verwirft die dem Test nicht 
passen, dann sortiert man effektiv die Zahlen nach dem Muster des Test.

Einfaches Beispiel: Man untersucht ob in 100 Bits die Nuller häufiger 
als  60 mal oder weniger als 40 mal auftauchen. Falls das so ist geht 
man von einer Störung aus und verwirft sie.
Was hat man nun gemacht? Aus den Zufallszahlen werden vorhersehbare 
Zahlen, die keine echten Zufallszahlen mehr sind. Bei echten 
Zufallszahlen kann es durchaus vorkommen das einmal 100 Bits Null sind.


Grüße, Esko

Edit:
Sehe gerade dass noch einige Beiträge erstellt worden sind. Die 
Zeichnung von Casandro macht das Problem mit den Nicht-Zufall-Bits ganz 
gut deutlich.

Ob man die "Filterung" der Zufallszahlen (= mixen & verkürzen, nicht 
Folgen verwerfen die scheinbar nicht passen) per MC oder PC macht ist 
doch egal.

Autor: Christian Berger (casandro) Flattr this
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Esko wrote:
> Christian Berger (casandro)
>> das Diodenrauschen soll angeblich nicht langzeitstabil funktionieren.
>
> Wo hast du denn das her? Dann könnten ja die Chiphersteller ihre Dioden
> verbessern indem sie vorher "abgenutzt" werden. Das halte ich für sehr
> unwahrscheinlich.

Du betreibst Dioden außerhalb des Bereiches für den sie gebaut wurden.


> Du meinst dass die aktuelle ausgelesenen Bits in den Registern die
> Adressierung der nächsten ausgelesenen Daten bestimmt!?
> Das halte ich für keine gute Idee.
> Das läuft auf eine Hash Funktion heraus die sich auf bewährtem Weg (mit
> bekannten Algorithmen) deutlich besser herstellen lässt.
> Indem man kryptographische Sachen undurchschaubar macht werden sie oft
> nicht besser sondern schlechter. Siehe Enigma: Dort wurde der zu
> verschlüsselnde Buchstabe zweimal durch eine Walze geschickt. Man dachte
> je komplizierter der Weg desto besser. Das Gegenteil war der Fall. Der
> Schlüsselraum verkleinerte sich um 10^13 !

Das mein ich auch. Ich benutze keine Daten als Adresse, sondern nur ein 
Schieberegister, so wie es auch von anderen Hash-Funktionen verwendet 
wird. Im Prinzip läuft das auf eine Hash-Funktion hinaus. Nur so etwas 
aufwändigeres wie MD5 braucht man da nicht unbedingt.

Der Punkt ist, Du hast einen Zufallszahlenpool, hängst daran Dein Bit 
vom Zufallsexperiment und schickst das dann durch eine Funktion. Das 
Ergebnis dieser Funktion ist dein neuer Zufallszahlenpool.
Du siehst, ein rückgekoppeltes Schieberegister erfüllt den Zweck.

> Das ist absolut korrekt und ein sehr wichtiger Hinweis.
> Es ist sicher - trotz der sehr guten Filterung der Speisespannung - dass
> die Frequenz des 555 durchschlägt, wenn auch nur minimal. Dadurch ergibt
> sich eine Periodizität und damit eine Entropieverkleinerung.

Genau, ebenso könnte es sein, dass das Spektrum nicht ganz weiß ist und 
somit vermehrt längere Bitsequenzen vorkommen.

>> Das kannst du mit einem nachgeschalteten Pseudozufallszahlengenerator
>> schön ausgleichen.
>
> Nein!
> Die Folge muss zwangsläufig verkürzt werden um die "verlorene" Entropie
> wieder wettzumachen.

Du hast mich nicht verstanden!
Man könnte zwar theoretisch die Folgen verlängern, aber ich habe 
beschrieben, wie man das verhindert und dafür sorgt dass Du nicht mehr 
Entropie rausholst als reinkommt.


> Edit:
> Sehe gerade dass noch einige Beiträge erstellt worden sind. Die
> Zeichnung von Casandro macht das Problem mit den Nicht-Zufall-Bits ganz
> gut deutlich.
>
> Ob man die "Filterung" der Zufallszahlen (= mixen & verkürzen, nicht
> Folgen verwerfen die scheinbar nicht passen) per MC oder PC macht ist
> doch egal.

Bestimmte Folgen verwerfen ist eine schlechte Idee. Denn dann sinkt die 
Wahrscheinlichkeit dieser Bitfolgen auf 0. Wenn dann muss man das 
durchmixen so dass Störungen durchgemischt werden, aber nichts wirklich 
rausgeworfen wird.

Ja, prinzipiell ist es egal wo man die Nachverarbeitung macht, aber das 
sollte man wenn möglich möglichst ständig machen, so dass im 
Zufallszahlenpool ständig neue Zahlen zur Verfügung stehen. Ich finde 
einfach, was man extern machen kann sollte man auch extern machen.

Autor: Michael G. (linuxgeek) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Esko wrote:
> Christian Berger (casandro)
>> Ein wichtiger Punkt ist auch, dass Dir dein Zufallsexperiment (Diode,
>> Widerstand, etc) Dir eventuell weniger als ein Bit [Zufallszahlen] pro
>> Bit Eingangsdaten liefert.

Darin sehe ich kein Problem, um ehrlich zu sein. Dann les ich halt eine 
eins mehr, unterm Strich duerfte das absolut nichts ausmachen. Das wird 
aber die Analyse zeigen. Falls ich Probleme sehe, weiss ich ja, wo ich 
ansetzen/verbessern kann.

> Das ist absolut korrekt und ein sehr wichtiger Hinweis.
> Es ist sicher - trotz der sehr guten Filterung der Speisespannung - dass
> die Frequenz des 555 durchschlägt, wenn auch nur minimal. Dadurch ergibt
> sich eine Periodizität und damit eine Entropieverkleinerung.
>
>
>> Das kannst du mit einem nachgeschalteten Pseudozufallszahlengenerator
>> schön ausgleichen.
>
> Nein!
> Die Folge muss zwangsläufig verkürzt werden um die "verlorene" Entropie
> wieder wettzumachen.
>
>
> Michael G.
>> Man kann ja, falls wirklich mal etwas dummes passiert, im Treiber einen
>> oberflaechlichen, strichprobenartigen Test (also nicht so extensiv)
>> implementieren, der dann Folgen, die aus der Reihe tanzen, einfach
>> verwirft.
>
> Ob das möglich ist? Die Quintessenz des Zufalls ist ja eben dass er sich
> in kein Muster fügt. Wenn man nun Zahlen verwirft die dem Test nicht
> passen, dann sortiert man effektiv die Zahlen nach dem Muster des Test.
>
> Einfaches Beispiel: Man untersucht ob in 100 Bits die Nuller häufiger
> als  60 mal oder weniger als 40 mal auftauchen. Falls das so ist geht
> man von einer Störung aus und verwirft sie.
> Was hat man nun gemacht? Aus den Zufallszahlen werden vorhersehbare
> Zahlen, die keine echten Zufallszahlen mehr sind. Bei echten
> Zufallszahlen kann es durchaus vorkommen das einmal 100 Bits Null sind.

Ne ne ganz so einfach ist es dann auch nicht. Ein solcher Test waere 
natuerlich Unsinn und ausserdem haelt er keine Aussage ueber den Zufall.

In einer Folge aus 100 Bits 10101010...10 habe ich auch 50 einser und 50 
Nuller. Guter Zufall nach Deinem Test, aber das ist natuerlich Unfug.

> Grüße, Esko
>
> Edit:
> Sehe gerade dass noch einige Beiträge erstellt worden sind. Die
> Zeichnung von Casandro macht das Problem mit den Nicht-Zufall-Bits ganz
> gut deutlich.

Im Moment sehe ich darin immernoch kein Problem. Wenn Deine Muenze 3 mal 
auf die selbe Seite faellt wirst ihr ja auch nicht nachsagen, dass sie 
nicht schnell genug war, oder? Der wesentliche Punkt ist: Du kannst 
nicht wissen, wie sie das naechste mal fallen wird, ob nun gleich oder 
anders. Das ist das Wesentliche.

Aber nochmal: Falls der Zufall nicht gut genug ist komme ich darauf 
zurueck und ueberlege mir, wie man ihn verbessern kann. Aber das macht 
man im Bedarfsfall. Meistens macht man naemlich, wie schon erwaehnt, die 
Sache durch Ueberverkomplizierung nicht besser, sondern schlechter.

Michael

Autor: Christian Berger (casandro) Flattr this
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Michael G. wrote:

> Darin sehe ich kein Problem, um ehrlich zu sein. Dann les ich halt eine
> eins mehr, unterm Strich duerfte das absolut nichts ausmachen. Das wird
> aber die Analyse zeigen. Falls ich Probleme sehe, weiss ich ja, wo ich
> ansetzen/verbessern kann.

Das Problem ist einfach, dass beispielsweise dein 128Bit Schlüssel dann 
nur weniger effektive Bits hat.

>> Edit:
>> Sehe gerade dass noch einige Beiträge erstellt worden sind. Die
>> Zeichnung von Casandro macht das Problem mit den Nicht-Zufall-Bits ganz
>> gut deutlich.
>
> Im Moment sehe ich darin immernoch kein Problem. Wenn Deine Muenze 3 mal
> auf die selbe Seite faellt wirst ihr ja auch nicht nachsagen, dass sie
> nicht schnell genug war, oder? Der wesentliche Punkt ist: Du kannst
> nicht wissen, wie sie das naechste mal fallen wird, ob nun gleich oder
> anders. Das ist das Wesentliche.

Moment, stell Dir mal ein Doppelpendel vor. Und ein Bit ist jetzt ob das 
Ende des Pendels in der linken oder rechten Halbebene ist, wenn Du das 
beobachtet. Wenn das Doppelpendel (ein chaotischer Prozess) jetzt in der 
Größenordnung von 0.1-10 Hz schwingt und Du nimmst die Bits mit 1 MHz 
auf, so kannst Du zwar nicht genau sagen welches Bit danach kommt, Du 
kannst aber sagen, dass dieses Bit mit hoher Wahrscheinlichkeit genau so 
ist wie das Bit vorher.
Bei allen elektronischen Zufallsereignissen, bei denen das Rauschen als 
kontinuierliches Signal erzeugt wird hast Du dieses Problem.

> Aber nochmal: Falls der Zufall nicht gut genug ist komme ich darauf
> zurueck und ueberlege mir, wie man ihn verbessern kann. Aber das macht
> man im Bedarfsfall. Meistens macht man naemlich, wie schon erwaehnt, die
> Sache durch Ueberverkomplizierung nicht besser, sondern schlechter.

Es wird ja dadurch nicht komplizierter. Nur rohe Zufallszahlen sind 
eigentlich nie zu gebrauchen.

> Michael

Autor: spess53 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi

Vom Autor des oben erwähnten Funkamateurartikels gab es schon 2001 einen 
Beitrag. Daraus folgender Link:

http://www.gap-optique.unige.ch/prototypes/qrng/

Vielleicht hilfts.

MfG Spess

Autor: Esko (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Christian Berger (casandro)
> Esko wrote:
>> Christian Berger (casandro)
>>> das Diodenrauschen soll angeblich nicht langzeitstabil funktionieren.
>>
>> Wo hast du denn das her? Dann könnten ja die Chiphersteller ihre Dioden
>> verbessern indem sie vorher "abgenutzt" werden. Das halte ich für sehr
>> unwahrscheinlich.
>
> Du betreibst Dioden außerhalb des Bereiches für den sie gebaut wurden.

Quatsch!
Bei diesem kleinen Strom werden sie geschont wie sonst nirgends.


> Der Punkt ist, Du hast einen Zufallszahlenpool, hängst daran Dein Bit
> vom Zufallsexperiment und schickst das dann durch eine Funktion. Das
> Ergebnis dieser Funktion ist dein neuer Zufallszahlenpool.

Schieben und verknüpfen.
Aber wichtig ist eben dass der hinterher weniger Daten rauskommen als 
vorne reinkommen. Sonst hast du nichts gewonnen.


> Nur so etwas aufwändigeres wie MD5 braucht man da nicht unbedingt.

Nö, sicher nicht.

>> Nein!
>> Die Folge muss zwangsläufig verkürzt werden um die "verlorene" Entropie
>> wieder wettzumachen.
>
>Du hast mich nicht verstanden!
Nein!
> Man könnte zwar theoretisch die Folgen verlängern, aber ich habe
> beschrieben, wie man das verhindert und dafür sorgt dass Du nicht mehr
> Entropie rausholst als reinkommt.
Das geht ja auch gar nicht wenn man will, mehr Entropie rausholen wie 
man hat.


>> ... nicht Folgen verwerfen die scheinbar nicht passen ...
>
> Bestimmte Folgen verwerfen ist eine schlechte Idee. Denn dann sinkt die
> Wahrscheinlichkeit dieser Bitfolgen auf 0.

Genau das versuche ich Michael klarzumachen. Ein Test der Zufallszahlen 
während des Betriebs ist nicht möglich. Man kann nur anhand einer 
langen Folge die Wahrscheinlichkeit abschätzen dass hier eine 
Einstreuung/Störung vorliegt.

Ne ne ganz so einfach ist es dann auch nicht. Ein solcher Test waere
natuerlich Unsinn und ausserdem haelt er keine Aussage ueber den Zufall.



>> Christian Berger (casandro)
>>> Ein wichtiger Punkt ist auch, dass Dir dein Zufallsexperiment (Diode,
>>> Widerstand, etc) Dir eventuell weniger als ein Bit [Zufallszahlen] pro
>>> Bit Eingangsdaten liefert.
>
> Darin sehe ich kein Problem, um ehrlich zu sein. Dann les ich halt eine
> eins mehr, unterm Strich duerfte das absolut nichts ausmachen.

Doch eben schon. Wenn du darauf vertraust das die Bits zufällig sind, 
sie aber eine Periodizität o.ä. haben dann ist dein effektiver Schlüssel 
kürzer.

> Ne ne ganz so einfach ist es dann auch nicht. Ein solcher Test waere
> natuerlich Unsinn und ausserdem haelt er keine Aussage ueber den Zufall.

Das wollt ich ja eben sagen. Solche Tests, egal wie kompliziert sie 
sind, sind sagen nie 100% aus ob eine Reihe zufällig ist. Leichfertig 
angewandt zerstören sie die zufallszahlen. Auch der Chi² Test.

Schöner Vergleich mit dem Pendel.

Autor: Michael G. (linuxgeek) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nur dass der Vergleich mit dem Pendel hinkt, denn das waere 
Ueberabtastung, was bei den Frequenzen von ca. 15kSamples/s nicht 
passieren wird. Und sollte dem doch so sein, schraub ich die Frequenz 
halt runter, 9600kBit/s reichen jedenfalls vollkommen aus.

Und Esko: Der Test "zerstoert" garnichts, weil die Daten durch den Test 
nicht manipuliert werden.

Gruss,
Michael

Autor: Christian Berger (casandro) Flattr this
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Esko wrote:

> Schieben und verknüpfen.
> Aber wichtig ist eben dass der hinterher weniger Daten rauskommen als
> vorne reinkommen. Sonst hast du nichts gewonnen.

Richtig, aber Du kannst da ja beliebig viel oder wenig Daten rausnehmen.

>> Man könnte zwar theoretisch die Folgen verlängern, aber ich habe
>> beschrieben, wie man das verhindert und dafür sorgt dass Du nicht mehr
>> Entropie rausholst als reinkommt.
> Das geht ja auch gar nicht wenn man will, mehr Entropie rausholen wie
> man hat.

Richtig, aber man hat die Alternative, mehr 'beliebige' Zahlen raus zu 
holen. Manchmal braucht man ja auch nur 'beliebige' Zahlen, die eine 
geringe Entropie pro Bit haben.

> Doch eben schon. Wenn du darauf vertraust das die Bits zufällig sind,
> sie aber eine Periodizität o.ä. haben dann ist dein effektiver Schlüssel
> kürzer.

Vielleicht mal ein schöner Vergleich. Der Informationsgehalt hängt davon 
ab, wie wahrscheinlich es ist, dass Du das nächste Bit vorhersagen 
kannst, wenn das aktuelle Bit gegeben ist. Nehmen wir mal das 
kritisierte Beispiel, dass 'man mal ein Bit zwei mal einließt' bedeutet 
im Klartext folgendes:
Wenn eine 1 da ist, so bedeutet es, dass es wahrscheinlicher ist, dass 
eine 1 kommt als eine 0. Bei einer 0 ist es genau umgekehrt. Somit sinkt 
der Informationsgehalt, da das nächste Bit weniger überraschend kommt.

Informationen sind Überraschungen. Wenn ich sage, dass unser 
Bundeskanzler nicht schwanger ist, so ist das keine Überraschung und 
somit keine Information.


> Schöner Vergleich mit dem Pendel.

Danke.

Autor: Michael G. (linuxgeek) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ihr macht wilde Annahmen. Beim gegebenen Experiment ist der Sachverhalt 
nicht vorhersagbar. Sollte dem doch so sein, wird sich das bei der 
Analyse der Daten zeigen und dann kann man einlenken. Aber bei einem 
wilden Rauschen anzunehmen, dass es ueber mind. 70 Mikrosekunden stabil 
bleibt, ist ja wohl Unsinn. Ausserdem hat eine Pendelbewegung nichts mit 
Zufall zu tun. Der Vergleich ist weit hergeholt.

Ich werde das Signal auch mal am Scope untersuchen in den gegebenen 
Zeitbereichen... dann sieht man sowas ja auch.

Michael

Autor: Michael G. (linuxgeek) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sups die Sache verzoegert sich noch etwas, nachdem Helmi leider 
unterschiedliche Bausteine im ersten Schaltplan und zweiten verwendet 
hat, das habe ich nicht rechtzeitig bemerkt.

Danke trotzdem fuer die Rege Mitarbeit ;) Werde es weiter verfolgen.

Ach ja: Weitere Infos dann auf meiner Homepage http://coremelt.net links 
im Menue electronics/randomness.

Greets,
Michael

Autor: Michael G. (linuxgeek) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hab die Sache jetzt aufgebaut und es rauscht leider garnix... hab nen 
recht stabilen 2V-Spannungspegel am Ausgang...

Autor: Helmi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Michael

Welche Spannung hast du an der Z-Diode ?

Gruss Helmi

Autor: Michael G. (linuxgeek) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Die Spannung an der Z-Diode entspricht der Durchbruchspannung von etwas 
ueber 8V und die Diode selber rauscht auch sehr gut, der opAmp 
verstaerkt mir aber nicht das Rauschen sondern addiert mir nur ein 
Offset von knapp 2V, soll das so beabsichtigt sein?

Michael

Autor: Helmi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Michael,

wenn also die Diode rauscht dann muesste das auch an Pin3 von IC2 zu 
messen sein. An Pin 3 liegt DC-Maessig UB/2.

Dann mess mal an Pin 1 von IC2 dort musste neben einem DC-Pegel von UB/2 
das rauschen schon um 100 fach verstaerkt auftreten (ca. 50 mVss).

Jetzt an Pin 7 messen dort mueste das rauschen je nachdem wie du den 
Widerstand R6 bestueckt hast ( 1K .. 10K) das rauschen wiederum um den 
Faktor 10 .. 100 groesser sein.

Bitte mess auch mal die Spannung am C7 (Spannung von der Ladungspumpe)

Gruss Helmi

Autor: Michael G. (linuxgeek) Benutzerseite
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hi Helmi,


Also: Das Oszillogramm zeigt das Rauschen direkt an der Diode.
Die Ladungspumpe hat eine Spannung von 9.2V, an der Diode messe ich 
7.61V.
An Pin 3 vom Opamp liegen etwa UB/2, 2.3V, allerdings ist es ein 
DC-Pegel ohne nennenswertes Rauschen - und das kommt dann auch am Ende 
wieder raus. Wo koennte der Fehler liegen? Betriebsspannung am OpAmp 
messe ich 5.03V.

Autor: Helmi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Also wenn du an der Diode rauschen hast aber an Pin3 nix mehr dann sieht 
es so aus als ob der kondensator C12 (220nF) nicht vorhanden waer.

Das rauschen mit ca. 2.. 3 mV kommt ja auch in etwa hin.

Ueberpruef bitte mal den C12   (davor rauschen dahinter nix mehr) ?

Gruss Helmi

Autor: Michael G. (linuxgeek) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hm... ne der Kondensator ist da. Allerdings messe ich obiges Rauschen 
auch an der Kathode, nicht an der Anode... da liegt besagter Pegel...

Autor: Helmi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das ist richtig an der Kathode den die Anode liegt ja auf GND.
Die Kathode geht dann ueber den 220nF Kondensator an Pin3 vom IC2

Wenn du nun an der Kathode ein rauschen misst dann sollte es doch auch 
ueber den 220nF Kondensator an Pin3 zu messen sein.

Frage wie misst du eigentlich das rauschen der Diode.
Mit Tastkopfspitze an der Kathode und die Masse ueber das Massekabel des 
Tastkopfes ?

Wenn du so misst ist es schlecht.

Die Masse deines Tastkopfes schliesst du am besten so kurz wie moeglich 
an Masse an. Die Messspitze hat vorne so einen kleinen Kontaktring der 
auf Masse fuehrt. Um den wickelst du etwas Draht und loetets das andere 
Ende auf deine Platine. Das ganze sieht dann aus wie eine kleine Feder. 
So hast du den kuerzesten Weg nach Masse. Ueber das Massekabel vom 
Tastkopf mit seinem ca. 20 cm laenge holtst du dir sonst irgendwelche 
Stoerungen rein.

Gruss Helmi

Autor: Michael G. (linuxgeek) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hm ich fuerchte das wird nix... ich hab nen ganz normalen Spannungspegel 
an der Kathode. Was misst Du denn dort mit Deinem Aufbau? Dein 
Oszillogramm ist nach dem opAmp, oder?

Autor: Helmi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mein Signal ist nach  dem 2. OP
Denk daran das die rauschspannung an der Kathode sehr klein ist 1..2 mV
erst nach dem 1. OP hast du einen einigermassen vernüftigen Pegel. ca. 
50mV
Prüf bitte mal ob die OPs auch wirklich verstärken

Gruss Helmi

Autor: Michael G. (linuxgeek) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hah! Es klappt!! Der Widerstand war mit 1k viel zu klein ;) ;)

Autor: Michael G. (linuxgeek) Benutzerseite
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
(=

Autor: Michael G. (linuxgeek) Benutzerseite
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hier mal eine etwas hoehere Aufloesung. Ich gehe mal davon aus dass im 
Mittel eine A/D-Wandlung etwa 50us in Anspruch nehmen wird, lt. 
Datenblatt 17-260us. Die Werte sind zwischen 2 und 3V zu erwarten, also 
zwischen etwa 410-614. Vielleicht ist es eine gute Idee, dafuer zu 
sorgen, dass man mind. 100uS zwischen den Konversionen wartet, das 
waeren dann etwa 10.000 Konversionen pro Sekunde. Jetzt stellt sich nur 
die Frage: Werte ich nur ein Bit aus oder mehrere... ein Bit wuerde an 
sich reichen, ich habe ein sinnvolles Minimum bei etwa 9.6kBaud 
angelegt, bei 100uS wuerde das ja gut hinkommen.

Gruss,
Michael

Autor: Helmi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Michael

na ist denn schon Weihnachten ?

Welchen 1K hast du denn geaendert und in welchen Wert?

Noch ein Tipp fuer dich:

Wenn du denn LM358 gegen einen TS912 Rail to Rail OP austauscht gibst am 
Ausgang einen hoehren Pegel daher du kannst den ADC Werte bereich besser 
ausnutzen falls es dir was nuetzt.

Die Widerstandswerte die Ich dir angegeben hatte waren auch nur 
ungefaehr Werte die koennen je nach Hersteller und Charge der Z-Diode 
anders ausfallen.

Gruss Helmi

Autor: Michael G. (linuxgeek) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hy Helmi,

ja heute ist FAST Weihnachten :D
Wie es der Zufall will hab ich sogar TS912 da, gleich mal ausgetauscht 
(=
Das war der Widerstand 1..10K. Sieht sehr gut aus das Rauschen...

lg,
Michael

Autor: Michael G. (linuxgeek) Benutzerseite
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Sodali, ich hab jetzt erste Tests gemacht und ich muss sagen, ich bin 
ziemlich zufrieden ;) Ich hab das Rauschen uebrigens auch mal 
visualisiert... siehe Anhang. Der Generator verwendet jetzt pro Wandlung 
genau ein Bit an Entropie, naemlich das niederwertigste. Denn das ist 
das einzige, das auch tatsaechlich P(0) = P(1) = 1/2 hat, bei allen 
anderen Bits ist dies naemlich nicht der Fall.

Ich habe uebrigens auch mal testweise ca 50.000 mal gewuerfelt, also 6 
Zufallsklassen, hier die Verteilung:

1: 10155
2: 10147
3: 10075
4: 10107
5: 10358
6: 10254

Sieht also sehr gut aus, wie ich meine.

Lg,
Michael

Autor: Helmi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hy Michael,


jetzt ist aber Weihnachten für dich.

Gruss Helmi

Autor: Michael G. (linuxgeek) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
So isses... ;)

Autor: Michael G. (linuxgeek) Benutzerseite
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Ich hab ein tool geschrieben, das ein Bitmap generiert, hier ein 
Beispiel... (fuer's Forum nach PNG konvertiert).

lg,
Michael

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.