Dragon,Rabbit,Spritz: NIST â Statistical Test Suite For Random And Pseudorandom Number Generators...

Helmut Schellong · May 18, 2022

On 05/18/2022 14:11, Arno Welzel wrote:

Helmut Schellong:

On 05/17/2022 17:52, Arno Welzel wrote:
Ole Jansen:

Am 17.05.22 um 03:40 schrieb Bonita Montero:
Es hat sicher noch niemand bewiesen, dass komprimierte Daten
ein guter Zufalls-Generator wÃ¤ren. Ganz einfach weil das eine
komplett schwachsinnige Aussage ist.

Je wirksamer ein Komprimierungsalgoritmus arbeitet um so eher vermeidet
dieser Redundanzen und Strukturen. Darf dann nicht wenigstens
angenommen werden dass komprimierte Daten Ã¤hnliche Eigenschasften
wie Zufallsdaten haben?

Nein, da das Ergebnis auf *nicht* zufÃ¤lligen Daten basiert.

Es basiert aber doch auf zufÃ¤lligen Daten.

Ãhm - nein.

Du widersprichst der Testsuite!

Ein guter Komprimierer entfernt alle redundanten und strukturierten Daten,
so daÃ quasi nur Zufallsdaten Ã¼brig bleiben.

Nein, aus den Daten die Ã¼brig bleiben, lassen sich die Ausgangsdaten
*exakt* wieder rekonstruieren.

Ja, dennoch genÃ¼gen diese Daten den hohen AnsprÃ¼chen an eine Krypto-ZufÃ¤lligkeit.
Bescheinigt durch die Testsuite.

Es verbleibt ein Rest, an dem keinerlei Abfolgeregel erkennbar ist.

Aber sicher - wie sonst sollte der Komprimierer sonst daraus wieder das
Original erzeugen kÃ¶nnen?

Das ist kein Widerspruch.
Die Datei \'z.a.xz\' ist 335 KB groÃ, so daÃ der Header der Datei keine Rolle spielte.
AuÃerdem habe ich die ersten 1024 Byte entfernt.

--
Mit freundlichen GrÃ¼Ãen
Helmut Schellong var@schellong.biz
http://www.schellong.de/c.htm http://www.schellong.de/c2x.htm http://www.schellong.de/c_padding_bits.htm
http://www.schellong.de/htm/bishmnk.htm http://www.schellong.de/htm/rpar.bish.html http://www.schellong.de/htm/sieger.bish.html
http://www.schellong.de/htm/audio_proj.htm http://www.schellong.de/htm/audio_unsinn.htm http://www.schellong.de/htm/tuner.htm
http://www.schellong.de/htm/string.htm http://www.schellong.de/htm/string.c.html http://www.schellong.de/htm/deutsche_bahn.htm
http://www.schellong.de/htm/schaltungen.htm http://www.schellong.de/htm/rand.htm http://www.schellong.de/htm/dragon.c.html

Helmut Schellong · May 18, 2022

On 05/18/2022 14:12, Arno Welzel wrote:

Helmut Schellong:

[...]
Wie gesagt, haben _kryptographische_ Zufallszahlengeneratoren (PRNG)
_keine_ PeriodizitÃ¤t.

Dann sind es keine PRNG mehr. Denn genau deshalb nennt man die Dinger
\"pseudo\", weil das Ergebnis eben *nicht* zufÃ¤llig ist, auch wenn die
Periode sehr lang sein kann.

Das ist eine falsche Aussage.
Es ist oben \'kryptographische PRNG\' ausgesagt worden.
Nur fÃ¼r diese gilt die NichtperiodizitÃ¤t, eben fÃ¼r \'CSPRNG\'.

|GrundsÃ¤tzlich sind fÃ¼r einen CSPRNG dieselben Voraussetzungen
|wie fÃ¼r einen normalen Pseudozufallszahlengenerator vonnÃ¶ten, nur dass
|fÃ¼r die Sicherheit noch einige zusÃ¤tzliche Bedingungen erfÃ¼llt sein mÃ¼ssen.
|Zum einen darf die von ihm erzeugte Zahlenfolge nicht von einer
|echten Zufallszahlenfolge unterscheidbar sein.
|Zum anderen darf es nicht mÃ¶glich sein, anhand der Ausgabe des Generators
|auf seinen internen Zustand zu schlieÃen, auch wenn die genaue Funktionsweise bekannt ist.

Habe ich heute bereits gepostet, so wie vor vielen Wochen auch schon.

https://de.wikipedia.org/wiki/Liste_von_Zufallszahlengeneratoren

| Pseudozufallszahlengeneratoren
| kryptographisch sichere Zufallszahlengeneratoren (Rabbit, Dragon, Spritz)
| ZuverlÃ¤ssige Generatoren (AES)
| BeschrÃ¤nkt zuverlÃ¤ssige Generatoren (Mersenne-Twister)
| Wenig bis nicht zuverlÃ¤ssige Generatoren (rand(), random() [1])

