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/articles/i1036/103659_7lo.jpg 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.
Angehängte Dateien:
-
rausch.jpg
32 KB
@Michael G. (linuxgeek) Hier noch ein Bildchen vom Signal Gruss Helmi
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
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
Angehängte Dateien:
-
noise.png
3,3 KB
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 ;) ;)
Angehängte Dateien:
-
noise3.png
2,4 KB
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
Angehängte Dateien:
-
noise_digital.png
22 KB
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
Angehängte Dateien:
-
noise.png
33 KB
Ich hab ein tool geschrieben, das ein Bitmap generiert, hier ein Beispiel... (fuer's Forum nach PNG konvertiert). lg, Michael
Thread beobachten
Seitenaufteilung abschalten
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.