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

Hanno Foest · May 26, 2022

On 27.05.22 00:12, Helmut Schellong wrote:

Executables sind definitiv nicht random!

Die dieharder-Tests \"beweisen\" das aber. Zumindest deinem
Sprachgebrauch von \"beweisen\" zufolge.

Das ist irrelevant.

Das ist bewiesen. Deine Meinung ist irrelevant. Beweise stehen nicht
unter dem Vorbehalt der Meinung eines Schellong.

Am sichersten von allen ErwÃ¤gungen ist, daÃ Executables nicht zufÃ¤llig
sein kÃ¶nnen.

Das wÃ¼rde aber deiner apodiktischen Feststellung, daÃ der Output so
eines Tools einen Beweis darstellen wÃ¼rde, widersprechen. Und dann hÃ¤tte
sich der GroÃe Schellong geirrt. Und das kann doch wohl nicht sein. Oder?

Offenbar ist die Ausgabe eines solchen Tools nur dann ein Beweis, wenn
das rauskommt, was du gerne mÃ¶chtest. Tolle Wurst.

Hanno

--
The modern conservative is engaged in one of man\'s oldest exercises in
moral philosophy; that is, the search for a superior moral justification
for selfishness.
- John Kenneth Galbraith

Helmut Schellong · May 27, 2022

On 05/26/2022 17:07, Arno Welzel wrote:

Helmut Schellong:

On 05/25/2022 15:02, Holger Schieferdecker wrote:
[...]
FÃ¼r Kryptographie mag die ReversibilitÃ¤t negativ sein,

Ist sie nicht - warum auch?

Weil das Ausgangsmaterial bekannt sein kann und man dann *exakt* weiÃ,
wie die Zahlenfolge zustandgekommen ist, die als \"Zufall\" benutzt wird.

Man muss also geheimhalten, was man als Ausgangsmaterial benutzt hat,
genauso wie man den Startwert fÃ¼r den PRNG einem potentiellen Angreifer
nicht verraten sollte.

Im Ergebnis Ã¤ndert sich nichts - nicht die Kompromierung an sich ist der
entscheidende Punkt, die macht nichts \"zufÃ¤lliger\", sondern dass man
bestimmte Dinge geheimhÃ¤lt.

Das Ausgangsmaterial kann nicht bekannt sein.