[1]
|Diese Pseudozufallszahlengeneratoren bestehen einen GroÃteil der Tests nicht.
|Sie sollten nur verwendet werden, wenn betrÃ¤chtliche stochastische MÃ¤ngel
|der generierten Zahlenfolgen in Kauf genommen werden kÃ¶nnen.

--
Mit freundlichen GrÃ¼Ãen
Helmut Schellong var@schellong.biz
http://www.schellong.de/c.htm http://www.schellong.de/c2x.htm http://www.schellong.de/c_padding_bits.htm
http://www.schellong.de/htm/bishmnk.htm http://www.schellong.de/htm/rpar.bish.html http://www.schellong.de/htm/sieger.bish.html
http://www.schellong.de/htm/audio_proj.htm http://www.schellong.de/htm/audio_unsinn.htm http://www.schellong.de/htm/tuner.htm
http://www.schellong.de/htm/string.htm http://www.schellong.de/htm/string.c.html http://www.schellong.de/htm/deutsche_bahn.htm
http://www.schellong.de/htm/schaltungen.htm http://www.schellong.de/htm/rand.htm http://www.schellong.de/htm/dragon.c.html

Helmut Schellong · May 18, 2022

On 05/18/2022 14:16, Arno Welzel wrote:

Helmut Schellong:

On 05/18/2022 13:32, Bonita Montero wrote:
[...]
Da hilft auch kein Key, denn PRNGs bleiben immer nachvollziehbarer
Zufall. Selbst ein kryptografischer Zufallsgenerator generiert keinen
nicht nachvollziehbaren Zufall, sondern eben nur einen den man mit
weltlicher Rechenleistung nicht nachvollziehen kann.
\"Zufall\" kannst Du nur haben wenn Du z.B. das Rauschen eines
Rauschgenerators digitalisierst.

Ein Key kann durch echten Zufall ausgewÃ¤hlt werden.

Dann brauche ich keinen PNRG mehr, sondern nehme gleich die Quelle des
echten Zufalls als Basis.

Das wird nicht praktikabel sein.

--
Mit freundlichen GrÃ¼Ãen
Helmut Schellong var@schellong.biz
http://www.schellong.de/c.htm http://www.schellong.de/c2x.htm http://www.schellong.de/c_padding_bits.htm
http://www.schellong.de/htm/bishmnk.htm http://www.schellong.de/htm/rpar.bish.html http://www.schellong.de/htm/sieger.bish.html
http://www.schellong.de/htm/audio_proj.htm http://www.schellong.de/htm/audio_unsinn.htm http://www.schellong.de/htm/tuner.htm
http://www.schellong.de/htm/string.htm http://www.schellong.de/htm/string.c.html http://www.schellong.de/htm/deutsche_bahn.htm
http://www.schellong.de/htm/schaltungen.htm http://www.schellong.de/htm/rand.htm http://www.schellong.de/htm/dragon.c.html

Thomas Koenig · May 18, 2022

Arno Welzel <usenet@arnowelzel.de> schrieb:

Wenn Du aber nur ausdrÃ¼cken wolltest, dass ein komprimierte Datei aus
*aussieht* als wÃ¤re sie zufÃ¤llig, mag das stimmen. Aber auch eine Reihe
aufsteigender Zahlen wie 1,2,3,4,5,6 ist so gesehen zufÃ¤llig - der
Zufall kann ja durchaus dazu fÃ¼hren, dass genau diese Reihe zustande
gekommen ist.

In dem Kontext zwei Literaturstellen:

https://dilbert.com/strip/2001-10-25
https://xkcd.com/221/

Rupert Haselbeck · May 18, 2022

Helmut Schellong schrieb:

Entscheidend ist ein Testlauf mit der Testsuite.
Dessen Resultat sagt, ob der Bitstrom krypto-zufÃ¤llig ist oder nicht.

