Quantenzufallsgenerator

Am 30.08.2013 10:43 schrieb Robert Rohling:

Diodenrauschen verstärken? Du willst zwar nichts radioaktives, aber ne BPW34 und ein Rauchmelder aus den USA sollten als Signalquelle schon mal taugen.

Wie man daraus einen ordentliche Zufall macht weiß ich auch nicht, würde mich aber mal interessieren. Wie kompensiert man Sättigungs- und Verschleißeffekte, Temperaturdrift, stellt sicher, daß gleich viele Einsen und Nullen rausfallen, etc?

Hanno

Das letzte Problem ist relativ einfach zu lösen - solange die Ereignisse unabhängig sind und nur die Rate für '0' und '1' unterschiedlich sind, kann man ausnutzen dass '01' genauso wahrscheinlich ist wie '10'.

Oliver Jennrich schrieb:

Hallo,

nur wird dann die Datenrate etwas unregelmässig wenn dazwischen mal längere Folgen von 000.. und 111.. auftreten, was ja bei Zufallszahlen durchaus zulässig ist.

Bye

Hanno Foest wrote in news:b8b5cjFcsknU1 @mid.individual.net:

Naja, es sollte schon indeterministischer Zufall dabei herauskommen. Bei radioaktivem Zerfall bin ich mir da nicht mehr so sicher.

Irgendwas Optisches mit Kristall sollte es sein. Gibts da nicht zufällig schon was Fertiges in DIP8 oder so? SCNR...

Gruß R.R.

Ja, sicher. Einen Tod muss man sterben.

Am 30.08.2013 10:43, schrieb Robert Rohling: >

Sowat?

Carsten

Ganz nett? Beim RS232 ist die Taktgenerierung über eine umständliche Schaltung mit Taktrückgewinnung aus dem empfangenen Bytes per Logikgates realisiert, mit der Begründung, ein hochfrequenter Quarz würde zu sehr einstrahlen. Kann ich mir nicht vorstellen, daß ein Low-Power Microcontroller, mit gutem Layout, da was ausmachen würde und es wäre dann auch nicht das umständliche Challenge-Response Verfahren notwendig, sondern der Microcontroller würde einfach mit maximaler RS232-Geschwindigkeit immer senden.

Und bei der USB-Variante ist der FT232 in Kombination mit dem ATtiny85 viel zu umständlich, zumal dort auch wieder völlig unnötigerweise dasselbe Challenge/Response Protokoll verwendet wurde. Einfach einen modernen ARM-Microcontroller einsetzen und eine USB-Soundkarte simulieren, die Mono-Rauschen liefert und fertig wäre der perfekte Zufallsgenerator. Keine Treiberinstallation notwendig, mit ggf. Problemen mit den virtuellen COM-Ports, wie es beim FT232 der Fall ist. Und es würde auch Anhieb in allen Audio-Programmen laufen, die Audio-Input haben, wie Audacity, was dann z.B. auch im Rohformat das aufgezeichnete speichern kann. Oder auch als Rauschquelle für Musikproduktionen (aber dafür reicht auch ein einfacher Mersenne-Twister, man hört den Unterschied nicht).

