Hardware-Zufallsgenerator gesucht

[Julien Thomas]

Rafael Deliano wrote:

sondern erst nochmals durch einen entsprechend sinnvollen
Algorithmus schicken um kräftig zu komprimieren.

Die kostengünstige Verfügbarkeit von ICs für DES ist
vermutlich immer noch schlecht, und in Software ist
DES auch relativ aufwendig. Der Algorithmus hat aber
glaube ich Zufallszahlenmodus und Qualität wäre
sehr gut.

MfG JRD

...und möglicherweise mit Hintertürchen "on-chip"... auch wieder
inakzeptabel für ernsthafte Krypto-Anwendungen. Genau, wie der
Zufallsgenerator auf diversen neuzeitlichen CPUs. Alles in keiner Weise
transparent. Ich verstehe die Frage des OP so, dass er einen
Selbstbau-Ansatz für die Zufallsbit-Erzeugung haben wollte, der
*nachvollziehbar* ist. Und da kommt ihr mit Chipsätzen... tst-tst...

MfG JT

 

[Rafael Deliano]

DES
...und möglicherweise mit Hintertürchen "on-chip"
Gähn. Ich empfehle mal nicht c´t sondern irgendwas

seriöseres zu dem Thema zu lesen und seis nur das
Buch von Schneier. DES wurde von der NSA verändert,
um es gegen Verfahren resistenter zu machen von denen
die lautstark kritisierenden "Experten" Diffie/Hellman
damals noch keine Ahnung hatten die aber heute bekannt
sind. Zu historischen Debatte über DES empfiehlt sich:
Smid, Branstad "The Data Encryption Standard: Past and Future"
in: Simmons "Contemporary Cryptology" IEEE Press 1992

Alles in keiner Weise transparent.
DES und vergleichbare Algorithmen sind ziemlich gut

auf Korrelation u.ä. untersucht und ausgezeichnete
Zufallszahlengeneratoren

Geht im Kern auch auf ein Problem ein das alle Leute
die mit Z-Dioden wursteln wollen haben: entweder
man nimmt etwas simples wie LFSR und die
Verteilungsumwandlung per ROM. Dann kann man im
Entwurf Qualitätskriterien sicherstellen.
Oder man hat etwas komplexeres wie DES bzw. etwas
völlig unklares wie Z-Dioden, dann muß man nachher
ausgiebig und aufwendig testen. Aber bei DES haben
das andere wenigstens schon gemacht.

Ich verstehe die Frage des OP so,
Die ursprüngliche Frage war so unspezifisch dass

man beliebiges reininterpretieren und damit
einstweilen auch keine konkrete Empfehlung für
Schaltung geben kann.

MfG JRD

 

[Uwe Hercksen]

Joerg schrieb:

Aber nicht weit weg von der Ponderosa Ranch, wo die Leute Trucks fahren,
Country Music hoeren und selber Holz hacken. Da faellt mir ein, der
Holzofen braucht jetzt wieder Futter.

Hallo,

Hmm, und manchmal auch andere Jagdteilnehmer mit Schrot krankenhausreif
schiessen. Zieht man da keine knallorangen Westen zur Warnung an?

Bye

 

[Uwe Hercksen]

Sebastian Suchanek schrieb:

Ich dachte daran, irgendwie das Rauschen eines diskreten
Bauteils (Widerstand, Diode...) oder einer Art Radioempfänger[1]
auszuwerten.

Hallo,

wenn Du eine exakte bestimmte statistische Verteilung willst musst Du
bei analogen Rauschmethoden vorsichtig sein das Dir nicht ein kleiner
Gleichspannungsoffset die Verteilung und deren Mittelwert verändert.

Bye

 

[Rafael Deliano]

Zieht man da keine knallorangen Westen zur Warnung an?
Beim Tontaubenschiessen eventuell schon.

Ansonsten könnte natürlich Bambi die Weste auch sehen ...

MfG JRD

 

[Rafael Deliano]

wenn Du eine exakte bestimmte statistische Verteilung willst
Da hat er eh nur die Wahl zwischen Gauß, Gauß und Gauß.