Das ist natÃ¼rlich BlÃ¶dsinn. Du hast noch immer nicht verstanden, wofÃ¼r
ein Testprogramm gedacht ist und vor allem auch nicht, wo die Grenzen
liegen. Freilich mag eine Folge von Werten fÃ¼r deine Testsuite wie
zufÃ¤llig aussehen. Dennoch sind die aufeinanderfolgenden Werte in einer
komprimierten Datei in keiner Weise zufÃ¤llig sondern beliebig oft exakt
reproduzierbar, einfach durch einen neuen Durchlauf der Ausgangsdatei
durch das Kompressionsprogramm. Zufall ist da nicht im Geringsten zu sehen.
Wie so oft im Leben und in der IT kommt es auch hier auf den Kontext an.
Das Testprogramm kann den Kontext nicht berÃ¼cksichtigen und glaubt bei
einem guten, redundanzfreien Produkt eines Kompressionsalgorithmus an
eine zufÃ¤llige Abfolge von Werten. Es hat keine MÃ¶glichkeit, zu
erkennen, dass die Abfolge der Werte streng deterministisch und in
keiner Weise von Zufall beeinflusst ist.
Mit rudimentÃ¤ren mathematischen Kenntnissen und ein paar Grundbegriffen
der Kryptologie sollte aber fÃ¼r einen halbwegs intelligenten Menschen
erkennbar sein, dass es eine saublÃ¶de Idee wÃ¤re, als Zufallsquelle eine
Datei beliebigen bekannten Inhalts zu verwenden, ob nun komprimiert oder
nicht. Sowas wÃ¤re natÃ¼rlich auch in gewisser Weise \"sicher\", aber nur
solange, wie der interessierte Mitleser die Quelle der \"Zufallszahlen\"
nicht kennt. Security by Obscurity?
Wo es auf hohe QualitÃ¤t der VerschlÃ¼sselung ankommt, verwendet man gerne
\"echten\" Zufall zur SchlÃ¼sselgenerierung, z.B. ausgehend vom Zerfall
eines radioaktiven Elements, einem Detektor, der HÃ¶henstrahlung misst
oder das Rauschen von Bauelementen.

MfG
Rupert

Rupert Haselbeck · May 18, 2022

Helmut Schellong schrieb:

Arno Welzel wrote:
Deswegen ist eine andere Bezeichnung fÃ¼r PRNG - pseudorandom number
generator - auch DBRG - deterministic random bit generator. AbhÃ¤ngig von
den Eingangsparametern kommt nÃ¤mlich *immer* genau derselbe \"Zufall\"
heraus.

Das ist fÃ¼r VerschlÃ¼sselung jedoch zwingend notwendig.
Andernfalls kÃ¶nnte nicht entschlÃ¼sselt werden.

Unsinn! Das Optimum fÃ¼r sichere Kryptografie sind _echte_
Zufallszahlenfolgen.

Gehts dir etwa nur darum, deinen Ruf als GRÃDAZ zu festigen?

MfG
Rupert

Helmut Schellong · May 18, 2022

On 05/18/2022 16:30, Rupert Haselbeck wrote:

Helmut Schellong schrieb:

Entscheidend ist ein Testlauf mit der Testsuite.
Dessen Resultat sagt, ob der Bitstrom krypto-zufÃ¤llig ist oder nicht.

Das ist natÃ¼rlich BlÃ¶dsinn. Du hast noch immer nicht verstanden, wofÃ¼r ein Testprogramm gedacht ist und vor allem auch nicht, wo die Grenzen liegen. Freilich mag eine Folge von Werten fÃ¼r deine Testsuite wie zufÃ¤llig aussehen. Dennoch sind die aufeinanderfolgenden Werte in einer komprimierten Datei in keiner Weise zufÃ¤llig sondern beliebig oft exakt reproduzierbar, einfach durch einen neuen Durchlauf der Ausgangsdatei durch das Kompressionsprogramm. Zufall ist da nicht im Geringsten zu sehen.
Wie so oft im Leben und in der IT kommt es auch hier auf den Kontext an. Das Testprogramm kann den Kontext nicht berÃ¼cksichtigen und glaubt bei einem guten, redundanzfreien Produkt eines Kompressionsalgorithmus an eine zufÃ¤llige Abfolge von Werten. Es hat keine MÃ¶glichkeit, zu erkennen, dass die Abfolge der Werte streng deterministisch und in keiner Weise von Zufall beeinflusst ist.
Mit rudimentÃ¤ren mathematischen Kenntnissen und ein paar Grundbegriffen der Kryptologie sollte aber fÃ¼r einen halbwegs intelligenten Menschen erkennbar sein, dass es eine saublÃ¶de Idee wÃ¤re, als Zufallsquelle eine Datei beliebigen bekannten Inhalts zu verwenden, ob nun komprimiert oder nicht. Sowas wÃ¤re natÃ¼rlich auch in gewisser Weise \"sicher\", aber nur solange, wie der interessierte Mitleser die Quelle der \"Zufallszahlen\" nicht kennt. Security by Obscurity?
Wo es auf hohe QualitÃ¤t der VerschlÃ¼sselung ankommt, verwendet man gerne Â \"echten\" Zufall zur SchlÃ¼sselgenerierung, z.B. ausgehend vom Zerfall eines radioaktiven Elements, einem Detektor, der HÃ¶henstrahlung misst oder das Rauschen von Bauelementen.

Vor mehr als zwei Stunden postete ich:
============================================================================> Die Testsuite untersucht halt nur das Ergebnis und nicht den Weg, wie
> das Ergebnis zustande gekommen ist.