Ich habe ein ar-Archiv mit einer unbekannten Anzahl von unbekannten Dateien
benutzt: ar -r za.a *.* ../*.*; xz za.a
Dann habe ich pauschal die ersten 1024 Byte von za.a entfernt.

Das Archiv za.a existiert nicht mehr.
Denn es diente nur dazu, die ZufÃ¤lligkeit von za.a.xz zu untersuchen.
Das hat nur akademischen Wert!
Die Ausgabe der Testsuite dazu existiert noch.

Ich schrieb bereits, daÃ die Verwendung von komprimierten Dateien als
Fundgrube von zufÃ¤lligen Bitfolgen Idiotie ist!
DafÃ¼r gibt es dedizierte Zufalls-Funktionen.

Das, was Attacken auf VerschlÃ¼sselungs-Funktionen hervorbringen sollen, ist der SchlÃ¼ssel.
Ist der Aufwand dafÃ¼r geringer als Brute Force, gilt \'geknackt\'.

--
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 27, 2022

On 05/26/2022 17:08, Arno Welzel wrote:

Ralph A. Schmid, dk5ras:

[...]
Redet ihr vielleicht alle nur gekonnt aneinander vorbei? Die Folge aus
dem Komprimierer vermag durchaus den AnsprÃ¼chen der VerschlÃ¼sselung
erst mal entsprechen, die Folge wirkt zufÃ¤llig, und jedes Tool zur
Evaluierung wird ohne Kenntnis der Herkunft sagen, jawoll, die ist
gut, die kann der Algo verwenden. Nur eben, daÃ sie nicht zufÃ¤llig
ist, aber man natÃ¼rlich die Ursprungsdaten und den Komprimierer kennen
muÃ, um die nicht-ZufÃ¤lligkeit zu erkennen.

Nein, man muss *nur* den Komprimierer kennen und kann dann *immer* die
Ausgangsdaten wiederherstellen.

Das wird in der Praxis aber nicht gemacht.
Man will keine Zufallsdaten aus komprimierten Daten gewinnen!
Das ist Nonsens.

--
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 27, 2022

On 05/26/2022 17:10, Arno Welzel wrote:

Helmut Schellong:

[...]
Das ist vollkommen falsch!:
==========================>> Ich habe _lediglich_ mitgeteilt, daÃ ich auch eine komprimierte Datei
untersucht habe, und diese wesentlich besser als random() ist.

Ja - wenn man komplett ignoriert, wie die Datei zustande gekommen ist
und komplett vergisst, welches Komprimierungsverfahren verwendet wurde.

Ansonsten ist diese Datei einfach nur ein Klartext in anderer Form.

Diese Datei existiert nicht mehr.
Sie diente nur der Feststellung von ZufÃ¤lligkeit.
Nur akademischer Wert.

--
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 27, 2022

On 05/26/2022 17:13, Arno Welzel wrote:

Helmut Schellong:

[...]
|This package will address the problem of evaluating (P)RNGs for randomness.
|It will be useful in:
|o identifying (P)RNGs which produce weak (or patterned) binary sequences,
|o designing new (P)RNGs,
|o verifying that the implementations of (P)RNGs are correct,
|o studying (P)RNGs described in standards, and
|o investigating the degree of randomness by currently used (P)RNGs.

Eine komprimierte Datei ist aber kein (P)RNG sondern nur eine
komprimierte Datei - egal ob die Bitfolgen so *aussehen* wie das
Ergebnis eines (P)RNG.

FÃ¼r die Testsuite ist der Ursprung egal.
Die untersucht jede Bitfolge blind auf ZufÃ¤lligkeit.
DarÃ¼ber braucht gar nicht geredet werden.

So wie Eliza auch nur ein Programm ist und kein Mensch, auch wenn manche
Menschen die Antworten von Eliza fÃ¼r Reaktionen einer echten Person halten.

Die Antworten von Eliza sind von Menschen einzeln kreiert und vorgegeben worden, las ich.
Weil, die bekommen KI einfach nicht wirklich hin - die reden nur davon.

--
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 27, 2022

On 05/26/2022 17:15, Arno Welzel wrote:

Helmut Schellong:

On 05/26/2022 16:32, Hanno Foest wrote:
[...]
Die dieharder-Tests \"beweisen\" das aber. Zumindest deinem Sprachgebrauch von \"beweisen\" zufolge.

Das ist irrelevant.
Executables kÃ¶nnen nicht random sein.

Genauso wenig wie komprimierte Dateien - denn denen liegen *nicht*
zufÃ¤llige Ausgangsdaten zugrunde und das Ergebnis ist exakt
vorherbestimmbar.

Diese Aussage ist falsch.
Der Beweis von Kolmogorow (et al) liegt seit 1964 vor und wurde mehrfach gepostet.
Komplett-Ignorierung?

--
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 27, 2022

On 05/27/2022 00:48, Hanno Foest wrote:

On 27.05.22 00:12, Helmut Schellong wrote:

Executables sind definitiv nicht random!

Die dieharder-Tests \"beweisen\" das aber. Zumindest deinem Sprachgebrauch von \"beweisen\" zufolge.

Das ist irrelevant.

Das ist bewiesen. Deine Meinung ist irrelevant. Beweise stehen nicht unter dem Vorbehalt der Meinung eines Schellong.

Am sichersten von allen ErwÃ¤gungen ist, daÃ Executables nicht zufÃ¤llig sein kÃ¶nnen.

Das wÃ¼rde aber deiner apodiktischen Feststellung, daÃ der Output so eines Tools einen Beweis darstellen wÃ¼rde, widersprechen. Und dann hÃ¤tte sich der GroÃe Schellong geirrt. Und das kann doch wohl nicht sein. Oder?

Offenbar ist die Ausgabe eines solchen Tools nur dann ein Beweis, wenn das rauskommt, was du gerne mÃ¶chtest. Tolle Wurst.

Falsch.
Ich schrieb von Beginn an, daÃ dann das Tool falsch bedient wurde
oder unzutreffende Ergebnisse liefert.

--
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

Holger Schieferdecker · May 27, 2022

Am 26.05.2022 um 17:04 schrieb Arno Welzel:

Holger Schieferdecker:

Am 24.05.2022 um 10:28 schrieb Arno Welzel:
[...]
Bei komprimierten Daten ist das aber nicht so, weil die Komprimierung
von Daten reversibel ist und man daher aus diesen Daten auch wieder die
Ursprungsdaten rekonstruieren kann. Daher ist das Ergebnis auch nur so
\"zufÃ¤llig\", wie die Ausgangsdaten.

Dann kÃ¶nnte man die Ausgangsdaten also bildlich gesprochen als Seed fÃ¼r
den \"Zufallszahlengenerator\" betrachten?

Nein, da \"Komprimierung\" ja *kein* Zahlengenerator ist, sondern nur die
Umformung von Daten in einer andere Form mit weniger Redundanz.

FÃ¼r Kryptographie mag die ReversibilitÃ¤t negativ sein, aber wenn z.B.
Zufallszahlen fÃ¼r die Simulation einer Teilchenbewegung brauche, reicht
es doch, wenn sie statistisch verteilt sind.

Was ist \"statistisch verteilt\"?

Sie erfÃ¼llt die statistischen Anforderungen an Zufallszahlen, wie
Gleichverteilung. Was da sonst noch im Detail gelten muÃ, weiÃ ich
nicht. Das meinte ich damit.

Holger

Holger Schieferdecker · May 27, 2022

Am 25.05.2022 um 16:11 schrieb Helmut Schellong:

On 05/25/2022 15:02, Holger Schieferdecker wrote:
Am 24.05.2022 um 10:28 schrieb Arno Welzel:
Bei komprimierten Daten ist das aber nicht so, weil die Komprimierung
von Daten reversibel ist und man daher aus diesen Daten auch wieder die
Ursprungsdaten rekonstruieren kann. Daher ist das Ergebnis auch nur so
\"zufÃ¤llig\", wie die Ausgangsdaten.

Dann kÃ¶nnte man die Ausgangsdaten also bildlich gesprochen als Seed
fÃ¼r den \"Zufallszahlengenerator\" betrachten?

Das ist ein SchluÃ, der nicht so recht paÃt.
Ein Seed in Voreinstellung betrÃ¤gt oft einfach \'1\'.
(Die \'1\' ist prinzipiell genau so gut wie 923742194, jedoch die \'1\'
Â wird sicher als erste Zahl probiert ...)
Es kann jede Integer-Zahl verwendet werden, die im betreffenden
Zahlenbereich liegt.
Der Seed sollte jedoch in vielen Situationen im Wert wechseln.

Ich hatte das ganz, ganz, ganz abstrakt gemeint. Ein Zahlengenerator
erzeugt mit einem Startwert (Seed) eine Zahlenfolge. Ein
Komprimierungsalgorithmus erzeugt aus den unkomprimierten Daten auch
eine Zahlenfolge.

Inwieweit die statistischen Eigenschaften dieser Zahlenfolge fÃ¼r
Zufallszahlen genÃ¼gend sind, ist dann nochmal was anderes.

DaÃ der Seed fÃ¼r konkrete Anwendungen nicht immer gleich sein darf, ist
klar.

Holger

Helmut Schellong · May 27, 2022

On 05/27/2022 09:30, Holger Schieferdecker wrote:

Am 25.05.2022 um 16:11 schrieb Helmut Schellong:
On 05/25/2022 15:02, Holger Schieferdecker wrote:
Am 24.05.2022 um 10:28 schrieb Arno Welzel:
Bei komprimierten Daten ist das aber nicht so, weil die Komprimierung
von Daten reversibel ist und man daher aus diesen Daten auch wieder die
Ursprungsdaten rekonstruieren kann. Daher ist das Ergebnis auch nur so
\"zufÃ¤llig\", wie die Ausgangsdaten.

Dann kÃ¶nnte man die Ausgangsdaten also bildlich gesprochen als Seed fÃ¼r den \"Zufallszahlengenerator\" betrachten?

Das ist ein SchluÃ, der nicht so recht paÃt.
Ein Seed in Voreinstellung betrÃ¤gt oft einfach \'1\'.
(Die \'1\' ist prinzipiell genau so gut wie 923742194, jedoch die \'1\'
Â Â wird sicher als erste Zahl probiert ...)
Es kann jede Integer-Zahl verwendet werden, die im betreffenden Zahlenbereich liegt.
Der Seed sollte jedoch in vielen Situationen im Wert wechseln.

Ich hatte das ganz, ganz, ganz abstrakt gemeint. Ein Zahlengenerator erzeugt mit einem Startwert (Seed) eine Zahlenfolge. Ein Komprimierungsalgorithmus erzeugt aus den unkomprimierten Daten auch eine Zahlenfolge.

Inwieweit die statistischen Eigenschaften dieser Zahlenfolge fÃ¼r Zufallszahlen genÃ¼gend sind, ist dann nochmal was anderes.

Richtig. Eine beliebige Bitfolge kann mittels Testsoftware auf QualitÃ¤t geprÃ¼ft werden.

DaÃ der Seed fÃ¼r konkrete Anwendungen nicht immer gleich sein darf, ist klar.

Der Seed ist gleichbedeutend mit einem Key fÃ¼r einen Stream-Cipher.
Seed wie auch Key erzeugen eine ganz bestimmte Bitfolge am Ausgang.
Falls die Ausgabe direkt verwendet wird, liegt ein Zufallszahlengenerator vor.
Falls sie mit einer anderen Bitfolge per XOR verknÃ¼pft wird, liegt eine VerschlÃ¼sselung vor.

Wie zu sehen ist:
http://www.schellong.de/htm/rabbit.bish.html
Verwende ich stets den gleichen SchlÃ¼ssel.
Es kÃ¶nnen aber GrÃ¼nde entstehen, die eine Ãnderung nahelegen.

Das ist aber Ã¼blich:
PaÃwÃ¶rter soll(t)en oft jedes halbe Jahr geÃ¤ndert werden.
Die datei.pfx bei Elster soll alle drei Jahre erneuert werden.

Es gibt sogar Experten, die raten von einer stÃ¤ndigen, pauschalen Erneuerung ab.
https://www.heise.de/security/meldung/Passwoerter-BSI-verabschiedet-sich-vom-praeventiven-Passwort-Wechsel-4652481.html

Bereits in den 1990ern las ich von Experten, daÃ besser nicht dauernd geÃ¤ndert werden soll.

--
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

Hanno Foest · May 27, 2022

On 27.05.22 01:14, Helmut Schellong wrote:

Executables sind definitiv nicht random!

Die dieharder-Tests \"beweisen\" das aber. Zumindest deinem
Sprachgebrauch von \"beweisen\" zufolge.

Das ist irrelevant.

Das ist bewiesen. Deine Meinung ist irrelevant. Beweise stehen nicht
unter dem Vorbehalt der Meinung eines Schellong.

Am sichersten von allen ErwÃ¤gungen ist, daÃ Executables nicht
zufÃ¤llig sein kÃ¶nnen.

Das wÃ¼rde aber deiner apodiktischen Feststellung, daÃ der Output so
eines Tools einen Beweis darstellen wÃ¼rde, widersprechen. Und dann
hÃ¤tte sich der GroÃe Schellong geirrt. Und das kann doch wohl nicht
sein. Oder?

Offenbar ist die Ausgabe eines solchen Tools nur dann ein Beweis, wenn
das rauskommt, was du gerne mÃ¶chtest. Tolle Wurst.

Falsch.
Ich schrieb von Beginn an, daÃ dann das Tool falsch bedient wurde
oder unzutreffende Ergebnisse liefert.

Ah, demnach ist das Tool richtig bedient, wenn dir genehme Ergebnisse
rauskommen, und falsch, wenn du die Ergebnisse nicht magst. So einfach
kann man es sich machen. Tolle \"Beweise\".

Hanno

--
The modern conservative is engaged in one of man\'s oldest exercises in
moral philosophy; that is, the search for a superior moral justification
for selfishness.
- John Kenneth Galbraith

Helmut Schellong · May 27, 2022

On 05/27/2022 12:26, Hanno Foest wrote:

On 27.05.22 01:14, Helmut Schellong wrote:

Executables sind definitiv nicht random!

Die dieharder-Tests \"beweisen\" das aber. Zumindest deinem Sprachgebrauch von \"beweisen\" zufolge.

Das ist irrelevant.

Das ist bewiesen. Deine Meinung ist irrelevant. Beweise stehen nicht unter dem Vorbehalt der Meinung eines Schellong.

Am sichersten von allen ErwÃ¤gungen ist, daÃ Executables nicht zufÃ¤llig sein kÃ¶nnen.

Das wÃ¼rde aber deiner apodiktischen Feststellung, daÃ der Output so eines Tools einen Beweis darstellen wÃ¼rde, widersprechen. Und dann hÃ¤tte sich der GroÃe Schellong geirrt. Und das kann doch wohl nicht sein. Oder?

Offenbar ist die Ausgabe eines solchen Tools nur dann ein Beweis, wenn das rauskommt, was du gerne mÃ¶chtest. Tolle Wurst.

Falsch.
Ich schrieb von Beginn an, daÃ dann das Tool falsch bedient wurde
oder unzutreffende Ergebnisse liefert.

Ah, demnach ist das Tool richtig bedient, wenn dir genehme Ergebnisse rauskommen, und falsch, wenn du die Ergebnisse nicht magst. So einfach kann man es sich machen. Tolle \"Beweise\".

Die Angelegenheit ist schon lÃ¤ngst von Deiner Seite her unseriÃ¶s geworden:

Ich habe mit der Software DIEHARD nie etwas zu tun gehabt.
Ich habe auch aktuell nichts damit zu tun.
Ich kenne nur den Namen \'DIEHARD\' - sonst nichts.
Meine angeblich sinngemÃ¤Ãe Aussage:
\"... daÃ der Output so eines Tools einen Beweis darstellen ...\"
ist frei erfunden.

Ich habe _nur_ von der NIST-Testsuite geschrieben, daÃ deren Ausgabe
im Rahmen von _Vergleichsbetrachtungen_ einen Beweis darstellt.

Diese Testsuite wird weltweit zur absoluten Validierung von kryptographischen
Algorithmen benutzt, womit meine Aussage mit den Vergleichsbetrachtungen
nicht weit hergeholt ist.

--
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

Hans-Peter Diettrich · May 28, 2022

On 5/17/22 5:52 PM, 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.

IMO liegt das alleine an der Definition von \"zufÃ¤llig\".

Die HÃ¤ufigkeit von Symbolen in Texten (und BinÃ¤rdateien) ist eine ganz
andere als in einer daraus erzeugten komprimierten Version. Siehe auch
die Diskussion, ob eine Datei erst verschlÃ¼sselt und dann komprimiert
werden soll, oder umgekehrt.

DoDi

Ole Jansen · May 28, 2022

Am 25.05.22 um 09:55 schrieb Hans-Peter Diettrich:

On 5/17/22 5:52 PM, 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.

IMO liegt das alleine an der Definition von \"zufÃ¤llig\".

\"Random\" im Sinne von nicht vorhersehbar sind beispielsweise
aufgezeichnete Daten von radioaktiven ZerfÃ¤llen oder aus
Rauschdioden.

Die HÃ¤ufigkeit von Symbolen in Texten (und BinÃ¤rdateien) ist eine ganz
andere als in einer daraus erzeugten komprimierten Version.

Beispielsweise kÃ¶nnen solche Daten Redundanzen enthalten,
z.B. wenn die Entropiequelle nicht zur WortlÃ¤nge der Daten
passt.

Wie mir der Umstand zeigt dass ich die Daten aus radioaktiven
Messungen komprimieren kann. Ich nehme an das liegt an der
nicht gleichmÃ¤Ãigen oder zufÃ¤lligen Verteilung der Symbole liegt.
Den Daten fehlt also eine wesentliche kryptografische
Eigenschaft.

Siehe auch
die Diskussion, ob eine Datei erst verschlÃ¼sselt und dann komprimiert
werden soll, oder umgekehrt.

Wenn sich die verschlÃ¼sselten Daten komprimieren lassen taugt
die VerschlÃ¼sselung nichts? Oder darf man das nicht generell
annehmen?

O.J.

Helmut Schellong · May 28, 2022

On 05/28/2022 19:33, Ole Jansen wrote:

Am 25.05.22 um 09:55 schrieb Hans-Peter Diettrich:
On 5/17/22 5:52 PM, 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.

IMO liegt das alleine an der Definition von \"zufÃ¤llig\".

\"Random\" im Sinne von nicht vorhersehbar sind beispielsweise
aufgezeichnete Daten von radioaktiven ZerfÃ¤llen oder aus
Rauschdioden.

Die HÃ¤ufigkeit von Symbolen in Texten (und BinÃ¤rdateien) ist eine ganz andere als in einer daraus erzeugten komprimierten Version.

Beispielsweise kÃ¶nnen solche Daten Redundanzen enthalten,
z.B. wenn die Entropiequelle nicht zur WortlÃ¤nge der Daten
passt.

WieÂ mir der Umstand zeigt dass ich die Daten aus radioaktiven
Messungen komprimieren kann. Ich nehme an das liegt an der
nicht gleichmÃ¤Ãigen oder zufÃ¤lligen Verteilung der Symbole liegt.
Den Daten fehlt also eine wesentliche kryptografische
Eigenschaft.

W8t:JjyX~%Sfu5_.)(>wCYF*#HlV?]g{94a0@z^sZp\\UeTh6d}QD!nom-E|/Rx,$
i#Q+(d\\Pt_>?Vpul%Lf0crgsBaX`|]bOC}S;RZKI76@AmvGwYh:y{xeTWjqoH~F.
JML3h^g[0}c*\\ADft$eT1O>Yq(~#@&\"mQ5%Rb;7v`XsC+ZF)Gox-|?l!uB/i2P,6

Diese Daten sehen zufÃ¤llig aus, sind es aber nicht im Sinne eines CSPRNG.
Deshalb lassen sie sich komprimieren (um bis zu 20%).
Das oberste Bit jedes Bytes ist stets 0. Das ist nicht random!

Die Daten aus RadioaktivitÃ¤t waren dann ungeeignet aufbereitet.
Es muÃ im gesamten Wertebereich des betreffenden Typs streuen!

Siehe auch die Diskussion, ob eine Datei erst verschlÃ¼sselt und dann komprimiert werden soll, oder umgekehrt.

Wenn sich die verschlÃ¼sselten Daten komprimieren lassen taugt
die VerschlÃ¼sselung nichts? Oder darf man das nicht generell
annehmen?

Eine Datei darf nicht vor dem Komprimieren verschlÃ¼sselt werden.
Die VerschlÃ¼sselung verknÃ¼pft nÃ¤mlich einen Random-Strom.
Das verhindert effektiv eine starke Komprimierung.

Optimal ist ein ar-Archiv aus Dateien mit dem gleichen Inhaltstyp.
Diese xz-komprimieren und abschlieÃend verschlÃ¼sseln.
409] file *.xz
za.a.xz: XZ compressed data
Deshalb muÃ verschlÃ¼sselt werden. (Die Endung .xz ist irrelevant.)

Eine Datei, die nur 0-Bits enthÃ¤lt, enthÃ¤lt nach dem VerschlÃ¼sseln
den Original-Keystream des verschlÃ¼sselnden Algorithmus.

--
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

Hans-Peter Diettrich · May 28, 2022

On 5/26/22 5:08 PM, Arno Welzel wrote:

Nein, man muss*nur* den Komprimierer kennen und kann dann*immer* die
Ausgangsdaten wiederherstellen.

Es gibt auch Komprimierer mit Passwort. Dann kann man zumindest das
Passwort als \"salt\" eines Pseudo-Randomgenerators betrachten. Hinzu
kommt die SymbolgrÃ¶Ãe einer Zufalls*zahl*, die bei einer Komprimierung
je nach Verfahren kein Vielfaches von 8 ist und im Verlauf wechseln
kann. Dann sind wir bei einer zufÃ¤lligen Bitfolge, aus der ohne weitere
Informationen kaum ermittelt werden kann, ob sie von einem
Zufallsgenerator oder einem Komprimierer erzeugt wurde. Ein
Random-Generator, der auch rein zufÃ¤llig keine komprimierte Datei
erzeugen kann, taugt eh nix.

Das Argument, daÃ die *selbe* Datei stets gleich komprimiert wird, ist
sowieso sinnfrei. DaÃ *Ã¤hnliche* Dateien Ã¤hnlich komprimieren war schon
bei Enigma hinfÃ¤llig.

Insgesamt gibt es unterschiedliche AnwendungsfÃ¤lle fÃ¼r Pseudo- und echte
Random-Generatoren sowie Komprimierer. Was also soll ein Streit, wie
weit einer davon durch einen anderen ersetzt werden kann? Zudem fallen
mir gerade keine sinnvollen VerwendungsmÃ¶glichkeiten fÃ¼r echte
Zufallszahlen ein, in denen nicht auch Pseudo-Zufallszahlen verwendet
werden kÃ¶nnen.

DoDi

Helmut Schellong · May 29, 2022

On 05/28/2022 22:39, Hans-Peter Diettrich wrote:

On 5/26/22 5:08 PM, Arno Welzel wrote:
Nein, man muss*nur*Â den Komprimierer kennen und kann dann*immer*Â die
Ausgangsdaten wiederherstellen.

Es gibt auch Komprimierer mit Passwort. Dann kann man zumindest das Passwort als \"salt\" eines Pseudo-Randomgenerators betrachten. Hinzu kommt die SymbolgrÃ¶Ãe einer Zufalls*zahl*, die bei einer Komprimierung je nach Verfahren kein Vielfaches von 8 ist und im Verlauf wechseln kann. Dann sind wir bei einer zufÃ¤lligen Bitfolge, aus der ohne weitere Informationen kaum ermittelt werden kann, ob sie von einem Zufallsgenerator oder einem Komprimierer erzeugt wurde.

Ich schreibe nun zum dritten Mal, daÃ aus einer komprimierten Datei
die vordersten Bytes (Header) entfernt werden kÃ¶nnen.
Dadurch ist ein Dekomprimieren gar nicht mehr mÃ¶glich.
Auch nicht durch Hacken.

--
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 30, 2022

On 05/27/2022 12:26, Hanno Foest wrote:

On 27.05.22 01:14, Helmut Schellong wrote:

Executables sind definitiv nicht random!

Die dieharder-Tests \"beweisen\" das aber. Zumindest deinem Sprachgebrauch von \"beweisen\" zufolge.

Das ist irrelevant.

Das ist bewiesen. Deine Meinung ist irrelevant. Beweise stehen nicht unter dem Vorbehalt der Meinung eines Schellong.

Am sichersten von allen ErwÃ¤gungen ist, daÃ Executables nicht zufÃ¤llig sein kÃ¶nnen.

Das wÃ¼rde aber deiner apodiktischen Feststellung, daÃ der Output so eines Tools einen Beweis darstellen wÃ¼rde, widersprechen. Und dann hÃ¤tte sich der GroÃe Schellong geirrt. Und das kann doch wohl nicht sein. Oder?

Offenbar ist die Ausgabe eines solchen Tools nur dann ein Beweis, wenn das rauskommt, was du gerne mÃ¶chtest. Tolle Wurst.

Falsch.
Ich schrieb von Beginn an, daÃ dann das Tool falsch bedient wurde
oder unzutreffende Ergebnisse liefert.

Ah, demnach ist das Tool richtig bedient, wenn dir genehme Ergebnisse rauskommen, und falsch, wenn du die Ergebnisse nicht magst. So einfach kann man es sich machen. Tolle \"Beweise\".

http://www.schellong.de/txt/diehard_testexe.txt

A 1 Datei vom Stream-Cipher Dragon
B 114 BinÃ¤re Executables aus /usr/local/bin

Die erste Datei hat alle Tests bestanden, die 114 Exe haben jeweils 0 Tests bestanden!
Die Charakteristiken der Ausgabedaten A:B sind absolut eindeutig unterscheidbar.

Das kÃ¶nnte ausgeweitet werden auf alle BinÃ¤ren x86-Executables der Welt >=1MB, mit
gleichem SUCCESS:FAILURE-Ergebnis.

Skript:
==========================================================================set -f
set fn:.500 ft:.300 sz:020

cd die.c
diehard -1 /usr/nist/zodrag

for fn in $( list -fp \"/usr/local/bin\" )
do
expr \"$(- file -b \"$fn\" )\" :: \'ELF.%{1,} executable\' || continue
fstat -sv sz \"$fn\"
let \"sz<1000000\" && continue
diehard -1 \"$fn\"
done
==========================================================================

--
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

Arno Welzel · Jun 7, 2022

Helmut Schellong:

[...]

Das ist aber Ã¼blich:
PaÃwÃ¶rter soll(t)en oft jedes halbe Jahr geÃ¤ndert werden.

Nein, sollten sie nicht. Diese Empfehlung, die einst vom NIST und BSI
ausgegeben wurde, gilt schon lÃ¤nger nicht mehr, weil man da auch gemerkt
hat, dass das eher kontraproduktiv ist.

Wenn ein Passwort kompromittiert wurde, hilft es nicht, dass es kurz
davor im Rahmen regelmÃ¤Ãigen Wechsels erneuert wurde. Sehr wohl aber
neigen Nutzer dazu, weniger sichere PasswÃ¶rter zu vergeben, wenn sie
diese ohnehin alle 3-6 Monate neu vergeben mÃ¼ssen. Nicht selten hat man
dann auch einfach nur eine angehÃ¤ngte Zahl, die hochgezÃ¤hlt wird bei
jeder Erneuerung - und so etwas bekommen auch Angreifer heraus, wenn das
komprimittierte Passwort eine Zahlenfolge enthÃ¤lt.

Die datei.pfx bei Elster soll alle drei Jahre erneuert werden.

Es gibt sogar Experten, die raten von einer stÃ¤ndigen, pauschalen Erneuerung ab.
https://www.heise.de/security/meldung/Passwoerter-BSI-verabschiedet-sich-vom-praeventiven-Passwort-Wechsel-4652481.html

Bereits in den 1990ern las ich von Experten, daÃ besser nicht dauernd geÃ¤ndert werden soll.

Ja, aus guten GrÃ¼nden.

--
Arno Welzel
https://arnowelzel.de

Arno Welzel · Jun 7, 2022

Helmut Schellong:

On 05/26/2022 17:15, Arno Welzel wrote:
Helmut Schellong:

On 05/26/2022 16:32, Hanno Foest wrote:
[...]
Die dieharder-Tests \"beweisen\" das aber. Zumindest deinem Sprachgebrauch von \"beweisen\" zufolge.

Das ist irrelevant.
Executables kÃ¶nnen nicht random sein.

Genauso wenig wie komprimierte Dateien - denn denen liegen *nicht*
zufÃ¤llige Ausgangsdaten zugrunde und das Ergebnis ist exakt
vorherbestimmbar.

Diese Aussage ist falsch.

Nein, sie ist - bezogen auf nicht zufÃ¤llige Ausgangsdaten(!) - richtig.

Der Beweis von Kolmogorow (et al) liegt seit 1964 vor und wurde mehrfach gepostet.
Komplett-Ignorierung?

Nein, Eingrenzung auf \"nicht zufÃ¤llige Ausgangsdaten\". Wenn man die
Ausgangsdaten kennt, weiÃ man auch, wie die komprimierten Daten dazu
aussehen. Die Zahl der Komprimierungsverfahren ist ebenfalls endlich.

--
Arno Welzel
https://arnowelzel.de

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

Hanno Foest

Guest

Helmut Schellong

Guest

Helmut Schellong

Guest

Helmut Schellong

Guest

Helmut Schellong

Guest

Helmut Schellong

Guest

Helmut Schellong

Guest

Holger Schieferdecker

Guest

Holger Schieferdecker

Guest

Helmut Schellong

Guest

Hanno Foest

Guest

Helmut Schellong

Guest

Hans-Peter Diettrich

Guest

Ole Jansen

Guest

Helmut Schellong

Guest

Hans-Peter Diettrich

Guest

Helmut Schellong

Guest

Helmut Schellong

Guest

Arno Welzel

Guest

Arno Welzel

Guest

Log in

Welcome to EDABoard.com

Sponsor

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