Interessant wäre auch mal, die Zahlen genauer zu analysieren. Nur die Häufigkeitkeitsverteilung und eine Bitmap die nach Augenmaß beurteilt wird, ist nicht gerade sehr aussagekräftig. Eine FFT-Analyse und ein Test per Die-Hard Tests (

Um übrigens nicht perfekte Zufallsgeneratoren zufälliger zu machen und Dinge wie Hochfrequenzeinstrahlungen herauszufiltern, kann man den Datenstrom durch einen Einweghash, z.B. SHA256, laufen lassen.

Am 30.08.2013 18:12, schrieb Frank Buss:

Garantiert wird ein Eingangsbitstream durch Anwendung einer kryptografischen Kompressionsfunktion *NICHT* "zufälliger". Hundertprozentig nicht.

Insgesamt finde ich viele Vorschläge in dem Thread schon recht gruselig. Auch die Diehard-Tests muss man entsprechend lesen können (vom Output her) und wissen, wie und was für Eingabedaten man füttern muss (und wieviel). Definitiv nichttrivial.

Wenn man schon einen TRNG braucht, dann lässt das mit ziemlicher Sicherheit auf kryptografische Applikationen schließen. Was dann an so einer (offenbar wichtigen) Ecke für Vorschläge gemacht werden ist schon einigermaßen haarsträubend.

Gruß, Johannes

Die Idee ist nicht von mir, hier eine Referenz:

In dem aufgeführten Artikel vom NIST

ist folgendes zu finden:

| These algorithms [SHA] enable the determination of a message?s | integrity: any change to the message will, with a very high | probability, result in a different message digest. This property is | useful in the generation and verification of digital signatures and | message authentication codes, and in the generation of random numbers | or bits.

Streng genommen müsste man wohl sagen, wenn ein hardwarebasierter Zufallsgenerator mit nicht-zufälligen Störungen immer noch recht zufällig ist, dann generiert die Hash-Funktion zumindest genauso zufällige Werte, wie als Eingabe der Hash-Funktion verwendet wird, aber mit besserer Verteilung. Das meinte ich mit "zufälliger machen". Praktisch gesehen wird es wahrscheinlich kein Verfahren geben, mit dem man solche Werte von Zufallswerten ohne zufällige Störungen unterscheiden können.

Ich hätte nichts dagegen, bessere Vorschläge zu hören.

Am 30.08.2013 22:32, schrieb Frank Buss:

Glaube ich dir. Und es macht auch Sinn, einen Entropie-Pool durch eine Hashfunktion zu jagen.

Was ich nach wie vor bestreite, ist, dass dadurch die Zufälligkeit (Entropie) größer wird. Das ist definitiv nicht der Fall.

Da steht in der "generation of random numbers": Gemeint ist eine

Genau, eine ideale Hashfunktion streut gleich. Zur Mischung von Entropie macht man sich das zu nutze.

Das Problem dabei ist, dass es den Usenet-gerechten Absatz der mal eben implementierungsrelevante Probleme von embedded-Krypto vollumfänglich erklärt, nicht gibt.

Angefangen von der Entropie und den RNGs in eingebetteten Systemen muss man dann u.a. feststellen können, ob und wann der RNG kompromittiert ist und entsprechende Gegenmaßnahmen einleiten. Krypto-MCUs bieten hierfür z.B. teilweise Hardware-RNGs an, die auf unterschiedlichen Prinzipien basieren und dann im Betrieb ständig gegeneinander statistisch plausibilisiert werden.

Wenn ich dann einen ordentlichen TRNG habe, ist die Frage, was ich damit machen will. Kommunikation, klar, verschlüsselt und mit gesicherter Datenintegrität. Nur: Wie machen ohne relevante Seitenkanäle? Schwierig. Da gibt es alleine dutzende Abhandlungen darüber, angefangen von Software-Mechanismen (habe eine Arbeit in Errinerung bei dem die SBoxen abgeändert und dann auf dem GF die Eingabewerte entsprechend invariant geändert wurden, sehr geschickt) bishin zu Hardware-Einheiten die man auf FPGAs synthetisiert, um DPA zu erschweren.

Wenn man asymmetrische Handshakes macht kommt noch ein RIESEN Fass dazu, das man aufmacht. Operator Blinding ist nichttrivial und löst auch nur einen Teil des Problems. Eine Montgomery-Reduction so hinzubekommen dass weder aus Timing- noch aus Powergraphen signifikante Informationen abgeleitet werden können ist wirklich kompliziert. Und die implemeniert man ja üblicherweise nicht selber, sondern sie ist Teil der modexp-Funktion der jeweiligen MP-library. Die üblicherweise nicht dafür geschrieben sind, dass Seitenkanäle überhaupt als relevant betrachtet werden.

Grundsätzlich würde ich zusammenfassen: Leute die glauben, sie können handgestrickte Krypto selber bauen, unterschätzen entweder die Schwierigkeit enorm oder bauen sicher aussehende unsichere Systeme. Eine gute Orientierung, wie man Krpytosysteme selber baut, ist z.B. TLS. Und selbst bei denen gibts immer wieder Schnitzer (BEAST, CRIME, Lucky 13, etc). Als Handbuch für die reinen Algorithmen ist das "Handbook of Applied Cryptography" von unschätzbarem Wert. Für die ganzen Seitenkanalattacken dann die zahlreichen Papers von Paar (RUB) oder grundsätzlich so ziemlich alle Papers der CHES.

Insgesamt hoffe ich jetzt nicht zu pampig geklungen zu haben. So wars wirklich nicht gemeint. Aber es ist einfach ein wirklich komplexes Thema und je länger ich mich damit beschäftige umso mehr merke ich wie umfangreich das Feld ist.

Um die Stimmung aufzuheitern kann ich dazu raten, nach Vollbitverschlüsselung vom Kryptochef höchstpersönlich zu suchen :-)

Viele Grüße, Johannes

Ging erstmal nur um die Erzeugung von Zufallszahlen. Da gibt es Tests usw. für und kann man unabhängig von Kryptographieanwendungen betrachten.

Das klingt nach einer guten Idee. Also z.B. einen Zufallsgenerator der mit Zenerdiodenrauschen arbeitet und einer der optisch arbeitet und dann die beiden Generatoren per xor verknüpfen?

Hier übrigens eine Arbeit zu einem optischen Zufallsgenerator, der das Eintreffen einzelner Photonen auswertet:

U.a. zur Zenerdiode (falsch geschrieben im Artikel) schreiben die Autoren allerdings:

| Only the complexity of the often chaotic evolution makes it impossible | to predict the bit sequence with today?s technology. Quantum physics | provides inherent randomness and nondeterminacy.

Aber ist das Rauschen der Zenerdiode nicht auch ein Quanteneffekt? Oder das thermische Rauschen von Widerständen?

Hanno Foest wrote in news: snipped-for-privacy@mid.individual.net:

Das ist schon ein ordentlicher Zufall.

Dass gleich viele Einsen wie Nullen rausfallen, kann man nicht steuernd gewährleisten, weil dies dann ein systematischer Eingriff in den Zufall wäre, wodurch es kein Zufall mehr wäre.

Der physikalische Zufallsprozess muss das hergeben.

Den reinen Zufall gibt es nur in quantischen Prozessen. Alles andere ist lediglich systemischer Zufall.

Juergen Vogel wrote in news:XnsA22D62D4FE350hfhggftz@

Ganz richtig! Eigentlich wollt ich ja nur was als "putergestützter Entscheidungshelfer" basteln. (ich treff in letzter Zeit immer so blödsinnige Entscheidungen, da bräucht ich mal was, was auf eine fundamentalere Ebene zurückgreift und jegliche Kausalität ausschließt...rotfl)

Gruß R.R.

a) zweifelhafter Realname des ursprünglichen Fragestellers beflügelt Diskussionen nicht. b) es ist eine typische DAU-Frage, da es kaum reale Anwendungen für nicht-PRNG Generatoren gibt. c) Literatur ist heute spärlicher, aber z.B. die IEEE-reprints in Gupta "Electrical Noise: Fundamentals and Sources" IEEE Press 1977 behandeln auch analoge/physikalische Generatoren noch.

Die Z-Dioden Variante wird absehbar mit geringem Aufwand "schlechtes" Rauschen erzeugen.

Forrest Mims III ( Leserbrief IEEE Spectrum June 1987 ) scheint radioaktiv glücklich geworden zu sein: "The radioactive decay technique for generating truly random numbers is easily implemented with a Geiger counter, a 50-cent Coleman lamp mantle ( a thorium impreganted radioactive source ) and any computer with a joystick input..." Er hat zur Auswertung den Bildschirm als XY-Plot vollgeschrieben, ein Verfahren das auch Bell Labs in den 80ern zur Bewertung empfiehlt. Radioaktive Generatoren sind wohl in den 50er/60ern häufiger an Mainframes verwendet worden. Allerdings eben nicht so häufig als daß man in der Literatur viel Auswertungen findet. Wäre aber mit buntem Plot auf C64er sicher mal eine Gag-Schaltung fürs Vintage Computer Festival in München. Jenseits dessen würde ich aber nicht viel Anwendung sehen.

MfG JRD

Am 31.08.2013 10:16, schrieb Rafael Deliano:

ev. noch: "Rauschen als Information", Wolfgang Denda, Hüthig, ISBN_3-7785-1663-9

Falls du das Buch hast, dann kannst du damit gut Geld verdienen :-)

In welcher Hinsicht schlecht? Und würde es eine Hashing-Funktion verbessern?

Ich würde mal vermuten, daß die Datenrate dabei nicht allzu hoch sein wird, falls man nicht gerade was stark strahlendes zur Hand hat.

Robert Rohling wrote in news:kvpsh8$n7v$ snipped-for-privacy@news.albasani.net:

Ja klar rote Farbe sollte schon rot sein ;-)

Kennst du auch noch anderen Zufall ausser "inderterministischem"?

Aber der intelligente Rest der Welt ist sich dabei sicher.

".... ...." wrote in news:XnsA22D6C853AB85sdgj43@130.133.4.10:

Ich weiß ja jetzt nicht, was DU so persönlich unter Intellenz verstehst.

Gruß R.R.

Klein, aber empfehlenswert: Ehrenstrasser "Stochastische Signale und ihre Anwendung" Uni Taschenbücher 1974

Alle drei Bücher behandeln zwar Hf-Rauschdioden, aber nicht Z-Diode. Weil die als Hauptquelle eben nicht gut tut.

Da die heutigen 16 Bit A/D-Wandler bis uV runtermessen, hatte ich kürzlich Feindberührung mit 3 Z-Dioden ( 3,3V 4,7V 9,1V ) die die Referenzspannungen im 24V Eingangsteil einer Sensorschaltung machten die verrauscht war. Nach etwas Grübeln parallel zu allen Z-Dioden 100nF Kerkos gelötet: etwas besser aber noch nicht Ruhe. Wirksamer nächster Schritt war dann die 9,1V durch zwei in Serie geschaltete 4,7V zu ersetzen. (Zener-)Z-Dioden rauschen anscheinend deutlich weniger als (Avalanche-)Z-Dioden.

MfG JRD