Genau - das soll sie auch ausdrÃ¼cklich!
Ein anderes Konzept wÃ¤re auch Unfug.
Das Programm \'assess\' erhÃ¤lt irgendeine Datei als Eingabe...
...........................
In meiner Webseite:
http://www.schellong.de/htm/dragon.c.html#NIST
ist der Datenstrom \'zaxz\' auch nur zur ergÃ¤nzenden Demonstration vorhanden.

In der Praxis ist eine komprimierte Datei auch nur eingeschrÃ¤nkt nutzbar.
Man muÃ jede solche Datei mit der Testsuite auf Eignung testen.
Falls okay, kÃ¶nnen kleine Abschnitte aus der Datei herausgezogen werden.
Aber, was soll das?
============================================================================
Meine Antworten in der Vergangenheit nehmen (fast) alles vorweg, was
Du oben geschrieben hast.
Der Eindruck entsteht, Du hast meine Antworten aus der Vergangenheit
als Grundlage Deiner Antwort verwendet.
Aber dergestalt, als wÃ¤re alles, das ich in der Vergangenheit schrieb, mir unbekannt.
Das erinnert an ein Paradoxon!

--
Mit freundlichen GrÃ¼Ãen
Helmut Schellong var@schellong.biz
http://www.schellong.de/c.htm http://www.schellong.de/c2x.htm http://www.schellong.de/c_padding_bits.htm
http://www.schellong.de/htm/bishmnk.htm http://www.schellong.de/htm/rpar.bish.html http://www.schellong.de/htm/sieger.bish.html
http://www.schellong.de/htm/audio_proj.htm http://www.schellong.de/htm/audio_unsinn.htm http://www.schellong.de/htm/tuner.htm
http://www.schellong.de/htm/string.htm http://www.schellong.de/htm/string.c.html http://www.schellong.de/htm/deutsche_bahn.htm
http://www.schellong.de/htm/schaltungen.htm http://www.schellong.de/htm/rand.htm http://www.schellong.de/htm/dragon.c.html

Helmut Schellong · May 18, 2022

On 05/18/2022 17:00, Rupert Haselbeck wrote:

Helmut Schellong schrieb:
Arno Welzel wrote:
Deswegen ist eine andere Bezeichnung fÃ¼r PRNG - pseudorandom number
generator - auch DBRG - deterministic random bit generator. AbhÃ¤ngig von
den Eingangsparametern kommt nÃ¤mlich *immer* genau derselbe \"Zufall\" heraus.

Das ist fÃ¼r VerschlÃ¼sselung jedoch zwingend notwendig.
Andernfalls kÃ¶nnte nicht entschlÃ¼sselt werden.

Unsinn! Das Optimum fÃ¼r sichere Kryptografie sind _echte_ Zufallszahlenfolgen.

Unsinn!
Man mÃ¼Ãte dazu ja mit bis zu Tera-Bit langen _echten_ Zufallszahlenfolgen operieren
und diese speichern und an alle Parteien verteilen.
Dies fÃ¼r _jede_ zu verschlÃ¼sselnde/entschlÃ¼sselnde Datenmenge separat.
Welch ein Wahnsinn!

Da ist ein Key mit 256 Bit in Verbindung mit einem CSPRNG
wesentlich praktikabler und sogar sicherer.

Gehts dir etwa nur darum, deinen Ruf als GRÃDAZ zu festigen?

Unsinn!

--
Mit freundlichen GrÃ¼Ãen
Helmut Schellong var@schellong.biz
http://www.schellong.de/c.htm http://www.schellong.de/c2x.htm http://www.schellong.de/c_padding_bits.htm
http://www.schellong.de/htm/bishmnk.htm http://www.schellong.de/htm/rpar.bish.html http://www.schellong.de/htm/sieger.bish.html
http://www.schellong.de/htm/audio_proj.htm http://www.schellong.de/htm/audio_unsinn.htm http://www.schellong.de/htm/tuner.htm
http://www.schellong.de/htm/string.htm http://www.schellong.de/htm/string.c.html http://www.schellong.de/htm/deutsche_bahn.htm
http://www.schellong.de/htm/schaltungen.htm http://www.schellong.de/htm/rand.htm http://www.schellong.de/htm/dragon.c.html

Axel Berger · May 18, 2022

Arno Welzel wrote:

Wenn etwa die EntschlÃ¼sselung mit einem Test-SchlÃ¼ssel mindestens 0,01
Sekunden dauert, bis man feststellen kann, ob sie erfolgreich war oder
nicht

Es wird nie angesprochen, aber das zweite halte ich für das größere
Problem. Schlüssel algorithmisch Durchiterieren ist einfach, aber wie
erkenne ich den Erfolg? Je kürzer der Text, desto schwieriger wird das.

Das Knacken von Enigma gelang nur, weil die Deutschen jede Sendung mit
dem Wetterbericht begannen und der ausnahmslos mit denselben
Eingangsworten anfing.

