Hallo zusammen! Wie es der Titel schon sagt, brauche ich in meinem atmega gute Zufallszahlen, die einfach, schnell und sicher erzeugt werden. Derzeit nutze ich den ADC und lasse den für eine 32 Bit Zahl 32 mal durchlaufen und verkette das LSB jedes Durchlaufs zur Zahl. Das ist aber 1. langsam und 2. blockiert es den ADC. Und ob diese Zahl dann wirklich zufällig ist, habe ich nicht wissenschaftlich geprüft. Frage deshalb: Gibt es fertige Bausteile, die für diese Aufgabe gemacht sind? Entweder direkt einen SPI-IC, oder ein aktives Bauteil, welches ein digitales Rauschen (CMOS-Pegel) ausgibt, welches man direkt mit dem atmega einlesen kann.
Quelle: https://www.ibbergmann.org/ZUFALLSGENERATOREN/ Anschluß über RS232 oder USB. Preis: ab 20€
:
Bearbeitet durch User
Wenn Du einen A/D-Wandler frei hast, kannst Du den doch verwenden. Relativ hochohmig, mit der noch nicht richtig stabilisierten Versorgungsspannung, verbunden und da das letzte Bit verwenden. Kost' fast nix.
Nur einmal beim Hochlauf einen PRNG-Algorithmus mit ausreichend Bits aus dem ADC seeden und dann nur noch den PRNG nutzen.
Sebastian S. schrieb: > Wenn Du einen A/D-Wandler frei hast, kannst Du den doch verwenden. > Relativ hochohmig, mit der noch nicht richtig stabilisierten > Versorgungsspannung, verbunden und da das letzte Bit verwenden. > Kost' fast nix. Die Frage ist ob wirkliche, einwandfrei Zufallszahlen sind. Z.B. gleich viele Nullen wie Einsen. Am besten mit den Daten ein Bild am PC zeichnen und schauen ob es irgendwelche Muster zu sehen gibt.
:
Bearbeitet durch User
@Gerald K. >Die Frage ist ob wirkliche, einwandfrei Zufallszahlen sind. Z.B. gleich >viele Nullen wie Einsen. Sorry! Wo bleibt denn da noch Platz für Zufälligkeit?
MaWin schrieb: > Nur einmal beim Hochlauf einen PRNG-Algorithmus mit ausreichend Bits aus > dem ADC seeden Das ist der schwierige Teil. Was aus einem ADC tröpfelt, tröpfelt eben erstens nur und ist zweitens typisch alles andere als wirklich zufällig. Einfach mal aufzeichnen und durch eine FFT jagen, dann sieht man das sofort problemlos... > und dann nur noch den PRNG nutzen. Ja klar. Das ist dann der weitaus einfachere Teil. PRNGs beweisbarer Güte gibt es reichlich.
Jan schrieb: > Wie es der Titel schon sagt, brauche ich in meinem atmega gute > Zufallszahlen Wie gut?
Jan schrieb: > Wie es der Titel schon sagt, brauche ich in meinem atmega gute > Zufallszahlen, die einfach, schnell und sicher erzeugt werden. Wie gut, wie einfach, wie schnell und wie sicher? Auf der Achse "einfach" bist du nämlich schon ziemlich gut. Viel besser wird das nur, wenn du einen µC mit integriertem Hardware-RNG verwendest, z.B. PIC32: http://ww1.microchip.com/downloads/en/DeviceDoc/60001246B.pdf Muss es kryptographischer Zufall sein? Wie viel natürlicher Zufall muss es sein? Wie viele Zufallszahlen werden benötigt? Spricht etwas dagegen, die notwendige Entropie beim Flashen zu erzeugen und zu speichern? Wie so oft wäre ein bisschen Kontext auch sinnvoll, d.h. wofür diese Zufallszahlen verwendet werden sollen.
Sebastian S. schrieb: > @Gerald K. >> Die Frage ist ob wirkliche, einwandfrei Zufallszahlen sind. Z.B. gleich >> viele Nullen wie Einsen. >> Sorry! Wo bleibt denn da noch Platz für Zufälligkeit? Bei einem idealen Würfel sollte nach unendlich vielen Würfen jede Zahl mit einem 1/6 der Gesamtanzahl der Würfe vedtreten sein. Andernfalls wäre der Würfel gezinkt. https://www.frustfrei-lernen.de/mathematik/wuerfel-stochastik-wahrscheinlichkeitsrechnung.html Binäre Zufallszahlen entsprechen Münzwürfe. Bei einer unendlichen Anzahl von Münzwurfen sollte die Anzahl Kopf und Adler gleich sein. https://de.m.wikipedia.org/wiki/M%C3%BCnzwurf
:
Bearbeitet durch User
Gerald K. schrieb: > Die Frage ist ob wirkliche, einwandfrei Zufallszahlen sind. Z.B. gleich > viele Nullen wie Einsen. DAS sind aber keine Zufallszahlen mehr, da sie einem Regelwerk folgen...
Nur das letzte Bit vom ADC einlesen und sammeln erzeugt keine gleichverteilten Zufallszahlen. Das einzelne eingelesene Bit mag einer Gleichverteilung unterliegen. Allerdings ist das Sammeln gleichzusetzen mit einer gewichteten Addition von Gleichverteilten Zufallszahlen und da kommt schon mal eine Gauß-Verteilung raus. D.h. deine Zufallszahlen sind schon mal Gaußverteilt. Erzeuge einfach mal 100.000 Zahlen und analysiere sie. Du wirst staunen.
Guest schrieb: > Gerald K. schrieb: >> Die Frage ist ob wirkliche, einwandfrei Zufallszahlen sind. Z.B. gleich >> viele Nullen wie Einsen. > > DAS sind aber keine Zufallszahlen mehr, da sie einem Regelwerk folgen... Doch, "gleich viele" ist die flapsige Formulierung für die Wahrscheinlichkeiten von jeweils 0,5. Das Gesetz der großen Zahlen sagt dann, dass es bei sehr vielen Würfen auch gleich viele sind (von einer Ɛ-Abweichung abgesehen). Wenn man testen will, ob das "anständiger Zufall" ist wird man es auch genau so testen. (Das ist einer von vielen möglichen Tests).
1234567890 schrieb: > Nur das letzte Bit vom ADC einlesen und sammeln erzeugt keine > gleichverteilten Zufallszahlen. Das einzelne eingelesene Bit mag einer > Gleichverteilung unterliegen. Allerdings ist das Sammeln gleichzusetzen > mit einer gewichteten Addition von Gleichverteilten Zufallszahlen und da > kommt schon mal eine Gauß-Verteilung raus. D.h. deine Zufallszahlen sind > schon mal Gaußverteilt. Erzeuge einfach mal 100.000 Zahlen und > analysiere sie. Du wirst staunen. Sorry: 100.000 Zahlen bei 32 bit reichen noch nicht. Für einen halbwegs sichtbaren Effekt brauchst du ca. 25*2^32 Zahlen.
1234567890 schrieb: > Erzeuge einfach mal 100.000 Zahlen und analysiere sie. Du wirst staunen. Genau so ist es. Wenn die Rauschspannung kleiner als die kleinste Stufe des ADCs ist, wird es mehr Nullen als Einsen geben. Wenn die Eingangspannung mit einem Netzbrumm überlagert ist, dann wird sich das in der Verteilung der Zufallzahlen wiederfinden.
Gerald K. schrieb: > Bei einem idealen Würfel sollte nach unendlich vielen Würfen jede Zahl > mit einem 1/6 der Gesamtanzahl der Würfe vedtreten sein. Andernfalls > wäre der Würfel gezinkt. Das Problem bei einem Würfel ist, dass die Zahlen durch gebohrte Vertiefungen dargestellt werden. Daher hat die 6 eine höhere Wahrscheinlichkeit als - im anderen Extrem - eine 1. mfg mf
Ob Gleichverteilung überhaupt notwendig ist, hängt von der (wie immer geheimen) Anwendung ab. In den meisten Fällen ist sie es nicht. Der natürliche Zufall initialisiert einen PRNG - der ist dann gleichverteilt.
Heiner schrieb: > Der natürliche Zufall initialisiert einen PRNG - der ist dann > gleichverteilt. Einem PRNG mit rückgekoppelten Schieberegistern fehlt ein Zustand
Die Anforderungen an Zufallszahlen sind sehr vielfältig; ohne etwas mehr Kontext kann man dazu nicht viel sagen. Kryptographie wurde schon genannt. Ich glaube nicht, dass das Deine Anwendung ist, sonst hättest Du die Anforderungen besser spezifiziert. Für Monte-Carlo Anwendungen auf einer einzigen CPU ist die Länge der benötigten Sequenz entscheidend. Ist das Dein Problem? Wenn es nur darum geht, in einem Spiel den Space Invader an einer zufälligen Stelle erscheinen zu lassen, sind die Anforderungen viel einfacher. Also: Anwendung beschreiben!
Achim M. schrieb: > Das Problem bei einem Würfel ist, dass die Zahlen durch gebohrte > Vertiefungen dargestellt werden. Daher hat die 6 eine höhere > Wahrscheinlichkeit als - im anderen Extrem - eine 1. Warum fehlt manchen Leuten immer die Fähigkeit zur Abstraktion?
Hallo 1234567890, 1234567890 schrieb: > 1234567890 schrieb: >> Nur das letzte Bit vom ADC einlesen und sammeln erzeugt keine >> gleichverteilten Zufallszahlen. Das einzelne eingelesene Bit mag einer >> Gleichverteilung unterliegen. Allerdings ist das Sammeln gleichzusetzen >> mit einer gewichteten Addition von Gleichverteilten Zufallszahlen und da >> kommt schon mal eine Gauß-Verteilung raus. D.h. deine Zufallszahlen sind >> schon mal Gaußverteilt. Erzeuge einfach mal 100.000 Zahlen und >> analysiere sie. Du wirst staunen. > > Sorry: > 100.000 Zahlen bei 32 bit reichen noch nicht. Für einen halbwegs > sichtbaren Effekt brauchst du ca. 25*2^32 Zahlen. welchen Sinn macht es, das niedrigwerteste Bit eines ADC x-mal aufzusummieren um gleichverteilte Zufallszahlen zu erzeugen, wenn dem zentralen Grenzwertsatz nach das nicht gleichverteilte Ergebnis doch schon bekannt ist? Wenn ich Zugriff auf einen zufälligen Bitstream habe, dann fülle ich damit sequentiell z.B. einen 32-Bit-Wert, also z.B. per 32-maligem [Hochshiften und Addition des aktuellen "Stream"-Bits]. Was Du beschreibst ist kein Sammeln, sonder zielgerichtete Manipulation der Zahlen.
:
Bearbeitet durch User
Es geht um Kryptographie. Die Zufallszahlen müssen also kryptographisch sicher sein, damit der Initialisierungsvektor im CBC-Modus unvorhersehbar ist. Leider haben die ehemaligen Atmels keine PRNGs eingebaut, nichtmal die mit Hardware AES. Ich will da auch keine grosse Schaltung anhängen. Ein einzelnes Bauteil muss reichen. Maximal zwei. Diode und Widerstand mit integriertem AC des atmega? Am liebsten wäre mir was integriertes. Keine Bastellösung. Dummerweise haben die dicken Brummer alle schon PRNGs eingebaut, und die 8-Bitter nimmt man heute wohl nur noch für Spielereien. Das ist wohl der Grund, warum ich bis jetzt nichts finden konnte. Schade.
Guest schrieb: > DAS sind aber keine Zufallszahlen mehr, da sie einem Regelwerk folgen... 11011101111010000000 und 01100001110101001110 enthalten beide gleich viele Einsen und Nullen ;-) P.S. sicher nicht zufällig sondern zehn Einsen hingemalt und mit der Maus hier und da einige Nullen hingezugefügt, bis es auch zehn waren.
:
Bearbeitet durch User
Jan schrieb: > Diode und Widerstand mit integriertem AC des > atmega? Eine kleine Antenne, an den ADC Pin, dann strömt das ganze Universum auf den ADC ein. Da soll sich dann wohl das ein oder andere flatternde Bit finden.
EAF schrieb: > Eine kleine Antenne, an den ADC Pin Ja, das ist dann immer besonders nett, wenn ein Oberschlaumeier, der keine Ahnung von Kryptographie hat, für den Penetration Tester direkt eine Eingabemöglichkeit für die Zufallszahlen vorsieht.
1234567890 schrieb: > Das einzelne eingelesene Bit mag einer > Gleichverteilung unterliegen. Allerdings ist das Sammeln gleichzusetzen > mit einer gewichteten Addition von Gleichverteilten Zufallszahlen und da > kommt schon mal eine Gauß-Verteilung raus. D.h. deine Zufallszahlen sind > schon mal Gaußverteilt. Erzeuge einfach mal 100.000 Zahlen und > analysiere sie. Du wirst staunen. Das verstehe ich nicht: Wenn Du eine Folge von gleichverteilten Bits hast, also einen idealen Münzwurf, wie sollte eine daraus erstellte Binärzahl (erster Wurf bit 0, zweiter Wurf bit 1, ...) nicht gleichverteilt sein?
Jan (Gast) schrieb: > Dummerweise haben die dicken Brummer alle schon PRNGs eingebaut, > und die 8-Bitter nimmt man heute wohl nur noch für Spielereien. Ein PRNG mit guter Zufallsverteilung und ausreichend langem, nicht einfach nachvollziehbarem Zyklus und Ablauf ist auch mit einem Tiny25 locker zu erstellen. Die PRNGs der dicken Brummer sind meist keine Hardware, sondern oft recht simple Standardfunktionen der Firmware, oder des Compilers/Interpreters. Als Problem bleibt ein wirklich (!) zufälliger Startwert (Seed). Den bringen die dicken Brummer auch nicht mit. Auch nicht mit der SEED() Funktion o.ä. Oft wird aktuelles Datum / Uhrzeit (wenn vorhanden) mit ein paar Benutzer-Reaktionen verwürfelt. - Das hilft aber nicht, wenn die Geschichte autark anlaufen soll. Eine Antenne, oder andere Umweltsensoren könnten beeinflussbar sein. Ein leicht radioaktives Präparat + Geiger-Zählrohr macht SEHR gute Zufallszeiten, ist aber SEHR aufwändig! Das Rauschen auf der Durchbruchsspannung von Diodenstrecken kann auch guten Zufall liefern und ist etwas weniger aufwändig. Aber es braucht mehr als 3,3 V (eher 12 V), einen geregelten Verstärker, sowie gute Abblockung / Abschirmung um nicht beeinflussbar zu werden. Darum wirst du wohl nicht so leicht fündig... Weiteres Problem: Wie bringst du die GUTEN Startwerte ausspähsicher und unverfälschbar an den Empfänger?.
Jan schrieb: > Es geht um Kryptographie. Die Zufallszahlen müssen also kryptographisch > sicher sein, damit der Initialisierungsvektor im CBC-Modus > unvorhersehbar ist. Nochmal die Frage: Was spricht dagegen, die erforderliche Entropie beim Flashen zu erzeugen? Ansonsten ist die Frage, ob man in dieser Anwendung damit rechnen muss, dass ein Angreifer gezielt durch Einstreuung o.ä. den ADC manipuliert. Das erscheint mir doch eher unwahrscheinlich. Jan schrieb: > Leider haben die ehemaligen Atmels keine PRNGs > eingebaut, nichtmal die mit Hardware AES. Ähem, welcher soll das sein? So etwas braucht man aber nicht unbedingt in Hardware. Für Embedded ist z.B. Xorshift+ 128 gut geeignet, einfach, wenig Speicherintensiv, kryptografisch sicher: https://de.wikipedia.org/wiki/Xorshift#Xorshift+ Wenn dich Kryptografie auf den AVRs insgesamt interessiert, möchtest du vielleicht das hier anschauen: https://git.cryptolib.org/avr-crypto-lib.git https://wiki.das-labor.org/w/AVR-Crypto-Lib/en Davon abgesehen ist echte Kryptografie nicht gerade eine Anwendung für einen 8-Bitter mit ein paar MIPS. Einen TLS-Handshake in einer halben Stunde braucht kein Mensch ... Jan schrieb: > Dummerweise haben die dicken Brummer alle schon PRNGs eingebaut, und die > 8-Bitter nimmt man heute wohl nur noch für Spielereien. Das ist wohl der > Grund, warum ich bis jetzt nichts finden konnte. Schade. Inwiefern würde der o.g. Xorshift+ von einer Hardwareunterstützung profitieren? Jan schrieb: > Diode Das Rauschen einer Diode kann man auch verwenden, so macht das afair der PIC32, ein allgemein übliches Verfahren. Ist aber weder einfacher noch letztendlich besser (egal nach welcher Metrik) als das Rauschen des ADC zu verwenden. So oder so ist das Ergebnis dieser Geschichten nicht direkt als RNG geeignet, sondern liefert nur die Anfangsentropie für einen PRNG.
Heiner schrieb: > Jan schrieb: >> Es geht um Kryptographie. Die Zufallszahlen müssen also kryptographisch >> sicher sein, damit der Initialisierungsvektor im CBC-Modus >> unvorhersehbar ist. > > Nochmal die Frage: Was spricht dagegen, die erforderliche Entropie beim > Flashen zu erzeugen? Bei jedem Reset wäre der Initial-Seed identisch. Das geht so nicht. Man müsste das dann ins EEPROM speichern, was mit etwas Aufwand aber in der Tat eine Möglichkeit wäre.... hmmmm > Jan schrieb: >> Leider haben die ehemaligen Atmels keine PRNGs >> eingebaut, nichtmal die mit Hardware AES. > > Ähem, welcher soll das sein? Die komplette xmegaxxxAxU Serie und, gerne übersehen, der xmega384C3. > So etwas braucht man aber nicht unbedingt in Hardware. Für Embedded ist > z.B. Xorshift+ 128 gut geeignet, einfach, wenig Speicherintensiv, > kryptografisch sicher: > > https://de.wikipedia.org/wiki/Xorshift#Xorshift+ Kombiniert mit dem eeprom könnte das in der Tat funktionieren :) Guter Tipp. Danke. > Davon abgesehen ist echte Kryptografie nicht gerade eine Anwendung für > einen 8-Bitter mit ein paar MIPS. Einen TLS-Handshake in einer halben > Stunde braucht kein Mensch ... Gott sei Dank geht es hier nur um symmetrische Verschlüsselung. Da ist der noch ausreichend gut dabei.
Ich habe einfach mal gegoogelt. Da gibt es einen Hardware Random Number Generator auf einer Platine. Die kann man wohl ganz einfach über I2C ansprechen. Der Preis soll 15$ sein. Also dranlöten und fertig? https://www.mikroe.com/rng-click
PittyJ schrieb: > Also dranlöten und fertig? > > https://www.mikroe.com/rng-click Hier ist der Schaltplan. Vereint die Nachteile der ADC-LSB-Rausche-Lösung mit dem Nachteil eines Potis, mit dem man die Warscheinlichkeiten direkt verstellen kann mit dem Nachteil des I²C-Busses, den man ganz leicht abhören und manipulieren kann.
> Am besten mit den Daten ein Bild am PC zeichnen und schauen ob es > irgendwelche Muster zu sehen gibt. Ja, so wird es gemacht
Man speichert einfach vor jedem Abschalten den aktuellen Wert des PRNG im EEPROM als nächsten Startwert. Unterspannungserkennung geht beim AVR ganz einfach über das Messen der 1,1V Bandgap mit VCC als ADC-Referenz. Oder man speichert jeden Wert des PRNG in einem EERAM, FRAM oder MRAM, z.B. 47C04.
Cloud flare hat mehrere Zufallszahlengeneratroren. In der Lobby jedes größeren Büros einen. In dem einen stehen ein paar hundert Lava Lampen, in nem anderen jede Menge chaotische Pendel. Davon wird ein Bild gemacht und ein Hash berechnet. https://blog.cloudflare.com/randomness-101-lavarand-in-production/ Wenn du den Controller ans Internet anbindest kannst du dir sogar einfach eine wahre Zufallszahl runterladen. Zum Beispiel via ESP32.
Jens G. schrieb: > Achim M. schrieb: > >> Das Problem bei einem Würfel ist, dass die Zahlen durch gebohrte >> Vertiefungen dargestellt werden. Daher hat die 6 eine höhere >> Wahrscheinlichkeit als - im anderen Extrem - eine 1. > > Warum fehlt manchen Leuten immer die Fähigkeit zur Abstraktion? Warum verkennen manche Leute vor lauter Abstraktion die Realität? mfg mf
MaWin schrieb: > Nur einmal beim Hochlauf einen PRNG-Algorithmus mit ausreichend Bits aus > dem ADC seeden und dann nur noch den PRNG nutzen. Hardwerker sagen LFSR zum PRNG ;-) https://de.wikipedia.org/wiki/Linear_r%C3%BCckgekoppeltes_Schieberegister Kann man auch simple in Software nachstellen. BTW, was in der WP unter PRNG steht ist für Praktiker unbrauchbar: https://de.wikipedia.org/w/index.php?title=PRNG
Fpgakuechle K. schrieb: > Hardwerker sagen LFSR zum PRNG ;-) > > https://de.wikipedia.org/wiki/Linear_r%C3%BCckgekoppeltes_Schieberegister LFSR ist eine Methode, um einen PRNG zu implementieren
Gerald K. schrieb: > Sebastian S. schrieb: >> Wenn Du einen A/D-Wandler frei hast, kannst Du den doch verwenden. >> Relativ hochohmig, mit der noch nicht richtig stabilisierten >> Versorgungsspannung, verbunden und da das letzte Bit verwenden. >> Kost' fast nix. > > Die Frage ist ob wirkliche, einwandfrei Zufallszahlen sind. Z.B. gleich > viele Nullen wie Einsen. Das ist bei physischen Messwerten, die Zufalle enthalten, oft ein Problem. Es ist aber lösbar. Eine Suche nach "random number" zusammen mit "de-biasing" oder "postprocessing" liefert ein paar Paper zu dem Thema.
Sebastian S. schrieb: > Wenn Du einen A/D-Wandler frei hast Den Teil hast du schon gelesen? "Derzeit nutze ich den ADC"
J. T. schrieb: > Guest schrieb: > >> DAS sind aber keine Zufallszahlen mehr, da sie einem Regelwerk folgen... > > 11011101111010000000 > und > 01100001110101001110 > enthalten beide gleich viele Einsen und Nullen ;-) > P.S. sicher nicht zufällig sondern zehn Einsen hingemalt und mit der > Maus hier und da einige Nullen hingezugefügt, bis es auch zehn waren. Eben! Durch das Regelwerk ist ausgeschlossen, dass eine Zufallszahl a la 1101011110111110 erzeugt werden könnte. Somit ist das nicht mehr zufällig.
Guest schrieb: > Eben! Durch das Regelwerk ist ausgeschlossen, dass eine Zufallszahl a la > 1101011110111110 erzeugt werden könnte. Somit ist das nicht mehr > zufällig. Man kann auch absichtlich missverstehen, wenn man will. Er hat sicher nicht gemeint, dass jede einzelne Zufallszahl gleiche viele Nullen und Einsen enthalten muss, sondern bezog das auf eine große Menge von Zufallszahlen.
Eine andere Möglichkeit ist, einen Ringoszillator aus CMOS-Gattern zu bauen, z.B. aus einem HCT14. Die Daten werden einfach über einen Digitalpin periodisch "eingelesen". Mit einem zweiten Pin kann man den Oszillator auch über die 2.Eingänge des HCT14 abschalten, wenn man ihn nicht mehr braucht. Allerdings habe ich das immer nur für die Gewinnung des Seed benutzt und nicht direkt als "Zufallsdaten". Jörg
Jan schrieb: > Leider haben die ehemaligen Atmels keine PRNGs Der PRNG ist auch nicht dein Problem. Dessen Seed ist es, also zB ein TRNG.
Stefan ⛄ F. schrieb: > Er hat sicher nicht gemeint, dass jede einzelne Zufallszahl gleiche > viele Nullen und Einsen enthalten muss, Zumal so ein Algorithmus dann bei 15 Bit in einer Endlosschleife das passende letzte Bit nicht findet :-)
Stefan ⛄ F. schrieb: > Man kann auch absichtlich missverstehen, wenn man will. > Er hat sicher nicht gemeint, dass jede einzelne Zufallszahl gleiche > viele Nullen und Einsen enthalten muss, sondern bezog das auf eine große > Menge von Zufallszahlen. Schön, dass wir mal einer Meinung sind! Um es deutlicher zu machen hat ich vermutlich noch 00000000000000000000 und 11111111111111111111 mit aufnehmen sollen.
J. T. schrieb: > Um es deutlicher zu machen hat ich vermutlich noch 00000000000000000000 > und 11111111111111111111 mit aufnehmen sollen. Beide absolut perfekte Zufallszahlen. Sie sollten nur nicht öfter als alle anderen 20bit Zahlen vorkommen. ;-)
Jan schrieb: >> Jan schrieb: >>> Leider haben die ehemaligen Atmels keine PRNGs >>> eingebaut, nichtmal die mit Hardware AES. >> >> Ähem, welcher soll das sein? > > Die komplette xmegaxxxAxU Serie und, gerne übersehen, der xmega384C3. Das sind aber Xmega, keine ATmega wie eingangs gefordert. Peter D. schrieb: > Man speichert einfach vor jedem Abschalten den aktuellen Wert des PRNG > im EEPROM als nächsten Startwert. Unterspannungserkennung geht beim AVR > ganz einfach über das Messen der 1,1V Bandgap mit VCC als ADC-Referenz. > > Oder man speichert jeden Wert des PRNG in einem EERAM, FRAM oder MRAM, > z.B. 47C04. Oder man schaltet nie ab und schickt den Controller nur ausreichend tief schlafen. Dann braucht man nur noch ein Seed pro Batteriewechsel auf Vorrat im nichtflüchtigen Speicher. Oder man hat sowieso eine RTC im Design, die auch noch ein paar Byte Speicher hat. Oder man findet doch noch andere Wege, dem System nachträglich etwas Entropie einzuimpfen, Timing bei Benutzereingaben wäre ein Klassiker. Joe schrieb: > https://www.imn.htwk-leipzig.de/~medocpro/buecher/sedge1/k35t3.html Nein, lineare Kongruenzgeneratoren sind nicht für Kryptografie geeignet.
Heiner schrieb: > Oder man findet doch noch andere Wege, dem System nachträglich etwas > Entropie einzuimpfen, Timing bei Benutzereingaben wäre ein Klassiker. PCs sind im Vorteil, denn bis die Kiste oben ist gibts allerhand Entropie über I/O, und bis man die Entropie braucht dauert es meist eine Weile. Mikrocontroller sind oft ziemlich deterministisch, und ein Seed ist eher frühzeitig fällig.
:
Bearbeitet durch User
Leider habe ich gedanklich irgendwie PRNG mit TRNG vertauscht. Ich brauche natürlich keinen PRNG, sondern einen TRNG in Hardware. Ein PRNG in Hardware macht ja auch relativ wenig Sinn ;) PRNGs sind für kryptographische Zwecke auch ungeeignet bzw. man muss sie so vorsichtig anwenden, dass mir das zu heiss ist. Klassisches Beispiel ist die Nutzung eines PRNG für One-Time Pads. Sehr gefährlich.... Also am liebsten hätte ich eine integrierte Lösung für einen TRNG, aber ohne SPI oder I2C. Das ist unnötig kompliziert. Er soll einfach nur vor sich hinrauschen und ich lese da periodisch an einem Pin die 0en und 1en aus. Das ganze bitte nicht mit 10 Komponenten. Am liebsten wären mir maximal zwei. Als Anforderung zur Sicherheit ist folgendes gegeben: Die Zufallszahlen dürfen von aussen nicht manipulierbar sein. Das Gerät ist jedoch gegen Aufschrauben gesichert, da es schlicht physikalisch unerreichbar ist, bzw. wenn die physikalische Erreichbarkeit gegeben ist, das Problem woanders liegt, also nicht bei mir.
Dann über Umwege so https://blog.usejournal.com/how-to-generate-true-random-numbers-in-a-microcontroller-b0c65903ae84 oder man kauft halt einen passenden µC mit TRNG wie einige SAM von Atmel oder die RL78 von Renesas den zum Beispiel haben.
Hallo, nehmt doch einfach eine Lavalampe und eine Kamera. Mehr Zufall geht nicht. Selbst Cloudflare nutzt das.
Veit D. schrieb: > nehmt doch einfach eine Lavalampe und eine Kamera. Mehr Zufall geht > nicht. Selbst Cloudflare nutzt das. Lavalampe + Kamera: 2 Bauteile, perfekt! Jan schrieb: > Ein einzelnes Bauteil > muss reichen. Maximal zwei.
A. S. schrieb: > Lavalampe Ich dachte immer, das ist übelster Sondermüll! Werden die tatsächlich immer noch gebaut?? Oder haben diverse Altbestände endlich doch noch eine sinnvolle Anwendung gefunden... Gruß Rainer
Jan schrieb: > Und ob diese Zahl dann wirklich zufällig > ist, habe ich nicht wissenschaftlich geprüft. Ganz ehrlich, was für ein Hochsicherheitsgerät wird das denn, für daß da ein nicht ganz so perfekter Zufall nicht auch ausreicht? Immerhin müsste ja zur Erkennung und Auswertung solch einer Lücke doch ein ganz erheblicher Aufwand getrieben werden. Ist es das überhaupt wert? Oliver
:
Bearbeitet durch User
Veit D. schrieb: > nehmt doch einfach eine Lavalampe und eine Kamera. Mehr Zufall geht > nicht. Selbst Cloudflare nutzt das. Habe ich neulich bei Navi-Cis gesehen. hihi
Jan schrieb: > Es geht um Kryptographie. Ok, dann: Starken und zugleich schnellen CPRNG nehmen (z.B. ChaCha20). Zustand des CPRNG im EEPROM ablegen. Beim Flashen das EEPROM mit starkem Zufall seeden (muss für jedes Gerät neuer Zufall sein. z.B. /dev/urandom). Nach jedem Auslesen einer neuen Zahl aus dem CPRNG und vor der Verwendung dieser Zahl den CPRNG-Zustand ins EEPROM rückspeichern.
Rainer V. schrieb: > A. S. schrieb: >> Lavalampe > > Ich dachte immer, das ist übelster Sondermüll! Naja, die Dinger sind schon ein wirkliches Luxusgut, fast ohne jeden praktischen Nutzen. Aber: ich finde die immer noch faszinierend. Selbst ~50 Jahre nachdem ich das erste Mal eine gesehen habe (und nichtmal wusste, das es eine ist, denn das erste Mal gesehen habe ich sie in "Barbarella" als Hintergrund-Deko). Sorry, bin Ossi, war aber einer mit Westfernseh-Empfangsmöglichkeit... Und nein, Jane Fonda hatte rein garnichts damit zu tun. Die war natürlich auch sehr faszinierend, aber auf andere Weise. ;o) > Werden die tatsächlich > immer noch gebaut?? Warum nicht? Die Dinger SIND faszinierend. Also werden sich auch Käufer dafür finden. Auf Amazon z.B. findet sich aktuell immer noch eine ganz ordentliche Auswahl. Wenn sich das Zeug nicht verkaufen liesse, gäbe es die wohl nicht.
c-hater schrieb: > Wenn sich das Zeug nicht verkaufen liesse, > gäbe es die wohl nicht. Ich wundere mich ja auch nur...vielleicht ist mittlerweile ja auch "was Besseres" verbaut. Als mein Sohn vor etlichen Jahren in seine eigene Wohnung verschwand, hat er auch 2 Lampen hinterlassen, worüber ich mich sehr geärgert habe. Die wollte damals der Chef vom Wertstoffhof nicht annehmen, weil er angeblich kein technisches Arbeitsblatt vorliegen hätte. Außerdem hat er sinniert, dass das mit Sicherheit kostenpflichtig werden würde...auch für Privat...seitdem habe ich die Teile auf dem Dachboden ganz tief unten...und vielleicht freut sich mein Sohn sogar, wenn er die irgendwann wiederfindet :-) Gruß Rainer
Rainer V. schrieb: > Ich wundere mich ja auch nur...vielleicht ist mittlerweile ja auch "was > Besseres" verbaut. Das ist doch nur Öl, Wachs, gebräuchliche Farbstoffe und eine Lampe. War es (bis auf die Farbstoffe, da war damals in den 60ern noch einiges erlaubt, was mittlerweile verboten ist) schon immer.
c-hater schrieb: > bis auf die Farbstoffe Du wirst recht haben. "Früher" konnte man da tasächlich allerhand Mist reinmischen. Ähnliche Diskussion damals bei den "millionen" Hobbytöpfern bezüglich der höchst bedenklichen Stoffe in manchen Glasuren...also bleiben die Lampen auf dem Dachboden. Gruß Rainer
Ohne jetzt alles im Detail gelesen zu haben: Nehmt doch einen PRNG dessen Seed über echte Zufallsdaten initialisiert wird. Zudem könnte man während der Laufzeit den PRNG alle z.B. 100 samples mit einem Sample vom TRNG mischen. (z.B. XOR mit einem Zufallswort in Breite des PRNG Seeds) Statt den ADC für echte Zufallsdaten zu nehmen könnte man auch die Lade/Entladekurve eines Kondensators über einen Timer mit Capture Compare abmessen. Wenn der Timer schnell genug läuft (passieren sicher einige Überläufe vor dem Compare) dürfte das unterste Bit auch recht zufällig sein. Solang da keine RSA Keys mit erzeugt werden dürfte das recht gute Ergebnisse bringen.
Angehängte Dateien:
Johannes schrieb: > Ohne jetzt alles im Detail gelesen zu haben: Genau so weil Thread zu lange. Nun ich weis nicht ob der Vorschlag schon kam aber leider kenne ich den AVR zu wenig oder eher Nicht. Ich verwende für Zufallszahlen im MSP430 2 Freilafende Oszilatoren nämlich den LFXT1 und VLO Oszilator. Beide sind relativ präzise aber eben doch nicht Quarzgenau und nicht synchron. Generiere ich durch eine Und die beiden (TI Stellt sogar in diversen MSP's extra ein RND im OnChip ROM zur Verfügung mit app notes) Wenn ich mit diesen Zahlen ein Bild fülle lässt sich kein muster erkennen. Hat der AVR keine Oszilatoren drin die man so nutzen kann? Vorteil ist wenn mann 1 Timer mit den 2 Oszilatoren nutzt, braucht maan keine Prozessor Ressourcen um sie zu erzeugen und kann sie einfach bei Bedarf im CMP Register abhohlen.
Also die erste Antwort liefert ja schon eine professionelle Lösung. Ich habe diese Links aus meiner Linkliste in einem anderen Thread schon einmal gepostet: http://www.jtxp.org/tech/xr232web.htm http://www.jtxp.org/tech/xr232usb.htm Mit zwei Bauteilen ist es bei eigener Lösung nicht getan. Wie denken die Fachleute über diese Selbstbau Lösung? Zufall scheint keine einfache Sache zu sein.
Matthias 🟠. schrieb: > Mit zwei Bauteilen ist es bei eigener Lösung nicht getan. Wie denken die > Fachleute über diese Selbstbau Lösung? Zufall scheint keine einfache > Sache zu sein. Es hängt vollumfänglich davon ab, was man mit dem Zufall erreichen will. Die höchsten Anforderungen hat man für die Erzeugung von Keys für asymmetrische Verschlüsselung. Dort muss man im Zweifel damit rechnen, dass jemand einen Angriff drauf startet. Sind dann Schwächen im Zufallsgenerator erkennbar wird ein motivierter Angreifer diese auch ausnutzen. Es gab schon genügend Bug Reports über schwache Keys in bekannten Libraries. Wenn es nicht gerade so was ist sollten PRNGs gefüttert mit geringen Mengen echter Zufallsdaten völlig ausreichen. Für den absoluten Großteil der Anwendungen auf einem µC hat man wahrscheinlich kaum Anforderungen an die Sicherheit der Zahlen. Blöd ist eben nur, dass reine PRNGs auf einem µC immer die gleiche Zahlenfolge liefern. Daher muss man etwas Entropie reinstecken.
Johannes schrieb: > was man mit dem Zufall erreichen will. Vielleicht zur Abwechslung einfach mal den Thread lesen.
Lese dir mal den NIST SP 800-22 durch. https://csrc.nist.gov/publications/detail/sp/800-22/rev-1a/final https://csrc.nist.gov/Projects/Random-Bit-Generation/Documentation-and-Software Das beinhaltet eine Testsuite, um deine generierten "Zufalls"zahlen statistisch zu untersuchen. Ein Bestehen aller Tests ist das Mindeste, das du erfüllen solltest (es ist natürlich keine Garantie, dass die Werte tatsächlich zufällig sind). Auf einem ATmega644 habe ich TRNG/PRNG mal so gelöst gesehen: - ADC: - max. ADC clock 600 kHz, um Rauschen zu erhöhen - gain stage auf max. - beide differentiellen Eingänge auf den selben Pin (floating) gelegt. Damit ist der Messwert unabhängig vom physischen Wert am Pin und die gain stage produziert zusätzliches Rauschen. Im Prinzip misst man den DC-Offset und das Rauschen der gain stage - Die Zufallsbits sind dennoch nicht gleichverteilt (in meinem Fall waren es mehr '1' als '0') - Watchdog - WDT interrupt alle 16 ms, dann auslesen eines ständig laufenden timers - Man kann den WD Zähler nicht direkt auslesen, deshalb der normale (synchrone) timer. Da der WD Prozesschwankungen unterliegt und thermisch empfindlicher ist, sind die "16 ms" vom WDT ungenau und ergeben mal mehr und mal weniger MCU Takte. - Als TRNG sehr langsam, ca. 128 B/s, die zudem noch biased sind und somit nicht direkt verwendet werden können. Für den PRNG wurden dann beide TRNG-Quellen in einen ständig laufenden Keccak-f[200]/SHA-3 (200 bit state = 25 Register; n=18; r=64; c=136 (==ungefähres Sicherheitsniveau in bit)) gegeben, der im Prinzip ständig seine Ausgabe neu gehasht hat und gelegentlich die TRNG-Werte dazu gexort wurden. Siehe auch Guido Bertoni, Joan Daemen, Michaël Peeters, and Gilles Van Assche. "Sponge-Based Pseudo-Random Number Generators" Springer Berlin Heidelberg, Berlin, Heidelberg, 2010. Analog kann man natürlich auch eine zweite Instanz seines eh implementierten AES laufen lassen und regelmäßigem neu teilseeden.
Jan schrieb: > Heiner schrieb in Beitrag #6778837: >> Jan schrieb: >>> Leider haben die ehemaligen Atmels keine PRNGs >>> eingebaut, nichtmal die mit Hardware AES. >> >> Ähem, welcher soll das sein? > > Die komplette xmegaxxxAxU Serie und, gerne übersehen, der xmega384C3. Bedenke je nach Angreifermodell, dass der XMEGA HW-AES angreifbar über Seitenkanal ist (DPA). Gleiches gilt natürlich auch für einen naiv in SW implementierten AES.
Thread beobachten
Seitenaufteilung abschaltenBitte 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.