Wobei auch bei thermischem Rauschen wohl nicht davon ausgegangen
wird, daß die einzelne fiktive Rauschquelle Normalverteilung
hat, sondern einfach beliebig viele Quellen summiert werden die
dann via Central Limit Theorem Gauß ergeben.
Nur: der gleiche Prozess wird ja auch bemüht ( vgl
Parallelschalten von Referenzspannungs-ICs, Transistoren, OPs )
um das Rauschen zu vermindern. D.h. alle schlechten Rauschquellen
wie Z-Dioden machen Signalstärke, je "besser" die Rauschquelle desto
kleiner wird das Signal.

MfG JRD

 

[Christian Kahlo]

Rafael Deliano schrieb:

Die kostengünstige Verfügbarkeit von ICs für DES
Vermutlich wäre Xilinx da eh der richtigere Ansatz.

Du willst DES als PRNG einsetzen?
Das meinst Du nicht ernst?

 

[Andreas Lobinger]

Aloha,

Christian Kahlo wrote:

Rafael Deliano schrieb:
Die kostengünstige Verfügbarkeit von ICs für DES
Vermutlich wäre Xilinx da eh der richtigere Ansatz.

Du willst DES als PRNG einsetzen?
Nein. Thread von oben lesen: als RNG.

Einen fröhlichen Tag wünschend
LOBI

 

[Christian Kahlo]

Andreas Lobinger schrieb:

Du willst DES als PRNG einsetzen?
Nein. Thread von oben lesen: als RNG.

Nochmal zum Mitmeisseln:

- DES
- in Software
- als RNG

?

Das ist aber ein PRNG.

Zum Simulieren irgendeines Rauschens oder für Cryptozwecke?

Für Ersteres wäre DES unnötig langsam, ein klassischer
SHA-1 PRNG (wahlweise meinetwegen auch mit RIPEMD160)
waere absehbar schneller. Besser waere noch die Pseudo
Random Function aus TLS auf Basis von HMAC_RIPEMD-160
und Verzicht des dort mal zusaetzlich eingebauten
HMAC_MD5.

Für Letzteres braucht man über den Weg gar nicht nachzudenken.

Bei Bekanntwerden von folgenden Blöcken Random Material
kann man known-plaintext Attacken fahren und die Wahr-
scheinlichkeit für Replay Attacken nimmt ungemein zu, da
einem Angreifer der Key früher oder später bekanntwerden
würde. Und die Random Numbers sind ja gerade für den indirekten
Geheimnisnachweis gedacht. Siehe z.B. Mutual Authentication.
Da waere sogar der SHA-1 PRNG auch mit allen zwischenzeitlich
entdeckten Schwaechen von SHA-1 besser geeignet. Desweiteren
kann bei starken Angriffspotential und langfristiger Nutzung
ein und desselben Seeds davon ausgegangen werden dass solch
ein Angreifer folgende Zufallszahlen und damit auch
potentielles Keymaterial vorberechnen kann.

Kann sein, dass dieser Weg vor 15-20 Jahren mal aktuell war.
Heute jedoch ist er mit ziemlicher Sicherheit überholt.

Gruesse,
Christian

 

[Uwe Hercksen]

Rafael Deliano schrieb:

Beim Tontaubenschiessen eventuell schon.
Ansonsten könnte natürlich Bambi die Weste auch sehen ...

Hallo,

na ja, man kann auch die Leute in Schützen und in Treiber einteilen....

Bye

 

[Rafael Deliano]

Du willst DES als PRNG einsetzen?
Nein. Thread von oben lesen: als RNG.
Ich habe nicht behauptet, das DES ein RNG ist.

Für mich ist aber bei konkreter Anwendung die Teilung
in PRNG und RNG recht sinnfrei, solange man in der
Zykluslänge des PRNG bleibt.
Wer will, darf aber konkrete, praktikable
Vorschläge für RNGs machen ...

Zum Simulieren irgendeines Rauschens oder für
Cryptozwecke?
Letzeres ist in dem ganzen threat bisher nicht

angesprochen.

Für Ersteres wäre DES unnötig langsam, ein klassischer
SHA-1 PRNG
Das DES nicht aufwandsoptimal ist, gestehe ich

gern zu, aber es ist der Algorithmus mit höchster Verbreitung,
man wird also leichter IC oder halbfertige Implementierung
in ApplicationNote für FPGA finden.
Zweckentfremdeter kryptographischer Algorithmus kann in
Anwendungen Sinn machen, wo man glaubt mit der Qualität
eines LFSR nicht hinzukommen.

MfG JRD