--
/¯\\ No | Dipl.-Ing. F. Axel Berger Tel: +49/ 221/ 7771 8067
\\ / HTML | Roald-Amundsen-Straße 2a Fax: +49/ 221/ 7771 8069
X in | D-50829 Köln-Ossendorf http://berger-odenthal.de
/ \\ Mail | -- No unannounced, large, binary attachments, please! --

Volker Bartheld · May 19, 2022

On Wed, 18 May 2022 14:03:47 +0200, Bonita Montero wrote:

Am 18.05.2022 um 13:51 schrieb Helmut Schellong:
On 05/18/2022 13:32, Bonita Montero wrote:
Am 17.05.2022 um 18:43 schrieb Helmut Schellong:
On 05/17/2022 18:13, Bonita Montero wrote:
Am 17.05.2022 um 17:53 schrieb Arno Welzel:
Helmut Schellong:
On 05/17/2022 15:47, Ole Jansen wrote:
Am 17.05.22 um 03:40 schrieb Bonita Montero:
Ein Gegenbeweis wäre die Kompression von Zufalls-Daten.
Die wär dann schon als Zufall nutzbar.
Vollkommener Quatsch.
Der Zufall kann durch den Key da hineinkommen, der die Sequenz bestimmt.
Da hilft auch kein Key, denn PRNGs bleiben immer nachvollziehbarer
Zufall.
Ein Key kann durch echten Zufall ausgewählt werden.
Es gibt keinen echten Zufall, sondern nur ggf. nicht mit weltlichen
Mittel nachvollziehbaren.
Es muß zwischen \'Echtem Zufall\' und \'Pseudo-Zufall\' unterschieden werden!
Es ist zumindest kein echter Zufall, dass Du komplett blöd bist.

*LOL* Durch die Hinzunahme von de.comp.lang.c scheint diese unendliche
Selbstentblößung ja noch ein paar pikante Wendungen zu nehmen. Sin
eigentlich auch Maislieferungen vom Ukrainekonflikt betroffen?

Vol\"Popcorn!\"ker

Ole Jansen · May 19, 2022

Am 18.05.22 um 16:02 schrieb Helmut Schellong:

On 05/18/2022 14:12, Arno Welzel wrote:
Helmut Schellong:

[...]
Wie gesagt, haben _kryptographische_ Zufallszahlengeneratoren (PRNG)
_keine_ PeriodizitÃ¤t.

Dann sind es keine PRNG mehr. Denn genau deshalb nennt man die Dinger
\"pseudo\", weil das Ergebnis eben *nicht* zufÃ¤llig ist, auch wenn die
Periode sehr lang sein kann.

Das ist eine falsche Aussage.
Es ist oben \'kryptographische PRNG\' ausgesagt worden.
Nur fÃ¼r diese gilt die NichtperiodizitÃ¤t, eben fÃ¼r \'CSPRNG\'.

Wie sollen rein mathematische Zufallszahlengeneratoren
ohne PeriodizitÃ¤t denn funktionieren wenn die Zahl der
ZustÃ¤nde der Maschine endlich ist?

|GrundsÃ¤tzlich sind fÃ¼r einen CSPRNG dieselben Voraussetzungen
|wie fÃ¼r einen normalen Pseudozufallszahlengenerator vonnÃ¶ten, nur dass
|fÃ¼r die Sicherheit noch einige zusÃ¤tzliche Bedingungen erfÃ¼llt sein
mÃ¼ssen.
|Zum einen darf die von ihm erzeugte Zahlenfolge nicht von einer
|echten Zufallszahlenfolge unterscheidbar sein.
|Zum anderen darf es nicht mÃ¶glich sein, anhand der Ausgabe des Generators
|auf seinen internen Zustand zu schlieÃen, auch wenn die genaue
Funktionsweise bekannt ist.

Das ist praktisch so. Theoretisch geht es doch immer mit Brute Force?

O.J.

Rolf Bombach · May 19, 2022

Ole Jansen schrieb:

Am 18.05.22 um 16:02 schrieb Helmut Schellong:
On 05/18/2022 14:12, Arno Welzel wrote:
Helmut Schellong:

[...]
Wie gesagt, haben _kryptographische_ Zufallszahlengeneratoren (PRNG)
_keine_ PeriodizitÃ¤t.

Dann sind es keine PRNG mehr. Denn genau deshalb nennt man die Dinger
\"pseudo\", weil das Ergebnis eben *nicht* zufÃ¤llig ist, auch wenn die
Periode sehr lang sein kann.

Das ist eine falsche Aussage.
Es ist oben \'kryptographische PRNG\' ausgesagt worden.
Nur fÃ¼r diese gilt die NichtperiodizitÃ¤t, eben fÃ¼r \'CSPRNG\'.

Wie sollen rein mathematische Zufallszahlengeneratoren
ohne PeriodizitÃ¤t denn funktionieren wenn die Zahl der
ZustÃ¤nde der Maschine endlich ist?

