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

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

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

Basis-Emitterstrecken von Schalttransistoren machen auch ganz schön
"Krawall".

MfG Paul

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

>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

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...

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

@Michael G. (linuxgeek)

Hier noch ein paar Links zu Rauschgeneratoren


http://www.mydarc.de/dk3wi/html/noise_generator.html
http://www.maxim-ic.com/appnotes.cfm/appnote_number/3469
http://sound.westhost.com/project11.htm
http://www.techlib.com/electronics/pinknoise.htm

Gruss Helmi

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...

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

Gibt es irgendwo Beispielschaltungen?

>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ß

> 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...

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?

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

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.

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

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?

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.

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.

>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.

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

Hi

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

MfG Spess

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

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

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

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

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

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?

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.

@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

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.

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

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.

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

Paul

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.

>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

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.

Hm, da rauscht leider garnichts... Aufbau scheint augenscheinlich
korrekt.

@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

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

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.

@Michael G. (linuxgeek)


Hier noch ein Bildchen vom Signal

Gruss Helmi

Fuer was ist eigentlich der Timer da? Kann man den durch einen NE555
ersetzen?

Michael

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

@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

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

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

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.

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

@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

Hatte ich irgendwas anderes behauptet? Der Zweck scheint klar...

@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

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?

@Michael G. (linuxgeek)

Ich meinte mein Foto vom Signal

Gruss Helmi

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

Greets,
Michael

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

Gruss Helmi

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

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

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.

@Michael G. (linuxgeek)

Hallo Michael

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

Gruss Helmi

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

@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

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...

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.

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.

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

@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

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

@Michael G. (linuxgeek)


Ooh Danke der Ehre

Helmi  -- >  Helmut Lenzen

thx Michael

wie heisst denn deine Page ?

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...

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

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

@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

Hmm... ok egal nun ;)

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

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

>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.

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.

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

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

@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

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.

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

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.

Falls dies noetig ist, koennen wir nochmal drueber reden... ;)

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

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

>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?

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

@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.

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

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

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

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.

> 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

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

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

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

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.

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.

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

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

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

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.

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

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.

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

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

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

Hallo Michael

Welche Spannung hast du an der Z-Diode ?

Gruss Helmi

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

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

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.

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

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

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

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?

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

Hah! Es klappt!! Der Widerstand war mit 1k viel zu klein ;) ;)

(=

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

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

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

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

Hy Michael,


jetzt ist aber Weihnachten für dich.

Gruss Helmi

So isses... ;)

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

lg,
Michael