Unendlich und abzÃ¤hlbar unendlich...

OK, ein suboptimales Beispiel:

Man nehme einen populÃ¤ren PRNG wie Superpi. Der produziert Abermillionen
an Ziffern, welche statistisch gesehen zufÃ¤llig sind. NatÃ¼rlich kryptographisch
wertlos. Genau determiniert, einfache Mathematik. Bitte gib an, ab
welcher Stelle welche Sequenz periodisch wird. Mathematisch oder empirisch,
egal, es wird dich ein StÃ¼ck nÃ¤her an die Fields-Medaille ranbringen.

Als Ãbungsbeispiel versuche man andere transzendente Konstanten oder Funktionen.

--
mfg Rolf Bombach

Rolf Bombach · May 19, 2022

Axel Berger schrieb:

Arno Welzel wrote:
Wenn etwa die EntschlÃÂ¼sselung mit einem Test-SchlÃÂ¼ssel mindestens 0,01
Sekunden dauert, bis man feststellen kann, ob sie erfolgreich war oder
nicht

Es wird nie angesprochen, aber das zweite halte ich fÃ¼r das grÃ¶Ãere
Problem. SchlÃ¼ssel algorithmisch Durchiterieren ist einfach, aber wie
erkenne ich den Erfolg? Je kÃ¼rzer der Text, desto schwieriger wird das.

Das Knacken von Enigma gelang nur, weil die Deutschen jede Sendung mit
dem Wetterbericht begannen und der ausnahmslos mit denselben
Eingangsworten anfing.

Wie Arno schon implizierte: SpÃ¤testens dann, wenn der SchlÃ¼ssel lÃ¤nger
als der Text ist, kann man den Code nicht mehr knacken. Wenn du deine
Kreditkartennummer mit einem zwanzigstelligen Code verschlÃ¼sselst,
erfÃ¼llen beim Knacken ganz viele Resultate das Kriterium Kreditkartennummer.

--
mfg Rolf Bombach

Rolf Bombach · May 19, 2022

Arno Welzel schrieb:

Helmut Schellong:

On 05/18/2022 13:32, Bonita Montero wrote:
[...]
Da hilft auch kein Key, denn PRNGs bleiben immer nachvollziehbarer
Zufall. Selbst ein kryptografischer Zufallsgenerator generiert keinen
nicht nachvollziehbaren Zufall, sondern eben nur einen den man mit
weltlicher Rechenleistung nicht nachvollziehen kann.
\"Zufall\" kannst Du nur haben wenn Du z.B. das Rauschen eines
Rauschgenerators digitalisierst.

Ein Key kann durch echten Zufall ausgewÃ¤hlt werden.

Dann brauche ich keinen PNRG mehr, sondern nehme gleich die Quelle des
echten Zufalls als Basis.

FÃ¼r was sollte das gut sein? Dann wÃ¤ren wir beim One Time Pad. Der ist
prinzipiell nicht knackbar, braucht aber einen sicheren Kanal fÃ¼r den
SchlÃ¼ssel. Hatte man frÃ¼her mit WÃ¼rfel- und Lottomaschinen hergestellt...

--
mfg Rolf Bombach

Rolf Bombach · May 19, 2022

Rupert Haselbeck schrieb:

Helmut Schellong schrieb:
Arno Welzel wrote:
Deswegen ist eine andere Bezeichnung fÃ¼r PRNG - pseudorandom number
generator - auch DBRG - deterministic random bit generator. AbhÃ¤ngig von
den Eingangsparametern kommt nÃ¤mlich *immer* genau derselbe \"Zufall\" heraus.

Das ist fÃ¼r VerschlÃ¼sselung jedoch zwingend notwendig.
Andernfalls kÃ¶nnte nicht entschlÃ¼sselt werden.

Unsinn! Das Optimum fÃ¼r sichere Kryptografie sind _echte_ Zufallszahlenfolgen.

Gehts dir etwa nur darum, deinen Ruf als GRÃDAZ zu festigen?

Nein, hier geht es ausschliesslich um Schellong-Bashing, meist von Leuten,
die echt noch weniger Ahnung haben.

Um auf deinen Einwand zu kommen: Wie transportierst du den SchlÃ¼ssel von
deiner optimalen sicheren Kryptografie?

--
mfg Rolf Bombach

Rolf Bombach · May 19, 2022

Rupert Haselbeck schrieb:

Wo es auf hohe QualitÃ¤t der VerschlÃ¼sselung ankommt, verwendet man gerne Â \"echten\" Zufall zur SchlÃ¼sselgenerierung, z.B. ausgehend vom Zerfall eines radioaktiven Elements, einem Detektor, der
HÃ¶henstrahlung misst oder das Rauschen von Bauelementen.

Genau das hat Helmut auch so gesagt.
Was ist los? Drehen hier alle am Rad? Sommertemperaturen?

--
mfg Rolf Bombach

Rolf Bombach · May 19, 2022

Thomas Koenig schrieb:

Arno Welzel <usenet@arnowelzel.de> schrieb:

Wenn Du aber nur ausdrÃ¼cken wolltest, dass ein komprimierte Datei aus
*aussieht* als wÃ¤re sie zufÃ¤llig, mag das stimmen. Aber auch eine Reihe
aufsteigender Zahlen wie 1,2,3,4,5,6 ist so gesehen zufÃ¤llig - der
Zufall kann ja durchaus dazu fÃ¼hren, dass genau diese Reihe zustande
gekommen ist.

In dem Kontext zwei Literaturstellen:

https://dilbert.com/strip/2001-10-25
https://xkcd.com/221/

Die Enigma enthielt eine Scheibe, die dafÃ¼r sorgte, dass nie ein Buchstabe
durch sich selber codiert wurde. Die haben den dilbert nicht kapiert und
so die Kodierung _unsicherer_ gemacht.

Ad 2: Beim WÃ¼rfeln kommt durchschnittlich die 3,5.

--
mfg Rolf Bombach

Rolf Bombach · May 19, 2022

Arno Welzel schrieb:

Helmut Schellong:

On 05/17/2022 17:52, Arno Welzel wrote:
Ole Jansen:

Am 17.05.22 um 03:40 schrieb Bonita Montero:
Es hat sicher noch niemand bewiesen, dass komprimierte Daten
ein guter Zufalls-Generator wÃ¤ren. Ganz einfach weil das eine
komplett schwachsinnige Aussage ist.

Je wirksamer ein Komprimierungsalgoritmus arbeitet um so eher vermeidet
dieser Redundanzen und Strukturen. Darf dann nicht wenigstens
angenommen werden dass komprimierte Daten Ã¤hnliche Eigenschasften
wie Zufallsdaten haben?

Nein, da das Ergebnis auf *nicht* zufÃ¤lligen Daten basiert.

Es basiert aber doch auf zufÃ¤lligen Daten.

Ãhm - nein.

Ein guter Komprimierer entfernt alle redundanten und strukturierten Daten,
so daÃ quasi nur Zufallsdaten Ã¼brig bleiben.

Nein, aus den Daten die Ã¼brig bleiben, lassen sich die Ausgangsdaten
*exakt* wieder rekonstruieren.

Nur wenn das Verfahren und allfÃ¤llige SchlÃ¼ssel bekannt sind. Falls sie
das nicht sind, gibt es eben kein Verfahren, welches erkennen kann, dass
es sich um komprimierte Daten oder um weisses Rauschen handelt.

Es verbleibt ein Rest, an dem keinerlei Abfolgeregel erkennbar ist.

Aber sicher - wie sonst sollte der Komprimierer sonst daraus wieder das
Original erzeugen kÃ¶nnen?

?

--
mfg Rolf Bombach

Rolf Bombach · May 19, 2022

Bonita Montero schrieb:

Am 17.05.2022 um 15:47 schrieb Ole Jansen:
Am 17.05.22 um 03:40 schrieb Bonita Montero:
Es hat sicher noch niemand bewiesen, dass komprimierte Daten
ein guter Zufalls-Generator wÃ¤ren. Ganz einfach weil das eine
komplett schwachsinnige Aussage ist.

Je wirksamer ein Komprimierungsalgoritmus arbeitet um so eher vermeidet
dieser Redundanzen und Strukturen. Darf dann nicht wenigstens
angenommen werden dass komprimierte Daten Ã¤hnliche Eigenschasften
wie Zufallsdaten haben?

Wie blÃ¶d ist das denn ?
Das ist sicher nicht der wissenschaftliche Beweis von Helmuts
Aussage, dass eine gepackte datei von der Datensequenz her wie
ein Zufallsgenerator streut.

Das ist nicht ein Beweis, sondern eine plausible ErklÃ¤rung.
Den Beweis haben andere lÃ¤ngst geliefert, das muss man ja nicht wiederholen.

> Sind hier nur Idioten ?

Gewisse Statements sind manchmal reflexiv. Ausserdem plenkst du.

--
mfg Rolf Bombach

Helmut Schellong · May 19, 2022

On 05/19/2022 10:07, Ole Jansen wrote:

Am 18.05.22 um 16:02 schrieb Helmut Schellong:
On 05/18/2022 14:12, Arno Welzel wrote:
Helmut Schellong:

[...]
Wie gesagt, haben _kryptographische_ Zufallszahlengeneratoren (PRNG)
_keine_ PeriodizitÃ¤t.

Dann sind es keine PRNG mehr. Denn genau deshalb nennt man die Dinger
\"pseudo\", weil das Ergebnis eben *nicht* zufÃ¤llig ist, auch wenn die
Periode sehr lang sein kann.

Das ist eine falsche Aussage.
Es ist oben \'kryptographische PRNG\' ausgesagt worden.
Nur fÃ¼r diese gilt die NichtperiodizitÃ¤t, eben fÃ¼r \'CSPRNG\'.

Wie sollen rein mathematische Zufallszahlengeneratoren
ohne PeriodizitÃ¤t denn funktionieren wenn die Zahl der
ZustÃ¤nde der Maschine endlich ist?

Die Sache mit der PeriodizitÃ¤t bei CSPRNG ist nicht so einfach - konstant.
Diese haben alle ein Keystream-LÃ¤ngen-Limit, das wesentlich geringer ist
als irgendein Beginn einer neuen Periode.

|Rabbit was designed to be faster than commonly used ciphers and to justify
|a key size of 128 bits for encrypting up to 2^64 bytes of plaintext.
. ^^^^
|The most important feature of counter assisted stream ciphers [21]
|is that strict lower bounds on the period lengths can be provided.
|The adopted counter system in Rabbit has a period length of 2^256 â 1 [6].
|Since it can be shown that the input to the g-functions has at least the same period,
|a very pessimistic lower bound on the period of the state variables, Nx > 2^215 , can
|be guaranteed [19].

Es fÃ¤llt hier auf, daÃ nicht von einer PeriodizitÃ¤t des Keystreams geschrieben wird.
Sondern der innere Zustand wird beschrieben.
AuÃerdem wird von einer /pessimistischen/ Sicht geschrieben.

Dragon hat eine /erwartete/ Periode des inneren Zustands von 2^576.
Das LÃ¤ngen-Limit des Keystreams ist 2^61 Byte.

Es ist somit nicht falsch, wenn CSPRNG als nicht periodisch
hinsichtlich ihrer Ausgabe beschrieben werden.

Wird das Limit Ã¼berschritten, sinkt die ZufallsqualitÃ¤t der Zahlenfolge.
Angriffe mit LimitÃ¼berschreitung werden als ungÃ¼ltig attributiert.

|GrundsÃ¤tzlich sind fÃ¼r einen CSPRNG dieselben Voraussetzungen
|wie fÃ¼r einen normalen Pseudozufallszahlengenerator vonnÃ¶ten, nur dass
|fÃ¼r die Sicherheit noch einige zusÃ¤tzliche Bedingungen erfÃ¼llt sein mÃ¼ssen.
|Zum einen darf die von ihm erzeugte Zahlenfolge nicht von einer
|echten Zufallszahlenfolge unterscheidbar sein.
|Zum anderen darf es nicht mÃ¶glich sein, anhand der Ausgabe des Generators
|auf seinen internen Zustand zu schlieÃen, auch wenn die genaue Funktionsweise bekannt ist.

Das ist praktisch so. Theoretisch geht es doch immer mit Brute Force?

Brute Force ist quasi ein Standard.
Es wird stets untersucht, ob Angriffe mit weniger Aufwand als Brute Force mÃ¶glich sind.
Wenn das der Fall ist, werden Key und Aufwand beim Angriff verglichen.

--
Mit freundlichen GrÃ¼Ãen
Helmut Schellong var@schellong.biz
http://www.schellong.de/c.htm http://www.schellong.de/c2x.htm http://www.schellong.de/c_padding_bits.htm
http://www.schellong.de/htm/bishmnk.htm http://www.schellong.de/htm/rpar.bish.html http://www.schellong.de/htm/sieger.bish.html
http://www.schellong.de/htm/audio_proj.htm http://www.schellong.de/htm/audio_unsinn.htm http://www.schellong.de/htm/tuner.htm
http://www.schellong.de/htm/string.htm http://www.schellong.de/htm/string.c.html http://www.schellong.de/htm/deutsche_bahn.htm
http://www.schellong.de/htm/schaltungen.htm http://www.schellong.de/htm/rand.htm http://www.schellong.de/htm/dragon.c.html

Dragon,Rabbit,Spritz: NIST â Statistical Test Suite For Random And Pseudorandom Number Generators...

Helmut Schellong

Guest

Helmut Schellong

Guest

Helmut Schellong

Guest

Thomas Koenig

Guest

Rupert Haselbeck

Guest

Rupert Haselbeck

Guest

Helmut Schellong

Guest

Helmut Schellong

Guest

Axel Berger

Guest

Volker Bartheld

Guest

Ole Jansen

Guest

Rolf Bombach

Guest

Rolf Bombach

Guest

Rolf Bombach

Guest

Rolf Bombach

Guest

Rolf Bombach

Guest

Rolf Bombach

Guest

Rolf Bombach

Guest

Rolf Bombach

Guest

Helmut Schellong

Guest

Log in

Welcome to EDABoard.com

Sponsor

Dragon,Rabbit,Spritz: NIST â Statistical Test Suite For Random And Pseudorandom Number Generators...