Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

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

2 views
Skip to first unread message

Helmut Schellong

unread,
May 12, 2022, 11:41:49 AM5/12/22
to

Getestete Algorithmen: Dragon, Rabbit, Spritz.

http://www.schellong.de/htm/dragon.c.html#NIST

Mehrere 100KB Daten zum Vergleich aufbereitet plus NIST-Dokumentation.


--
Mit freundlichen Grüßen
Helmut Schellong v...@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/bsd.htm

Helmut Schellong

unread,
May 16, 2022, 9:36:38 AM5/16/22
to
On 05/12/2022 17:42, Helmut Schellong wrote:
>
> Getestete Algorithmen: Dragon, Rabbit, Spritz.
>
> http://www.schellong.de/htm/dragon.c.html#NIST
>
> Mehrere 100KB Daten zum Vergleich aufbereitet plus NIST-Dokumentation.
>
>

Neuigkeiten:

Inhaltsverzeichnis.
Link auf Skript-Inhalt.
rand() und random() hinzugefügt.
Eine komprimierte Datei ist ähnlich gut, wie ein kryptographischer Algorithmus!
Weit besser als rand()/random().


--
Mit freundlichen Grüßen
Helmut Schellong v...@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

Bonita Montero

unread,
May 16, 2022, 1:03:57 PM5/16/22
to
Am 16.05.2022 um 15:37 schrieb Helmut Schellong:
> On 05/12/2022 17:42, Helmut Schellong wrote:
>>
>> Getestete Algorithmen: Dragon, Rabbit, Spritz.
>>
>> http://www.schellong.de/htm/dragon.c.html#NIST
>>
>> Mehrere 100KB Daten zum Vergleich aufbereitet plus NIST-Dokumentation.
>>
>>
>
> Neuigkeiten:
>
> Inhaltsverzeichnis.
> Link auf Skript-Inhalt.
> rand() und random() hinzugefügt.
> Eine komprimierte Datei ist ähnlich gut, wie ein kryptographischer
> Algorithmus!

Mathematischer Beweis bitte, keine Worte. Hrhr.

> Weit besser als rand()/random().

Das kann man nicht pauschal sagen, sondern das hängt von der
Implementation ab.

Helmut Schellong

unread,
May 16, 2022, 2:46:41 PM5/16/22
to
On 05/16/2022 19:03, Bonita Montero wrote:
> Am 16.05.2022 um 15:37 schrieb Helmut Schellong:
>> On 05/12/2022 17:42, Helmut Schellong wrote:
>>>
>>> Getestete Algorithmen: Dragon, Rabbit, Spritz.
>>>
>>> http://www.schellong.de/htm/dragon.c.html#NIST
>>>
>>> Mehrere 100KB Daten zum Vergleich aufbereitet plus NIST-Dokumentation.
>>>
>>>
>>
>> Neuigkeiten:
>>
>> Inhaltsverzeichnis.
>> Link auf Skript-Inhalt.
>> rand() und random() hinzugefügt.
>> Eine komprimierte Datei ist ähnlich gut, wie ein kryptographischer Algorithmus!
>
> Mathematischer Beweis bitte, keine Worte. Hrhr.

Der Test mit der Test-Suite ist der Beweis.
Die mathematischen Beweise stehen in der .PDF, die ich verlinkt habe.

>> Weit besser als rand()/random().
>
> Das kann man nicht pauschal sagen, sondern das hängt von der
> Implementation ab.

Alle Funktionen, die nicht kryptographisch sind, sind
ähnlich schlecht wie rand()/random().

Bonita Montero

unread,
May 16, 2022, 9:40:19 PM5/16/22
to
Am 16.05.2022 um 20:47 schrieb Helmut Schellong:
> On 05/16/2022 19:03, Bonita Montero wrote:
>> Am 16.05.2022 um 15:37 schrieb Helmut Schellong:
>>> On 05/12/2022 17:42, Helmut Schellong wrote:
>>>>
>>>> Getestete Algorithmen: Dragon, Rabbit, Spritz.
>>>>
>>>> http://www.schellong.de/htm/dragon.c.html#NIST
>>>>
>>>> Mehrere 100KB Daten zum Vergleich aufbereitet plus NIST-Dokumentation.
>>>>
>>>>
>>>
>>> Neuigkeiten:
>>>
>>> Inhaltsverzeichnis.
>>> Link auf Skript-Inhalt.
>>> rand() und random() hinzugefügt.
>>> Eine komprimierte Datei ist ähnlich gut, wie ein kryptographischer
>>> Algorithmus!
>>
>> Mathematischer Beweis bitte, keine Worte. Hrhr.
>
> Der Test mit der Test-Suite ist der Beweis.

LOL, Du bist so dämlich. Alt-Ultra-Nerd.

> Die mathematischen Beweise stehen in der .PDF, die ich verlinkt habe.

Es hat sicher noch niemand bewiesen, dass komprimierte Daten
ein guter Zufalls-Generator wären. Ganz einfach weil das eine
komplett schwachsinnige Aussage ist.

> Alle Funktionen, die nicht kryptographisch sind, sind
> ähnlich schlecht wie rand()/random().

Ne, es gibt zwischen den nicht-kryptografischen Zufallsgeneratoren
riesige Unterschiede. Ein LCG ist halt z.B. nix gegen einen Mersenne
Twister.

Helmut Schellong

unread,
May 17, 2022, 4:53:56 AM5/17/22
to
On 05/17/2022 03:40, Bonita Montero wrote:
> Am 16.05.2022 um 20:47 schrieb Helmut Schellong:
>> On 05/16/2022 19:03, Bonita Montero wrote:
>>> Am 16.05.2022 um 15:37 schrieb Helmut Schellong:
>>>> On 05/12/2022 17:42, Helmut Schellong wrote:
>>>>>
>>>>> Getestete Algorithmen: Dragon, Rabbit, Spritz.
>>>>>
>>>>> http://www.schellong.de/htm/dragon.c.html#NIST
>>>>>
>>>>> Mehrere 100KB Daten zum Vergleich aufbereitet plus NIST-Dokumentation.
>>>>>
>>>>>
>>>>
>>>> Neuigkeiten:
>>>>
>>>> Inhaltsverzeichnis.
>>>> Link auf Skript-Inhalt.
>>>> rand() und random() hinzugefügt.
>>>> Eine komprimierte Datei ist ähnlich gut, wie ein kryptographischer Algorithmus!
>>>
>>> Mathematischer Beweis bitte, keine Worte. Hrhr.
>>
>> Der Test mit der Test-Suite ist der Beweis.
>
> LOL, Du bist so dämlich. Alt-Ultra-Nerd.

Selbstverständlich ist ein Lauf mit der NIST-Test-Suite das einzige
frei verfügbare Beweismittel mit Referenz-Charakter.

>> Die mathematischen Beweise stehen in der .PDF, die ich verlinkt habe.
>
> Es hat sicher noch niemand bewiesen, dass komprimierte Daten
> ein guter Zufalls-Generator wären. Ganz einfach weil das eine
> komplett schwachsinnige Aussage ist.

Es wurden hier schon vor langer Zeit Zusammenhänge entdeckt.
Eine Zufallsdatei ist nicht/kaum komprimierbar.
Eine maximal stark komprimierte Datei hat zufälligen Inhalt.
Beweis siehe unten.

Ich habe auch mit einer komprimierten Datei einen Testlauf durchgeführt.
http://www.schellong.de/htm/dragon.c.html#NIST
Aber ich glaube, Du willst Beweise gar nicht sehen, sondern nur abseits davon
Deinen frei erfundenen Mist verzapfen.

https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-22r1a.pdf

Darin werden die 15 Tests auf 40 Seiten beschrieben (Kapitel 2).
Die mathematische Grundlage der Tests wird auf 24 Seiten beschrieben (Kapitel 3).

>> Alle Funktionen, die nicht kryptographisch sind, sind
>> ähnlich schlecht wie rand()/random().
>
> Ne, es gibt zwischen den nicht-kryptografischen Zufallsgeneratoren
> riesige Unterschiede. Ein LCG ist halt z.B. nix gegen einen Mersenne
> Twister.

http://www.schellong.de/htm/dragon.c.html#NIST

Dort sind auch die Testergebnisse von rand() und random().
Im Vergleich - grottenschlecht!
Z.B. lrand48() ist nicht besser.
Datei.xz ist voll gut!


random() rand() lrand48() sind praktisch Totalausfälle (------ *):

------------------------------------------------------------------------------
RESULTS FOR THE UNIFORMITY OF P-VALUES AND THE PROPORTION OF PASSING SEQUENCES
------------------------------------------------------------------------------
generator is </usr/zorandom>
------------------------------------------------------------------------------
C1 C2 C3 C4 C5 C6 C7 C8 C9 C10 P-VALUE PROPORTION STATISTICAL TEST
------------------------------------------------------------------------------
5 0 0 0 0 0 0 0 0 0 ---- 0/5 * Frequency
0 0 0 0 0 0 0 0 0 5 ---- 5/5 BlockFrequency
5 0 0 0 0 0 0 0 0 0 ---- 0/5 * CumulativeSums
5 0 0 0 0 0 0 0 0 0 ---- 0/5 * CumulativeSums
5 0 0 0 0 0 0 0 0 0 ---- 0/5 * Runs
5 0 0 0 0 0 0 0 0 0 ---- 0/5 * LongestRun
5 0 0 0 0 0 0 0 0 0 ---- 0/5 * Rank
5 0 0 0 0 0 0 0 0 0 ---- 0/5 * FFT
5 0 0 0 0 0 0 0 0 0 ---- 0/5 * NonOverlappingTemplate
5 0 0 0 0 0 0 0 0 0 ---- 0/5 * NonOverlappingTemplate
5 0 0 0 0 0 0 0 0 0 ---- 0/5 * NonOverlappingTemplate
5 0 0 0 0 0 0 0 0 0 ---- 5/5 NonOverlappingTemplate
5 0 0 0 0 0 0 0 0 0 ---- 0/5 * NonOverlappingTemplate
5 0 0 0 0 0 0 0 0 0 ---- 0/5 * NonOverlappingTemplate
0 0 0 0 0 0 0 0 0 5 ---- 5/5 NonOverlappingTemplate
5 0 0 0 0 0 0 0 0 0 ---- 0/5 * NonOverlappingTemplate
5 0 0 0 0 0 0 0 0 0 ---- 0/5 * NonOverlappingTemplate
5 0 0 0 0 0 0 0 0 0 ---- 0/5 * NonOverlappingTemplate
5 0 0 0 0 0 0 0 0 0 ---- 0/5 * NonOverlappingTemplate
5 0 0 0 0 0 0 0 0 0 ---- 0/5 * NonOverlappingTemplate
5 0 0 0 0 0 0 0 0 0 ---- 0/5 * NonOverlappingTemplate
5 0 0 0 0 0 0 0 0 0 ---- 0/5 * NonOverlappingTemplate
0 0 0 0 0 0 0 0 0 5 ---- 5/5 NonOverlappingTemplate
5 0 0 0 0 0 0 0 0 0 ---- 0/5 * NonOverlappingTemplate
5 0 0 0 0 0 0 0 0 0 ---- 0/5 * NonOverlappingTemplate
5 0 0 0 0 0 0 0 0 0 ---- 0/5 * NonOverlappingTemplate
0 0 0 0 0 0 0 0 0 5 ---- 5/5 NonOverlappingTemplate
5 0 0 0 0 0 0 0 0 0 ---- 0/5 * NonOverlappingTemplate
0 0 0 5 0 0 0 0 0 0 ---- 5/5 NonOverlappingTemplate
5 0 0 0 0 0 0 0 0 0 ---- 0/5 * NonOverlappingTemplate
5 0 0 0 0 0 0 0 0 0 ---- 0/5 * NonOverlappingTemplate
5 0 0 0 0 0 0 0 0 0 ---- 0/5 * NonOverlappingTemplate
5 0 0 0 0 0 0 0 0 0 ---- 0/5 * NonOverlappingTemplate
5 0 0 0 0 0 0 0 0 0 ---- 0/5 * NonOverlappingTemplate
0 0 0 0 0 0 0 0 0 5 ---- 5/5 NonOverlappingTemplate
5 0 0 0 0 0 0 0 0 0 ---- 0/5 * NonOverlappingTemplate
5 0 0 0 0 0 0 0 0 0 ---- 0/5 * NonOverlappingTemplate
5 0 0 0 0 0 0 0 0 0 ---- 0/5 * NonOverlappingTemplate
5 0 0 0 0 0 0 0 0 0 ---- 0/5 * NonOverlappingTemplate
5 0 0 0 0 0 0 0 0 0 ---- 0/5 * NonOverlappingTemplate
5 0 0 0 0 0 0 0 0 0 ---- 0/5 * NonOverlappingTemplate
5 0 0 0 0 0 0 0 0 0 ---- 0/5 * NonOverlappingTemplate
5 0 0 0 0 0 0 0 0 0 ---- 0/5 * NonOverlappingTemplate
5 0 0 0 0 0 0 0 0 0 ---- 0/5 * NonOverlappingTemplate
5 0 0 0 0 0 0 0 0 0 ---- 0/5 * NonOverlappingTemplate
5 0 0 0 0 0 0 0 0 0 ---- 0/5 * NonOverlappingTemplate
0 0 0 0 0 0 0 0 0 5 ---- 5/5 NonOverlappingTemplate
0 0 0 0 0 0 0 0 0 5 ---- 5/5 NonOverlappingTemplate
0 0 0 0 0 0 0 0 0 5 ---- 5/5 NonOverlappingTemplate
0 0 0 0 0 0 0 0 0 5 ---- 5/5 NonOverlappingTemplate
5 0 0 0 0 0 0 0 0 0 ---- 0/5 * NonOverlappingTemplate
5 0 0 0 0 0 0 0 0 0 ---- 0/5 * NonOverlappingTemplate
5 0 0 0 0 0 0 0 0 0 ---- 5/5 NonOverlappingTemplate
0 0 0 0 0 0 0 0 5 0 ---- 5/5 NonOverlappingTemplate
5 0 0 0 0 0 0 0 0 0 ---- 0/5 * NonOverlappingTemplate
5 0 0 0 0 0 0 0 0 0 ---- 5/5 NonOverlappingTemplate
5 0 0 0 0 0 0 0 0 0 ---- 0/5 * NonOverlappingTemplate
5 0 0 0 0 0 0 0 0 0 ---- 0/5 * NonOverlappingTemplate
5 0 0 0 0 0 0 0 0 0 ---- 0/5 * NonOverlappingTemplate
5 0 0 0 0 0 0 0 0 0 ---- 0/5 * NonOverlappingTemplate
0 0 0 0 0 0 0 0 5 0 ---- 5/5 NonOverlappingTemplate
5 0 0 0 0 0 0 0 0 0 ---- 0/5 * NonOverlappingTemplate
0 0 0 5 0 0 0 0 0 0 ---- 5/5 NonOverlappingTemplate
0 0 0 0 0 0 0 0 5 0 ---- 5/5 NonOverlappingTemplate
5 0 0 0 0 0 0 0 0 0 ---- 0/5 * NonOverlappingTemplate
0 0 0 5 0 0 0 0 0 0 ---- 5/5 NonOverlappingTemplate
5 0 0 0 0 0 0 0 0 0 ---- 5/5 NonOverlappingTemplate
5 0 0 0 0 0 0 0 0 0 ---- 0/5 * NonOverlappingTemplate
0 0 0 0 0 0 0 0 0 5 ---- 5/5 NonOverlappingTemplate
5 0 0 0 0 0 0 0 0 0 ---- 0/5 * NonOverlappingTemplate
5 0 0 0 0 0 0 0 0 0 ---- 0/5 * NonOverlappingTemplate
0 0 0 0 0 0 0 0 5 0 ---- 5/5 NonOverlappingTemplate
5 0 0 0 0 0 0 0 0 0 ---- 0/5 * NonOverlappingTemplate
5 0 0 0 0 0 0 0 0 0 ---- 0/5 * NonOverlappingTemplate
5 0 0 0 0 0 0 0 0 0 ---- 0/5 * NonOverlappingTemplate
5 0 0 0 0 0 0 0 0 0 ---- 0/5 * NonOverlappingTemplate
0 0 0 0 0 0 0 0 0 5 ---- 5/5 NonOverlappingTemplate
5 0 0 0 0 0 0 0 0 0 ---- 0/5 * NonOverlappingTemplate
0 0 0 0 0 0 0 0 5 0 ---- 5/5 NonOverlappingTemplate
5 0 0 0 0 0 0 0 0 0 ---- 0/5 * NonOverlappingTemplate
5 0 0 0 0 0 0 0 0 0 ---- 0/5 * NonOverlappingTemplate
5 0 0 0 0 0 0 0 0 0 ---- 0/5 * NonOverlappingTemplate
5 0 0 0 0 0 0 0 0 0 ---- 0/5 * NonOverlappingTemplate
5 0 0 0 0 0 0 0 0 0 ---- 0/5 * NonOverlappingTemplate
0 0 0 0 0 0 0 0 0 5 ---- 5/5 NonOverlappingTemplate
5 0 0 0 0 0 0 0 0 0 ---- 0/5 * NonOverlappingTemplate
5 0 0 0 0 0 0 0 0 0 ---- 0/5 * NonOverlappingTemplate
5 0 0 0 0 0 0 0 0 0 ---- 0/5 * NonOverlappingTemplate
5 0 0 0 0 0 0 0 0 0 ---- 0/5 * NonOverlappingTemplate
5 0 0 0 0 0 0 0 0 0 ---- 0/5 * NonOverlappingTemplate
5 0 0 0 0 0 0 0 0 0 ---- 0/5 * NonOverlappingTemplate
5 0 0 0 0 0 0 0 0 0 ---- 0/5 * NonOverlappingTemplate
5 0 0 0 0 0 0 0 0 0 ---- 0/5 * NonOverlappingTemplate
5 0 0 0 0 0 0 0 0 0 ---- 0/5 * NonOverlappingTemplate
0 0 0 0 0 0 0 0 0 5 ---- 5/5 NonOverlappingTemplate
5 0 0 0 0 0 0 0 0 0 ---- 0/5 * NonOverlappingTemplate
5 0 0 0 0 0 0 0 0 0 ---- 0/5 * NonOverlappingTemplate
5 0 0 0 0 0 0 0 0 0 ---- 0/5 * NonOverlappingTemplate
5 0 0 0 0 0 0 0 0 0 ---- 0/5 * NonOverlappingTemplate
5 0 0 0 0 0 0 0 0 0 ---- 0/5 * NonOverlappingTemplate
0 0 0 0 0 5 0 0 0 0 ---- 5/5 NonOverlappingTemplate
5 0 0 0 0 0 0 0 0 0 ---- 0/5 * NonOverlappingTemplate
5 0 0 0 0 0 0 0 0 0 ---- 0/5 * NonOverlappingTemplate
5 0 0 0 0 0 0 0 0 0 ---- 0/5 * NonOverlappingTemplate
5 0 0 0 0 0 0 0 0 0 ---- 0/5 * NonOverlappingTemplate
5 0 0 0 0 0 0 0 0 0 ---- 0/5 * NonOverlappingTemplate
5 0 0 0 0 0 0 0 0 0 ---- 0/5 * NonOverlappingTemplate
5 0 0 0 0 0 0 0 0 0 ---- 0/5 * NonOverlappingTemplate
5 0 0 0 0 0 0 0 0 0 ---- 0/5 * NonOverlappingTemplate
0 0 0 0 0 0 0 0 5 0 ---- 5/5 NonOverlappingTemplate
5 0 0 0 0 0 0 0 0 0 ---- 0/5 * NonOverlappingTemplate
0 0 0 0 0 0 0 0 0 5 ---- 5/5 NonOverlappingTemplate
5 0 0 0 0 0 0 0 0 0 ---- 0/5 * NonOverlappingTemplate
5 0 0 0 0 0 0 0 0 0 ---- 0/5 * NonOverlappingTemplate
5 0 0 0 0 0 0 0 0 0 ---- 0/5 * NonOverlappingTemplate
5 0 0 0 0 0 0 0 0 0 ---- 0/5 * NonOverlappingTemplate
5 0 0 0 0 0 0 0 0 0 ---- 0/5 * NonOverlappingTemplate
0 5 0 0 0 0 0 0 0 0 ---- 5/5 NonOverlappingTemplate
5 0 0 0 0 0 0 0 0 0 ---- 0/5 * NonOverlappingTemplate
5 0 0 0 0 0 0 0 0 0 ---- 0/5 * NonOverlappingTemplate
0 0 0 0 0 0 0 0 0 5 ---- 5/5 NonOverlappingTemplate
5 0 0 0 0 0 0 0 0 0 ---- 0/5 * NonOverlappingTemplate
5 0 0 0 0 0 0 0 0 0 ---- 0/5 * NonOverlappingTemplate
0 0 0 0 0 0 5 0 0 0 ---- 5/5 NonOverlappingTemplate
0 0 0 0 0 0 5 0 0 0 ---- 5/5 NonOverlappingTemplate
5 0 0 0 0 0 0 0 0 0 ---- 0/5 * NonOverlappingTemplate
0 0 0 0 0 0 0 0 0 5 ---- 5/5 NonOverlappingTemplate
5 0 0 0 0 0 0 0 0 0 ---- 0/5 * NonOverlappingTemplate
5 0 0 0 0 0 0 0 0 0 ---- 0/5 * NonOverlappingTemplate
5 0 0 0 0 0 0 0 0 0 ---- 0/5 * NonOverlappingTemplate
5 0 0 0 0 0 0 0 0 0 ---- 0/5 * NonOverlappingTemplate
5 0 0 0 0 0 0 0 0 0 ---- 5/5 NonOverlappingTemplate
5 0 0 0 0 0 0 0 0 0 ---- 0/5 * NonOverlappingTemplate
5 0 0 0 0 0 0 0 0 0 ---- 0/5 * NonOverlappingTemplate
5 0 0 0 0 0 0 0 0 0 ---- 0/5 * NonOverlappingTemplate
5 0 0 0 0 0 0 0 0 0 ---- 0/5 * NonOverlappingTemplate
5 0 0 0 0 0 0 0 0 0 ---- 0/5 * NonOverlappingTemplate
5 0 0 0 0 0 0 0 0 0 ---- 0/5 * NonOverlappingTemplate
5 0 0 0 0 0 0 0 0 0 ---- 0/5 * NonOverlappingTemplate
5 0 0 0 0 0 0 0 0 0 ---- 0/5 * NonOverlappingTemplate
5 0 0 0 0 0 0 0 0 0 ---- 0/5 * NonOverlappingTemplate
5 0 0 0 0 0 0 0 0 0 ---- 0/5 * NonOverlappingTemplate
5 0 0 0 0 0 0 0 0 0 ---- 0/5 * NonOverlappingTemplate
0 0 0 5 0 0 0 0 0 0 ---- 5/5 NonOverlappingTemplate
5 0 0 0 0 0 0 0 0 0 ---- 0/5 * NonOverlappingTemplate
5 0 0 0 0 0 0 0 0 0 ---- 0/5 * NonOverlappingTemplate
5 0 0 0 0 0 0 0 0 0 ---- 0/5 * NonOverlappingTemplate
5 0 0 0 0 0 0 0 0 0 ---- 5/5 NonOverlappingTemplate
5 0 0 0 0 0 0 0 0 0 ---- 0/5 * NonOverlappingTemplate
5 0 0 0 0 0 0 0 0 0 ---- 0/5 * NonOverlappingTemplate
5 0 0 0 0 0 0 0 0 0 ---- 5/5 NonOverlappingTemplate
5 0 0 0 0 0 0 0 0 0 ---- 0/5 * NonOverlappingTemplate
5 0 0 0 0 0 0 0 0 0 ---- 0/5 * NonOverlappingTemplate
0 5 0 0 0 0 0 0 0 0 ---- 5/5 NonOverlappingTemplate
0 0 0 5 0 0 0 0 0 0 ---- 5/5 NonOverlappingTemplate
5 0 0 0 0 0 0 0 0 0 ---- 0/5 * NonOverlappingTemplate
5 0 0 0 0 0 0 0 0 0 ---- 0/5 * OverlappingTemplate
0 0 5 0 0 0 0 0 0 0 ---- 5/5 Universal
5 0 0 0 0 0 0 0 0 0 ---- 0/5 * ApproximateEntropy
0 0 0 0 0 0 0 0 0 0 ---- ------ RandomExcursions
0 0 0 0 0 0 0 0 0 0 ---- ------ RandomExcursions
0 0 0 0 0 0 0 0 0 0 ---- ------ RandomExcursions
0 0 0 0 0 0 0 0 0 0 ---- ------ RandomExcursions
0 0 0 0 0 0 0 0 0 0 ---- ------ RandomExcursions
0 0 0 0 0 0 0 0 0 0 ---- ------ RandomExcursions
0 0 0 0 0 0 0 0 0 0 ---- ------ RandomExcursions
0 0 0 0 0 0 0 0 0 0 ---- ------ RandomExcursions
0 0 0 0 0 0 0 0 0 0 ---- ------ RandomExcursionsVariant
0 0 0 0 0 0 0 0 0 0 ---- ------ RandomExcursionsVariant
0 0 0 0 0 0 0 0 0 0 ---- ------ RandomExcursionsVariant
0 0 0 0 0 0 0 0 0 0 ---- ------ RandomExcursionsVariant
0 0 0 0 0 0 0 0 0 0 ---- ------ RandomExcursionsVariant
0 0 0 0 0 0 0 0 0 0 ---- ------ RandomExcursionsVariant
0 0 0 0 0 0 0 0 0 0 ---- ------ RandomExcursionsVariant
0 0 0 0 0 0 0 0 0 0 ---- ------ RandomExcursionsVariant
0 0 0 0 0 0 0 0 0 0 ---- ------ RandomExcursionsVariant
0 0 0 0 0 0 0 0 0 0 ---- ------ RandomExcursionsVariant
0 0 0 0 0 0 0 0 0 0 ---- ------ RandomExcursionsVariant
0 0 0 0 0 0 0 0 0 0 ---- ------ RandomExcursionsVariant
0 0 0 0 0 0 0 0 0 0 ---- ------ RandomExcursionsVariant
0 0 0 0 0 0 0 0 0 0 ---- ------ RandomExcursionsVariant
0 0 0 0 0 0 0 0 0 0 ---- ------ RandomExcursionsVariant
0 0 0 0 0 0 0 0 0 0 ---- ------ RandomExcursionsVariant
0 0 0 0 0 0 0 0 0 0 ---- ------ RandomExcursionsVariant
0 0 0 0 0 0 0 0 0 0 ---- ------ RandomExcursionsVariant
5 0 0 0 0 0 0 0 0 0 ---- 0/5 * Serial
5 0 0 0 0 0 0 0 0 0 ---- 0/5 * Serial
5 0 0 0 0 0 0 0 0 0 ---- 0/5 * LinearComplexity

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
The minimum pass rate for each statistical test with the exception of the
random excursion (variant) test is approximately = 4 for a
sample size = 5 binary sequences.

The minimum pass rate for the random excursion (variant) test is undefined.

For further guidelines construct a probability table using the MAPLE program
provided in the addendum section of the documentation.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
________________________________________________________________________________

FILE = /usr/zorandom ALPHA = 0.0100
________________________________________________________________________________

BITSREAD = 10000000 0s = 5017875 1s = 4982125
BITSREAD = 10000000 0s = 5017875 1s = 4982125
BITSREAD = 10000000 0s = 5017875 1s = 4982125
BITSREAD = 10000000 0s = 5017875 1s = 4982125
BITSREAD = 10000000 0s = 5017875 1s = 4982125



Komprimierte Datei (Erfolg=100%):

------------------------------------------------------------------------------
RESULTS FOR THE UNIFORMITY OF P-VALUES AND THE PROPORTION OF PASSING SEQUENCES
------------------------------------------------------------------------------
generator is </usr/z.a.xz>
------------------------------------------------------------------------------
C1 C2 C3 C4 C5 C6 C7 C8 C9 C10 P-VALUE PROPORTION STATISTICAL TEST
------------------------------------------------------------------------------
1 0 1 1 0 0 0 0 1 1 ---- 5/5 Frequency
0 0 1 1 1 0 1 1 0 0 ---- 5/5 BlockFrequency
1 1 0 1 0 0 0 2 0 0 ---- 5/5 CumulativeSums
1 0 0 0 2 0 0 0 1 1 ---- 5/5 CumulativeSums
0 1 1 1 1 0 0 0 0 1 ---- 5/5 Runs
0 0 0 1 1 0 1 0 0 2 ---- 5/5 LongestRun
1 0 0 2 0 1 0 0 1 0 ---- 5/5 Rank
0 0 1 0 3 0 1 0 0 0 ---- 5/5 FFT
1 3 0 0 0 0 0 0 0 1 ---- 5/5 NonOverlappingTemplate
1 1 1 0 0 1 1 0 0 0 ---- 5/5 NonOverlappingTemplate
1 1 1 0 1 0 0 1 0 0 ---- 4/5 NonOverlappingTemplate
1 2 0 1 0 0 0 0 1 0 ---- 5/5 NonOverlappingTemplate
1 0 1 1 1 0 0 0 0 1 ---- 5/5 NonOverlappingTemplate
2 1 1 0 0 0 0 1 0 0 ---- 5/5 NonOverlappingTemplate
0 0 1 0 1 0 0 2 0 1 ---- 5/5 NonOverlappingTemplate
0 0 0 1 1 0 0 1 1 1 ---- 5/5 NonOverlappingTemplate
1 0 0 0 1 0 1 1 0 1 ---- 5/5 NonOverlappingTemplate
1 0 0 0 1 0 1 1 1 0 ---- 5/5 NonOverlappingTemplate
0 1 1 2 0 0 0 1 0 0 ---- 5/5 NonOverlappingTemplate
2 0 0 0 1 0 2 0 0 0 ---- 4/5 NonOverlappingTemplate
0 1 1 0 0 0 0 1 1 1 ---- 5/5 NonOverlappingTemplate
0 1 0 0 0 0 1 0 1 2 ---- 5/5 NonOverlappingTemplate
1 2 1 0 0 0 0 0 0 1 ---- 4/5 NonOverlappingTemplate
0 0 0 0 1 1 0 1 1 1 ---- 5/5 NonOverlappingTemplate
0 0 0 0 1 2 2 0 0 0 ---- 5/5 NonOverlappingTemplate
2 1 0 0 0 0 0 1 0 1 ---- 5/5 NonOverlappingTemplate
1 1 0 0 1 0 1 1 0 0 ---- 5/5 NonOverlappingTemplate
1 1 0 1 0 0 1 0 1 0 ---- 5/5 NonOverlappingTemplate
2 0 0 0 0 1 1 1 0 0 ---- 5/5 NonOverlappingTemplate
0 2 1 1 0 0 0 0 1 0 ---- 5/5 NonOverlappingTemplate
0 0 0 1 0 2 0 0 0 2 ---- 5/5 NonOverlappingTemplate
2 0 0 0 0 1 1 1 0 0 ---- 5/5 NonOverlappingTemplate
0 0 1 1 1 0 0 1 1 0 ---- 5/5 NonOverlappingTemplate
0 0 0 0 0 1 2 1 1 0 ---- 5/5 NonOverlappingTemplate
0 1 0 2 0 0 1 1 0 0 ---- 5/5 NonOverlappingTemplate
1 0 1 0 1 2 0 0 0 0 ---- 5/5 NonOverlappingTemplate
0 0 0 1 0 1 1 0 1 1 ---- 5/5 NonOverlappingTemplate
0 0 0 0 0 0 2 1 1 1 ---- 5/5 NonOverlappingTemplate
0 2 0 0 0 0 1 1 1 0 ---- 5/5 NonOverlappingTemplate
0 1 0 1 1 0 1 0 0 1 ---- 5/5 NonOverlappingTemplate
0 0 0 1 0 0 0 0 2 2 ---- 5/5 NonOverlappingTemplate
1 0 3 0 0 0 0 1 0 0 ---- 5/5 NonOverlappingTemplate
0 0 2 1 0 0 0 0 0 2 ---- 5/5 NonOverlappingTemplate
1 0 1 0 0 2 0 1 0 0 ---- 4/5 NonOverlappingTemplate
2 0 1 1 0 0 0 0 1 0 ---- 4/5 NonOverlappingTemplate
0 0 1 0 1 1 1 0 0 1 ---- 5/5 NonOverlappingTemplate
2 1 1 1 0 0 0 0 0 0 ---- 5/5 NonOverlappingTemplate
0 1 0 2 0 0 2 0 0 0 ---- 5/5 NonOverlappingTemplate
1 0 1 0 1 0 0 0 1 1 ---- 5/5 NonOverlappingTemplate
0 1 0 0 0 0 4 0 0 0 ---- 5/5 NonOverlappingTemplate
1 1 0 0 0 0 0 0 2 1 ---- 5/5 NonOverlappingTemplate
0 0 0 1 0 1 0 0 0 3 ---- 5/5 NonOverlappingTemplate
0 1 0 0 0 1 0 0 3 0 ---- 5/5 NonOverlappingTemplate
1 1 0 0 1 0 2 0 0 0 ---- 5/5 NonOverlappingTemplate
0 3 0 0 0 1 0 1 0 0 ---- 5/5 NonOverlappingTemplate
2 1 0 0 1 0 0 0 1 0 ---- 5/5 NonOverlappingTemplate
0 0 0 0 0 2 0 1 2 0 ---- 5/5 NonOverlappingTemplate
1 0 0 0 2 1 1 0 0 0 ---- 5/5 NonOverlappingTemplate
1 1 0 1 0 0 0 0 1 1 ---- 5/5 NonOverlappingTemplate
0 0 0 0 1 1 0 1 1 1 ---- 5/5 NonOverlappingTemplate
0 0 4 0 0 0 0 1 0 0 ---- 5/5 NonOverlappingTemplate
0 0 0 1 2 0 0 1 1 0 ---- 5/5 NonOverlappingTemplate
0 1 0 0 2 0 1 1 0 0 ---- 5/5 NonOverlappingTemplate
1 1 0 0 0 0 1 0 1 1 ---- 5/5 NonOverlappingTemplate
1 1 0 0 2 0 0 1 0 0 ---- 5/5 NonOverlappingTemplate
0 0 2 0 0 0 1 2 0 0 ---- 5/5 NonOverlappingTemplate
0 4 1 0 0 0 0 0 0 0 ---- 5/5 NonOverlappingTemplate
0 2 0 2 0 0 0 0 1 0 ---- 5/5 NonOverlappingTemplate
0 1 0 0 0 1 0 0 3 0 ---- 5/5 NonOverlappingTemplate
0 1 1 0 0 1 1 0 0 1 ---- 5/5 NonOverlappingTemplate
1 0 0 0 0 1 0 1 1 1 ---- 5/5 NonOverlappingTemplate
0 0 1 0 1 2 0 0 0 1 ---- 5/5 NonOverlappingTemplate
0 1 0 0 1 1 0 2 0 0 ---- 5/5 NonOverlappingTemplate
0 0 1 0 0 0 0 1 1 2 ---- 5/5 NonOverlappingTemplate
0 1 1 0 0 2 0 0 1 0 ---- 5/5 NonOverlappingTemplate
1 0 2 0 2 0 0 0 0 0 ---- 4/5 NonOverlappingTemplate
1 1 1 0 0 1 1 0 0 0 ---- 5/5 NonOverlappingTemplate
1 0 1 0 2 0 0 1 0 0 ---- 5/5 NonOverlappingTemplate
0 0 1 1 1 1 0 0 1 0 ---- 5/5 NonOverlappingTemplate
0 0 0 0 3 0 0 1 1 0 ---- 5/5 NonOverlappingTemplate
1 1 0 0 0 0 1 0 1 1 ---- 5/5 NonOverlappingTemplate
0 0 1 0 0 1 0 1 1 1 ---- 5/5 NonOverlappingTemplate
1 3 0 0 0 0 0 0 0 1 ---- 5/5 NonOverlappingTemplate
1 0 1 0 0 0 0 1 1 1 ---- 5/5 NonOverlappingTemplate
1 0 0 0 1 1 1 0 1 0 ---- 5/5 NonOverlappingTemplate
0 3 0 0 0 0 1 0 1 0 ---- 5/5 NonOverlappingTemplate
0 0 0 0 2 0 1 0 1 1 ---- 5/5 NonOverlappingTemplate
1 0 1 1 0 0 1 0 1 0 ---- 5/5 NonOverlappingTemplate
0 1 0 1 0 2 0 1 0 0 ---- 5/5 NonOverlappingTemplate
0 0 0 1 0 0 2 1 0 1 ---- 5/5 NonOverlappingTemplate
0 2 1 0 0 1 0 0 1 0 ---- 5/5 NonOverlappingTemplate
0 0 1 0 2 1 0 0 1 0 ---- 5/5 NonOverlappingTemplate
0 1 0 0 2 0 0 1 0 1 ---- 5/5 NonOverlappingTemplate
2 0 1 0 0 1 0 1 0 0 ---- 5/5 NonOverlappingTemplate
1 0 0 1 1 0 1 0 0 1 ---- 5/5 NonOverlappingTemplate
0 0 2 1 1 1 0 0 0 0 ---- 5/5 NonOverlappingTemplate
1 0 0 0 1 0 1 0 2 0 ---- 5/5 NonOverlappingTemplate
0 2 1 0 0 0 0 2 0 0 ---- 5/5 NonOverlappingTemplate
0 1 0 0 2 0 0 2 0 0 ---- 5/5 NonOverlappingTemplate
1 2 0 0 1 0 0 0 0 1 ---- 5/5 NonOverlappingTemplate
2 0 2 0 1 0 0 0 0 0 ---- 5/5 NonOverlappingTemplate
1 1 0 0 1 0 1 0 1 0 ---- 4/5 NonOverlappingTemplate
0 1 0 3 0 0 0 1 0 0 ---- 5/5 NonOverlappingTemplate
0 0 0 1 0 3 0 1 0 0 ---- 5/5 NonOverlappingTemplate
0 0 1 0 1 0 1 2 0 0 ---- 5/5 NonOverlappingTemplate
1 0 0 1 0 1 1 0 0 1 ---- 5/5 NonOverlappingTemplate
0 1 0 1 1 0 1 1 0 0 ---- 5/5 NonOverlappingTemplate
0 0 0 0 1 1 1 1 0 1 ---- 5/5 NonOverlappingTemplate
0 0 0 0 1 0 1 2 1 0 ---- 5/5 NonOverlappingTemplate
1 0 1 0 0 0 0 2 0 1 ---- 5/5 NonOverlappingTemplate
0 0 1 0 0 1 0 2 1 0 ---- 5/5 NonOverlappingTemplate
1 0 0 0 1 1 0 0 0 2 ---- 5/5 NonOverlappingTemplate
0 0 1 2 0 0 1 0 0 1 ---- 5/5 NonOverlappingTemplate
1 0 1 0 1 0 0 0 2 0 ---- 5/5 NonOverlappingTemplate
1 0 0 2 0 0 1 0 1 0 ---- 5/5 NonOverlappingTemplate
1 0 0 0 0 0 1 1 2 0 ---- 5/5 NonOverlappingTemplate
1 2 0 1 0 0 0 0 1 0 ---- 5/5 NonOverlappingTemplate
0 0 1 0 1 0 1 0 0 2 ---- 5/5 NonOverlappingTemplate
1 1 0 1 0 0 1 0 1 0 ---- 5/5 NonOverlappingTemplate
0 0 0 1 1 1 1 0 1 0 ---- 5/5 NonOverlappingTemplate
0 0 1 1 1 0 0 0 1 1 ---- 5/5 NonOverlappingTemplate
1 1 0 1 0 0 1 0 1 0 ---- 5/5 NonOverlappingTemplate
1 1 1 1 0 0 0 1 0 0 ---- 5/5 NonOverlappingTemplate
1 1 0 0 1 0 0 0 1 1 ---- 5/5 NonOverlappingTemplate
1 0 0 2 0 0 1 0 0 1 ---- 5/5 NonOverlappingTemplate
0 1 2 1 0 0 0 0 0 1 ---- 5/5 NonOverlappingTemplate
0 0 0 2 0 0 2 1 0 0 ---- 5/5 NonOverlappingTemplate
2 0 0 0 0 1 0 1 0 1 ---- 5/5 NonOverlappingTemplate
0 1 1 1 0 0 1 0 0 1 ---- 5/5 NonOverlappingTemplate
0 1 0 0 1 1 0 1 0 1 ---- 5/5 NonOverlappingTemplate
1 0 0 0 1 0 0 1 1 1 ---- 5/5 NonOverlappingTemplate
0 0 1 0 1 0 0 1 1 1 ---- 5/5 NonOverlappingTemplate
2 0 1 0 0 0 0 1 1 0 ---- 5/5 NonOverlappingTemplate
0 0 1 0 0 1 1 0 1 1 ---- 5/5 NonOverlappingTemplate
1 0 0 2 0 0 0 1 1 0 ---- 4/5 NonOverlappingTemplate
0 0 1 0 0 0 1 1 2 0 ---- 5/5 NonOverlappingTemplate
2 0 0 0 1 0 2 0 0 0 ---- 5/5 NonOverlappingTemplate
1 0 1 0 1 0 1 0 0 1 ---- 5/5 NonOverlappingTemplate
1 1 0 0 1 0 0 0 0 2 ---- 5/5 NonOverlappingTemplate
0 1 1 1 0 1 1 0 0 0 ---- 5/5 NonOverlappingTemplate
1 0 0 2 0 1 0 0 0 1 ---- 5/5 NonOverlappingTemplate
1 0 1 0 1 0 0 0 0 2 ---- 4/5 NonOverlappingTemplate
0 0 0 0 0 2 2 1 0 0 ---- 5/5 NonOverlappingTemplate
1 1 2 0 0 0 0 0 1 0 ---- 5/5 NonOverlappingTemplate
1 2 1 0 0 0 0 0 0 1 ---- 5/5 NonOverlappingTemplate
0 0 0 1 0 3 0 1 0 0 ---- 5/5 NonOverlappingTemplate
0 1 0 0 0 1 1 0 2 0 ---- 5/5 NonOverlappingTemplate
0 0 2 2 0 0 0 0 1 0 ---- 5/5 NonOverlappingTemplate
0 0 0 1 1 1 0 1 0 1 ---- 5/5 NonOverlappingTemplate
0 0 1 1 0 1 0 0 0 2 ---- 5/5 NonOverlappingTemplate
1 0 0 2 0 0 0 1 1 0 ---- 5/5 NonOverlappingTemplate
0 0 0 2 1 1 0 0 0 1 ---- 5/5 NonOverlappingTemplate
0 0 1 2 0 0 0 1 1 0 ---- 5/5 NonOverlappingTemplate
1 1 1 0 0 0 0 0 0 2 ---- 4/5 NonOverlappingTemplate
0 1 0 0 0 0 2 0 2 0 ---- 5/5 NonOverlappingTemplate
0 0 1 0 0 1 0 1 1 1 ---- 5/5 NonOverlappingTemplate
0 0 0 0 0 1 1 1 1 1 ---- 5/5 OverlappingTemplate
1 1 0 0 1 2 0 0 0 0 ---- 4/5 Universal
2 1 0 0 1 0 0 0 0 1 ---- 4/5 ApproximateEntropy
0 1 0 0 1 0 0 0 0 0 ---- 2/2 RandomExcursions
0 1 1 0 0 0 0 0 0 0 ---- 2/2 RandomExcursions
0 1 1 0 0 0 0 0 0 0 ---- 2/2 RandomExcursions
0 2 0 0 0 0 0 0 0 0 ---- 2/2 RandomExcursions
1 0 0 1 0 0 0 0 0 0 ---- 2/2 RandomExcursions
0 0 0 0 1 0 0 0 0 1 ---- 2/2 RandomExcursions
1 0 0 1 0 0 0 0 0 0 ---- 2/2 RandomExcursions
0 0 0 0 0 2 0 0 0 0 ---- 2/2 RandomExcursions
0 1 0 0 0 1 0 0 0 0 ---- 2/2 RandomExcursionsVariant
0 0 1 1 0 0 0 0 0 0 ---- 2/2 RandomExcursionsVariant
0 1 1 0 0 0 0 0 0 0 ---- 2/2 RandomExcursionsVariant
0 2 0 0 0 0 0 0 0 0 ---- 2/2 RandomExcursionsVariant
0 1 1 0 0 0 0 0 0 0 ---- 2/2 RandomExcursionsVariant
1 0 0 0 0 1 0 0 0 0 ---- 2/2 RandomExcursionsVariant
1 0 0 0 1 0 0 0 0 0 ---- 2/2 RandomExcursionsVariant
1 1 0 0 0 0 0 0 0 0 ---- 2/2 RandomExcursionsVariant
1 0 1 0 0 0 0 0 0 0 ---- 2/2 RandomExcursionsVariant
0 0 0 0 0 1 0 0 0 1 ---- 2/2 RandomExcursionsVariant
1 0 0 0 1 0 0 0 0 0 ---- 2/2 RandomExcursionsVariant
1 0 0 0 0 0 0 1 0 0 ---- 2/2 RandomExcursionsVariant
0 1 0 0 0 0 0 0 0 1 ---- 2/2 RandomExcursionsVariant
0 1 0 0 0 0 0 0 0 1 ---- 2/2 RandomExcursionsVariant
1 0 0 0 0 0 0 0 1 0 ---- 2/2 RandomExcursionsVariant
1 0 0 0 0 0 0 0 1 0 ---- 2/2 RandomExcursionsVariant
0 0 1 0 0 0 0 1 0 0 ---- 2/2 RandomExcursionsVariant
0 0 1 0 0 0 0 1 0 0 ---- 2/2 RandomExcursionsVariant
0 1 1 0 1 1 1 0 0 0 ---- 5/5 Serial
0 0 1 0 1 1 1 0 0 1 ---- 5/5 Serial
0 2 0 1 0 0 1 1 0 0 ---- 5/5 LinearComplexity

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
The minimum pass rate for each statistical test with the exception of the
random excursion (variant) test is approximately = 4 for a
sample size = 5 binary sequences.

The minimum pass rate for the random excursion (variant) test
is approximately = 1 for a sample size = 2 binary sequences.

For further guidelines construct a probability table using the MAPLE program
provided in the addendum section of the documentation.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
________________________________________________________________________________

FILE = /usr/z.a.xz ALPHA = 0.0100
________________________________________________________________________________

BITSREAD = 500000 0s = 249976 1s = 250024
BITSREAD = 500000 0s = 250070 1s = 249930
BITSREAD = 500000 0s = 250408 1s = 249592
BITSREAD = 500000 0s = 249099 1s = 250901
BITSREAD = 500000 0s = 249665 1s = 250335

Bonita Montero

unread,
May 17, 2022, 7:31:41 AM5/17/22
to
>>>> Mathematischer Beweis bitte, keine Worte. Hrhr.
>>>
>>> Der Test mit der Test-Suite ist der Beweis.
>>
>> LOL, Du bist so dämlich. Alt-Ultra-Nerd.
>
> Selbstverständlich ist ein Lauf mit der NIST-Test-Suite das einzige
> frei verfügbare Beweismittel mit Referenz-Charakter.

Niemand führt einen mathematischen Beweis empirisch anhand eines
Programms durch. Das war auch ein Scherz von mir, dass Du darauf
eingehst zeigt echt, wie beschränkt Du bist.

>> Es hat sicher noch niemand bewiesen, dass komprimierte Daten
>> ein guter Zufalls-Generator wären. Ganz einfach weil das eine
>> komplett schwachsinnige Aussage ist.

> Es wurden hier schon vor langer Zeit Zusammenhänge entdeckt.
> Eine Zufallsdatei ist nicht/kaum komprimierbar.

Du hattest ursprünglich eine komplett andere Aussage gemacht.

>> Ne, es gibt zwischen den nicht-kryptografischen Zufallsgeneratoren
>> riesige Unterschiede. Ein LCG ist halt z.B. nix gegen einen Mersenne
>> Twister.

> http://www.schellong.de/htm/dragon.c.html#NIST

Was red ich hier eigentlich wenn Du immer an mir vorbeiredest.
Hast Du Demenz ?

...

Ole Jansen

unread,
May 17, 2022, 9:47:31 AM5/17/22
to
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?

O.J.

Helmut Schellong

unread,
May 17, 2022, 11:19:53 AM5/17/22
to
Das darf nicht nur angenommen werden, sondern das ist einfach definitiv so.
Zumindest beim besten Komprimieralgorithmus xz/lzma.

https://de.wikipedia.org/wiki/Datenkompression:
Aus diesen beiden Tatsachen ergibt sich die Schlussfolgerung, dass rein zufällige Daten
(höchstwahrscheinlich) unkomprimierbar sind (da sie zumeist keine Struktur aufweisen),
und dass zwar viele, aber nicht alle, Daten komprimiert werden können.
Zwei Preisgelder, 100 Dollar für die erfolgreiche Kompression von einer Million
zufälliger Ziffern[6][7] und 5000 Dollar für die erfolgreiche Kompression einer Datei
beliebiger Länge, die vom Preisstifter, Mike Goldman, erzeugt wird,
wurden bis heute nicht ausbezahlt.

Die NIST-Testsuite hat der Datei z.a.xz bescheinigt, das die Bitfolge ihres Inhalts
eine hohe kryptographische Zufallsqualität hat.
Eine Hauptforderung bei kryptographischen Algorithmen ist, daß deren
Ausgabe-Bitstrom von echtem Zufall nicht unterscheidbar sein darf.

Beweis per 100% passed:

Arno Welzel

unread,
May 17, 2022, 11:51:54 AM5/17/22
to
Helmut Schellong:

[...]
> Eine maximal stark komprimierte Datei hat zufälligen Inhalt.

Nein, eine maximal stark komprimierte Datei hat genau den Inhalt, den
die unkomprimierten Ausgangsdaten und der Komprimierungsalgorithmus
vorgegeben. Mit "zufällig" hat das exakt gar nichts zu tun.


--
Arno Welzel
https://arnowelzel.de

Arno Welzel

unread,
May 17, 2022, 11:52:46 AM5/17/22
to
Ole Jansen:
Nein, da das Ergebnis auf *nicht* zufälligen Daten basiert.

Arno Welzel

unread,
May 17, 2022, 11:53:34 AM5/17/22
to
Helmut Schellong:

> On 05/17/2022 15:47, Ole Jansen wrote:
>> 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?
>>
>>
>
> Das darf nicht nur angenommen werden, sondern das ist einfach definitiv so.
> Zumindest beim besten Komprimieralgorithmus xz/lzma.

Nein, ist es nicht. Auch wenn die komprimierte Version einer Datei
"zufällig" aussieht, basiert sie auf einer *nicht* zufälligen Quelle und
ist damit eben selbst genauso wenig zufällig, sondern deterministisch.

Bonita Montero

unread,
May 17, 2022, 12:13:03 PM5/17/22
to
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.

Sind hier nur Idioten ?

Bonita Montero

unread,
May 17, 2022, 12:13:52 PM5/17/22
to
Ein Gegenbeweis wäre die Kompression von Zufalls-Daten.
Die wär dann schon als Zufall nutzbar.

Helmut Schellong

unread,
May 17, 2022, 12:20:01 PM5/17/22
to
On 05/17/2022 17:51, Arno Welzel wrote:
> Helmut Schellong:
>
> [...]
>> Eine maximal stark komprimierte Datei hat zufälligen Inhalt.
>
> Nein, eine maximal stark komprimierte Datei hat genau den Inhalt, den
> die unkomprimierten Ausgangsdaten und der Komprimierungsalgorithmus
> vorgegeben. Mit "zufällig" hat das exakt gar nichts zu tun.
>
>

Du interpretierst kraß falsch und ignorierst den Kontext.

Eine maximal stark komprimierte Datei hat einen Inhalt, der
wie mit einem Zufallsgenerator erzeugt aussieht.

Ohne Grund hat die Testsuite einer komprimierten Datei nicht einen
hochqualitativen Inhalt zuerkannt, wie von einem kryptographischen
Zufallsgenerator erzeugt.

Helmut Schellong

unread,
May 17, 2022, 12:28:49 PM5/17/22
to
Es basiert aber doch auf zufälligen Daten.
Ein guter Komprimierer entfernt alle redundanten und strukturierten Daten,
so daß quasi nur Zufallsdaten übrig bleiben.
Es verbleibt ein Rest, an dem keinerlei Abfolgeregel erkennbar ist.

Helmut Schellong

unread,
May 17, 2022, 12:35:04 PM5/17/22
to
Du ignorierst schon wieder den Kontext!
Das scheint Deine Methode zu sein, Leuten (vermeintlich) Unrecht geben zu können.
Der Kontext sind Pseudozufallsgeneratoren.
Steht auch im Titel des Threads (Dragon,Rabbit,Spritz sind PRNG=deterministisch).

Helmut Schellong

unread,
May 17, 2022, 12:37:28 PM5/17/22
to
Du bist nicht ernstzunehmen.

Helmut Schellong

unread,
May 17, 2022, 12:42:12 PM5/17/22
to
On 05/17/2022 18:13, Bonita Montero wrote:
Vollkommener Quatsch.
PRNG arbeiten grundsätzlich nicht mit Zufall, sondern deren Ausgabe sieht
innerhalb einer Maximallänge nur zufällig generiert aus!
Der Zufall kann durch den Key da hineinkommen, der die Sequenz bestimmt.

Bonita Montero

unread,
May 18, 2022, 12:56:51 AM5/18/22
to
Kannst Du mal beim Thema bleiben ?
Ich habe von Zufalls-Daten gesprochen und nicht, wie diese
entstanden sind.

Bonita Montero

unread,
May 18, 2022, 12:57:47 AM5/18/22
to
Am 17.05.2022 um 18:38 schrieb Helmut Schellong:
> On 05/17/2022 18:13, Bonita Montero wrote:
>> 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.
>>
>> Sind hier nur Idioten ?
>
> Du bist nicht ernstzunehmen.

Äh, dein Textverständnis bewegt sich auf dem Niveau eines Grundschülers,
und das ziemlich durchgängig. Wer ist hier wohl nicht ernstzunehmen ?

Ole Jansen

unread,
May 18, 2022, 12:59:42 AM5/18/22
to
Am 17.05.22 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:
>>>>>> 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?
>>>>>
>>>>>
>>>>
>>>> Das darf nicht nur angenommen werden, sondern das ist einfach
>>>> definitiv so.
>>>> Zumindest beim besten Komprimieralgorithmus xz/lzma.
>>>
>>> Nein, ist es nicht. Auch wenn die komprimierte Version einer Datei
>>> "zufällig" aussieht, basiert sie auf einer *nicht* zufälligen Quelle und
>>> ist damit eben selbst genauso wenig zufällig, sondern deterministisch.

Deterministisch sind mathematische Generatoren die mit einer
random seed starten auch. Als Laie würde ich erwarten dass
sich solche Reihen irgendwann wiederholen und dass die Länge
zwischen den Wiederholungen nicht größer sein kann als die
Anzahl der Zustände welche die Rechenmaschine annehmen kann?

>> Ein Gegenbeweis wäre die Kompression von Zufalls-Daten.

Daten z.B. aus radioaktiven Zerfällen lassen sich mit lz
durchaus komprimieren. Beispielsweise wenn die Daten zufällig
sind aber die Werte ungleichmäßig verteilt.

Ich nehme einmal an dass solche Daten nicht mit "echten"
Zufallsdaten gemeint sind. Die Entwickler mathematischer
Algoritmen versuchen doch gerade solche Schwächen zu vermeiden
indem z.B. bits und bytes möglichst nicht nachvollziehbar
verwürfelt werden oder nichtlineare Funktionen verwendet
werden?

>> Die wär dann schon als Zufall nutzbar.

> Vollkommener Quatsch.
> PRNG arbeiten grundsätzlich nicht mit Zufall, sondern deren Ausgabe sieht
> innerhalb einer Maximallänge nur zufällig generiert aus!

"Sieht aus" meint also dass es keine identifizierbaren Muster
gibt welche sich durch Regressionsanalyse ermitteln lassen
(selbst wenn der Algoritmus bekannt ist) und dass der einzige
bekannte Weg zum Ermitteln der seed brute force wäre?

> Der Zufall kann durch den Key da hineinkommen, der die Sequenz bestimmt.

Die Unmöglichkeit einer Regressionsanalyse formal logisch
zu beweisen dürfte nicht gehen.
Kennt sich hier zufällig jemand mit Fredkin Gates oder
Reversible Computing aus?

O.J.


Thomas Koenig

unread,
May 18, 2022, 1:46:13 AM5/18/22
to
Ole Jansen <remove.this.k...@gmx.de> schrieb:
Das ist korrekt. Die Periodenlänge ist kann allerdings sehr lang
sein - die vom Mersenne Twister ist z.B. typischerweise 2^19937 - 1,
also eine Zalhl mit 6002 Stellen. Die Zahl ist so groß, die ist schon
nicht mal mehr astronomisch :-)

Ole Jansen

unread,
May 18, 2022, 2:40:39 AM5/18/22
to
Am 18.05.22 um 07:46 schrieb Thomas Koenig:
Umgekehrt bedeutet es dass eine Maschine zum Ausführen dieses
Algoritmus lediglich ca. 2.5 kbyte an möglichen Zuständen hätte?

O.J.

Helmut Schellong

unread,
May 18, 2022, 6:12:11 AM5/18/22
to
On 05/18/2022 06:59, Ole Jansen wrote:
> Am 17.05.22 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:
>>>>>>> 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?
>>>>>>
>>>>>>
>>>>>
>>>>> Das darf nicht nur angenommen werden, sondern das ist einfach definitiv so.
>>>>> Zumindest beim besten Komprimieralgorithmus xz/lzma.
>>>>
>>>> Nein, ist es nicht. Auch wenn die komprimierte Version einer Datei
>>>> "zufällig" aussieht, basiert sie auf einer *nicht* zufälligen Quelle und
>>>> ist damit eben selbst genauso wenig zufällig, sondern deterministisch.
>
> Deterministisch sind mathematische Generatoren die mit einer
> random seed starten auch. Als Laie würde ich erwarten dass
> sich solche Reihen irgendwann wiederholen und dass die Länge
> zwischen den Wiederholungen nicht größer sein kann als die
> Anzahl der Zustände welche die Rechenmaschine annehmen kann?

Deine vorstehende Antwort und auch die folgende erfolgen übrigens nicht
auf einen Text von mir!

Kryptographische Generatoren wiederholen ihre Sequenzen _nicht_!
Sie verlieren nach einer Länge von z.B. 2^68 Byte etwas von ihrer Qualität.
So daß professionelle Angriffserfolge wahrscheinlicher werden.

Der kryptographische 'Spritz' erhält ebenso einen Seed.
Ein Key ist quasi ein Seed.
Zu 'Spritz' las ich, daß der nach 2^81 Byte/Bit immer noch eine
gute Qualität hatte.

>>> Ein Gegenbeweis wäre die Kompression von Zufalls-Daten.
>
> Daten z.B. aus radioaktiven Zerfällen lassen sich mit lz
> durchaus komprimieren. Beispielsweise wenn die Daten zufällig
> sind aber die Werte ungleichmäßig verteilt.
>
> Ich nehme einmal an dass solche Daten nicht mit "echten"
> Zufallsdaten gemeint sind. Die Entwickler mathematischer
> Algoritmen versuchen doch gerade solche Schwächen zu vermeiden
> indem z.B. bits und bytes möglichst nicht nachvollziehbar
> verwürfelt werden oder nichtlineare Funktionen verwendet
> werden?
>
>>> Die wär dann schon als Zufall nutzbar.
>
>> Vollkommener Quatsch.
>> PRNG arbeiten grundsätzlich nicht mit Zufall, sondern deren Ausgabe sieht
>> innerhalb einer Maximallänge nur zufällig generiert aus!
>
> "Sieht aus" meint also dass es keine identifizierbaren Muster
> gibt welche sich durch Regressionsanalyse ermitteln lassen
> (selbst wenn der Algoritmus bekannt ist) und dass der einzige
> bekannte Weg zum Ermitteln der seed brute force wäre?

Ja, die Bitströme von Dragon, Rabbit, Spritz wurden von der NIST-Testsuite
untersucht und erhielten das Prädikat 'Rein zufällig'.

http://www.schellong.de/htm/dragon.c.html#NIST

'Dragon, Rabbit, Spritz, rand, random, zaxz' sind dort dokumentiert.

Eine Haupteigenschaft eines kryptographischen Algorithmus' muß sein, daß
seine Ausgabe nicht von einer echt zufälligen Ausgabe unterscheidbar sein darf.
Das ist eine zwingende Definition!

FILE = /usr/zospritz ALPHA = 0.0100
BITSREAD = 10000000 0s = 4998530 1s = 5001470
BITSREAD = 10000000 0s = 4997893 1s = 5002107
BITSREAD = 10000000 0s = 5001453 1s = 4998547
BITSREAD = 10000000 0s = 4999579 1s = 5000421
BITSREAD = 10000000 0s = 4999914 1s = 5000086

FILE = /usr/zorandom ALPHA = 0.0100
BITSREAD = 10000000 0s = 5017875 1s = 4982125
BITSREAD = 10000000 0s = 5017875 1s = 4982125
BITSREAD = 10000000 0s = 5017875 1s = 4982125
BITSREAD = 10000000 0s = 5017875 1s = 4982125
BITSREAD = 10000000 0s = 5017875 1s = 4982125

"Nachtigall, ick hör dir trapsen."
Kann ich angesichts der vorstehenden Daten nur sagen.

Helmut Schellong

unread,
May 18, 2022, 6:43:23 AM5/18/22
to
Das kann auch so gesehen werden.

Wie gesagt, haben _kryptographische_ Zufallszahlengeneratoren (PRNG)
_keine_ Periodizität.

Helmut Schellong

unread,
May 18, 2022, 7:07:53 AM5/18/22
to
Nachfolgend ein automatischer Seed für 'Spritz'.
Es ist das Objekt 'seed' zu beachten.

Der Inhalt von 'seed'+'w' kann auch als 'Key' angesehen werden.

Zuerst wird der 'Seed' in die S-Box injiziert.
Dann folgen 1024 Durchläufe, um den 'Seed' zu verwischen;
der 'Seed' darf in der Ausgabe nicht erkennbar sein.

------------------------------------------------------
http://www.schellong.de/htm/bishmnk.htm

struct { pid_t pid; time_t tim; byte buf[256]; } seed;

seed.pid= getpid();
seed.tim= time(NULL);
if (b!=3) i-=w;
w= wv[seed.tim % sizeof(wv)];

for (a=0; a<256; ++a) {
i= i+w;
j= k+s[j+s[i]&255];
k= i+k+s[j] + ((byte*)&seed)[a];
t= s[i], s[i]=s[j], s[j]=t;
z= s[j+s[i+s[z+k&255]&255]&255];
}
for (j=i,a=0; a<1024; ++a) {
i= i+w;
j= k+s[j+s[i]&255];
k= i+k+s[j];
t= s[i], s[i]=s[j], s[j]=t;
z= s[j+s[i+s[z+k&255]&255]&255];
}
cnt=1600000; f=b; continue;

Bonita Montero

unread,
May 18, 2022, 7:32:56 AM5/18/22
to
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.

Arno Welzel

unread,
May 18, 2022, 7:45:27 AM5/18/22
to
Helmut Schellong:

> On 05/17/2022 17:51, Arno Welzel wrote:
>> Helmut Schellong:
>>
>> [...]
>>> Eine maximal stark komprimierte Datei hat zufälligen Inhalt.
>>
>> Nein, eine maximal stark komprimierte Datei hat genau den Inhalt, den
>> die unkomprimierten Ausgangsdaten und der Komprimierungsalgorithmus
>> vorgegeben. Mit "zufällig" hat das exakt gar nichts zu tun.
>>
>>
>
> Du interpretierst kraß falsch und ignorierst den Kontext.

Nein, ich interpretiere es genau so, wie es gesagt wurde:

"Eine maximal stark komprimierte Datei hat zufälligen Inhalt."

> Eine maximal stark komprimierte Datei hat einen Inhalt, der
> wie mit einem Zufallsgenerator erzeugt aussieht.

Ja - er sieht vieleicht so aus. Deswegen *ist* er aber nicht zufällig,
sondern deterministisch abhängig vom Ausgangsmaterial, was für die
Komprimierung verwendet wurde.

> Ohne Grund hat die Testsuite einer komprimierten Datei nicht einen
> hochqualitativen Inhalt zuerkannt, wie von einem kryptographischen
> Zufallsgenerator erzeugt.

Die Testsuite untersucht halt nur das Ergebnis und nicht den Weg, wie
das Ergebnis zustande gekommen ist.

Wenn man den Weg zum Ergebnis egal ist, dann können wir uns
Zufallsgeneratoren auch ganz sparen und nehmen einfach eine Google-Suche
nach irgendeinem Begriff aus einer Liste von z.B. 1000 Suchbegriffen als
Vorlage und komprimieren das von Google per HTTPS gesendete Ergebnis als
Datei.

Arno Welzel

unread,
May 18, 2022, 7:46:54 AM5/18/22
to
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:
>>>>>> 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?
>>>>>
>>>>>
>>>>
>>>> Das darf nicht nur angenommen werden, sondern das ist einfach definitiv so.
>>>> Zumindest beim besten Komprimieralgorithmus xz/lzma.
>>>
>>> Nein, ist es nicht. Auch wenn die komprimierte Version einer Datei
>>> "zufällig" aussieht, basiert sie auf einer *nicht* zufälligen Quelle und
>>> ist damit eben selbst genauso wenig zufällig, sondern deterministisch.
>>
>> Ein Gegenbeweis wäre die Kompression von Zufalls-Daten.
>> Die wär dann schon als Zufall nutzbar.
>>
>
> Vollkommener Quatsch.
> PRNG arbeiten grundsätzlich nicht mit Zufall, sondern deren Ausgabe sieht
> innerhalb einer Maximallänge nur zufällig generiert aus!
> Der Zufall kann durch den Key da hineinkommen, der die Sequenz bestimmt.

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.

Helmut Schellong

unread,
May 18, 2022, 7:49:58 AM5/18/22
to
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.
>> PRNG arbeiten grundsätzlich nicht mit Zufall, sondern deren Ausgabe sieht
>> innerhalb einer Maximallänge nur zufällig generiert aus!
>> Der Zufall kann durch den Key da hineinkommen, der die Sequenz bestimmt.
>
> 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.

Es muß zwischen 'Echtem Zufall' und 'Pseudo-Zufall' unterschieden werden!
Echter Zufall ist nicht rein durch Software realisierbar.

"Statistical Test Suite For Random And Pseudorandom Number Generators"
. ^^^

Arno Welzel

unread,
May 18, 2022, 8:03:15 AM5/18/22
to
Ole Jansen:

> Am 17.05.22 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:
[...]
>>>>> Das darf nicht nur angenommen werden, sondern das ist einfach
>>>>> definitiv so.
>>>>> Zumindest beim besten Komprimieralgorithmus xz/lzma.
>>>>
>>>> Nein, ist es nicht. Auch wenn die komprimierte Version einer Datei
>>>> "zufällig" aussieht, basiert sie auf einer *nicht* zufälligen Quelle und
>>>> ist damit eben selbst genauso wenig zufällig, sondern deterministisch.
>
> Deterministisch sind mathematische Generatoren die mit einer
> random seed starten auch. Als Laie würde ich erwarten dass
> sich solche Reihen irgendwann wiederholen und dass die Länge
> zwischen den Wiederholungen nicht größer sein kann als die
> Anzahl der Zustände welche die Rechenmaschine annehmen kann?

Ist ja auch so. Irgendwann wiederholt sich die Reihe.

Genau deswegen sind solche Generatoren eben *kein* echter Zufall,
sondern nur "pseudo-zufällig". Es wirkt nur so, als wäre es zufällig,
weil man auf den ersten Blick nicht gleich erkennt, wann sich die
Zahlenreihe wieder vorne anfängt.

>>> Ein Gegenbeweis wäre die Kompression von Zufalls-Daten.
>
> Daten z.B. aus radioaktiven Zerfällen lassen sich mit lz
> durchaus komprimieren. Beispielsweise wenn die Daten zufällig
> sind aber die Werte ungleichmäßig verteilt.

lz selbst erzeugt dennoch keinen Zufall, sondern der Zufall kommt nur
von der Quelle, die lz als Basis nutzt.

> Ich nehme einmal an dass solche Daten nicht mit "echten"
> Zufallsdaten gemeint sind. Die Entwickler mathematischer
> Algoritmen versuchen doch gerade solche Schwächen zu vermeiden
> indem z.B. bits und bytes möglichst nicht nachvollziehbar
> verwürfelt werden oder nichtlineare Funktionen verwendet
> werden?

Genauer:

Bei kryptografischen Verfahren geht es darum, die Berechnung so
aufwendig zu machen, dass es nicht sinnvoll ist, alle möglichen
Schlüssel einfach durchzuprobieren, um den Klartext zu erhalten.

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 und der Schlüsselraum 2^4096 Kombinationen umfasst, braucht man
2^4096/100 Sekunden, um alle Schlüssel zu prüfen bzw. ungefähr 10^1224
Jahre. Selbst wenn man die Leistung für die Entschlüsselung um den
Faktor 10^6 steigern kann, ist die nötige Dauer immer noch viel zu lang,
um einen realistischen Angriff durchführen zu können.

>> Vollkommener Quatsch.
>> PRNG arbeiten grundsätzlich nicht mit Zufall, sondern deren Ausgabe sieht
>> innerhalb einer Maximallänge nur zufällig generiert aus!
>
> "Sieht aus" meint also dass es keine identifizierbaren Muster
> gibt welche sich durch Regressionsanalyse ermitteln lassen
> (selbst wenn der Algoritmus bekannt ist) und dass der einzige
> bekannte Weg zum Ermitteln der seed brute force wäre?

Falsch, es gibt solche Muster und die kann man durchaus ermitteln.

>> Der Zufall kann durch den Key da hineinkommen, der die Sequenz bestimmt.
>
> Die Unmöglichkeit einer Regressionsanalyse formal logisch
> zu beweisen dürfte nicht gehen.
> Kennt sich hier zufällig jemand mit Fredkin Gates oder
> Reversible Computing aus?

Was willst Du damit genau sagen?

*Verschlüsselte* Daten sind umkehrbar in den Klartext.

Ein *Hash* wie SHA1 dagegen nicht - es gibt nur potentiell mehrere
mögliche Quelldaten, die zum gleichen Ergebnis führen, weshalb man bei
Hash-Verfahren darum bemüht ist, dass kleinste Änderungen an der Quelle
zu einer möglichst großen Änderung um Ergebnis führt, auch wenn
Kollisionen schon deshalb nicht vermeidbar sind, weil ein Hash-Wert u.U.
kürzer ist, als die Daten, die ihm zugrunde liegen.

Beispiel für SHA1 - obwohl nur ein Buchstabe geändert wird, sieht das
berechnete Ergebnis komplett anders aus:

Testwert - 594313dd86e35061865f282a35659a940d68cdf5
Testwirt - 9c1f17b654aaaa2326f7aa39ee231d0f0cf35287

Bonita Montero

unread,
May 18, 2022, 8:03:47 AM5/18/22
to
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.
>>> PRNG arbeiten grundsätzlich nicht mit Zufall, sondern deren Ausgabe
>>> sieht
>>> innerhalb einer Maximallänge nur zufällig generiert aus!
>>> Der Zufall kann durch den Key da hineinkommen, der die Sequenz bestimmt.
>>
>> 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.

Es gibt keinen echten Zufall, sondern nur ggf. nicht mit weltlichen
Mittel nachvollziehbaren. Und der Key kann gar nicht erheblich sein
für die Nachvollziehbarkeit, zumindest theoretisch.

> Es muß zwischen 'Echtem Zufall' und 'Pseudo-Zufall' unterschieden werden!

Es ist zumindest kein echter Zufall, dass Du komplett blöd bist.

Arno Welzel

unread,
May 18, 2022, 8:09:41 AM5/18/22
to
Helmut Schellong:

> On 05/17/2022 17:53, Arno Welzel wrote:
>> Helmut Schellong:
>>
>>> On 05/17/2022 15:47, Ole Jansen wrote:
>>>> 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?
>>>
>>> Das darf nicht nur angenommen werden, sondern das ist einfach definitiv so.
>>> Zumindest beim besten Komprimieralgorithmus xz/lzma.
>>
>> Nein, ist es nicht. Auch wenn die komprimierte Version einer Datei
>> "zufällig" aussieht, basiert sie auf einer *nicht* zufälligen Quelle und
>> ist damit eben selbst genauso wenig zufällig, sondern deterministisch.
>
> Du ignorierst schon wieder den Kontext!
> Das scheint Deine Methode zu sein, Leuten (vermeintlich) Unrecht geben zu können.
> Der Kontext sind Pseudozufallsgeneratoren.

Die keinen Zufall erzeugen - deswegen heißen Sie ja
"Pseudozufallsgeneratoren".

> Steht auch im Titel des Threads (Dragon,Rabbit,Spritz sind PRNG=deterministisch).

Und damit eben nicht mehr "Zufall". Genausowenig wie eine komprimierte
Datei.

Ob der Dateiinhalt statistisch betrachtet "zufällig" *aussieht* ändert
daran nichts, dass er eben *nicht* zufällig *ist*.

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.

Arno Welzel

unread,
May 18, 2022, 8:11:38 AM5/18/22
to
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.

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

Arno Welzel

unread,
May 18, 2022, 8:12:59 AM5/18/22
to
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.

Arno Welzel

unread,
May 18, 2022, 8:16:13 AM5/18/22
to
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.

Helmut Schellong

unread,
May 18, 2022, 9:05:06 AM5/18/22
to
On 05/18/2022 13:45, Arno Welzel wrote:
> Helmut Schellong:
>
>> On 05/17/2022 17:51, Arno Welzel wrote:
>>> Helmut Schellong:
>>>
>>> [...]
>>>> Eine maximal stark komprimierte Datei hat zufälligen Inhalt.
>>>
>>> Nein, eine maximal stark komprimierte Datei hat genau den Inhalt, den
>>> die unkomprimierten Ausgangsdaten und der Komprimierungsalgorithmus
>>> vorgegeben. Mit "zufällig" hat das exakt gar nichts zu tun.
>>>
>>>
>>
>> Du interpretierst kraß falsch und ignorierst den Kontext.
>
> Nein, ich interpretiere es genau so, wie es gesagt wurde:
>
> "Eine maximal stark komprimierte Datei hat zufälligen Inhalt."
>

Im Kontext, den Du erneut ignorierst, wird gewöhnlich im Netz
so formuliert, wie ich formuliert habe!

Isoliert und streng betrachtet ist dies durchaus mißverständlich.
Ja - aber im Kontext betrachtet ist es _nicht mehr_ mißverständlich.
Du willst es jedoch nicht - korrekt - im Kontext betrachten!

>> Eine maximal stark komprimierte Datei hat einen Inhalt, der
>> wie mit einem Zufallsgenerator erzeugt aussieht.
>
> Ja - er sieht vieleicht so aus. Deswegen *ist* er aber nicht zufällig,
> sondern deterministisch abhängig vom Ausgangsmaterial, was für die
> Komprimierung verwendet wurde.

Ja, ich habe auch nichts anderes behauptet.

>> Ohne Grund hat die Testsuite einer komprimierten Datei nicht einen
>> hochqualitativen Inhalt zuerkannt, wie von einem kryptographischen
>> Zufallsgenerator erzeugt.
>
> 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...

> Wenn man den Weg zum Ergebnis egal ist, dann können wir uns
> Zufallsgeneratoren auch ganz sparen und nehmen einfach eine Google-Suche
> nach irgendeinem Begriff aus einer Liste von z.B. 1000 Suchbegriffen als
> Vorlage und komprimieren das von Google per HTTPS gesendete Ergebnis als
> Datei.
>

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?
Ich kann jederzeit einen Zufallsstrom per 'Spritz' ausgeben:
----------------------------------------------------------------
6H^E!nVe/Lrtg8Iyj_>T?K`#qSl[o:AhZ7~fFJa,*\w9]RB;X<DxbY5"WmNdk-iM
807L4-BzDAYjVQC_mviRgE%tZsr9Pe#[?$6"Tl@ny&3q^/\I(F1)Ha]>{JXK`xW,
ciI3N82KgA-kQqw"rGYs}C;ZopUtz{u_MLO7*)VP04H!vBe>TX+]\/?%ED^F(Rhd
4y>nMEGRk}0tZJw<PlY%i~)X8`T;+/6L#p3@9u&mV!Ngej*O_$A|5Kx7I:WCr]DS
1Z[KY&O$H3G9}j?Xte%R#pWw~g{>*0.I5^nB8:DLmvE;@_FduUfzCi+,!bJTQ/s]
804A2|ouB7vh@F;+9wYnmEO%"g1M3r#C\i/HpSx_[l{-Ij$NX?`!:Pf]dW^.)Z~K
U~/FG"?x#)eDCl.gHnj-+S`ocp3MA$dB}XW;{r:ia0!qK2mh4vw6Y>&7@u^bJQR8
H93\lPqRKD}.(nfC5Q/4N-8b#[a_~m)U"o1r:6dF`wj;><X+TEz*^%OevAh&Gs7?
2]_q%PnV-,Xmh;"@<|+T/(t!elv0Kc{*i)?1w}E4AQSMuybFs&UdIOJ`ZRj:^[8~
HZQ*g5R|L@C3/rp:^P0sU]1+(E_}vOJB~#72><oIcVSqT\;a$FADX,ky9zbfW68l
,QsDWTe<8KR507";Gl2]@qIu?z3+f6v4LbX`ABtimJN|cgMp%(o)*V/Z#Sh:a!H-
!ku]5fHKD@N$)dQ9><W4iO"\JEAgPjl2I+8&L~C3T6_S?r#Yem^vz{o*c;R:nyZU
UW3A@,kFp|zZ]N:1iBI!&("Y<LDer5n/$*~4C#aE?0dbP8%Sc_xl2f69vqGOus-j
@oWwXiE]z3D~+0IMmp$4d;7JVY}-#N!l[h/SA96OU1xgPQ{rveLuFT<2_,5Zc|HK
@U$2wW]tE4TX)7bx>A3/S."\%lV5kM9-&vZHi|6c:81`o*[KmqOr{N}asnu;f_~y
Bc5uw@-Uij"&_g\JMs,h?dK*L2AeI(f{EGCQ7qlD<r0|N8zav$k39Fo%+HP}~;m[
----------------------------------------------------------------

Die Qualität ist besser als bei random(), aber doch ziemlich schlecht.
Warum, ist klar, nämlich, weil der Zeichenbereich stark gefiltert ist.
Für Paßwörter ist das aber geeignet: |N8zav$k39Fo%+HP}

Helmut Schellong

unread,
May 18, 2022, 9:07:53 AM5/18/22
to
On 05/18/2022 13:46, Arno Welzel wrote:
> Helmut Schellong:
>
>> On 05/17/2022 18:13, Bonita Montero wrote:
>>> Am 17.05.2022 um 17:53 schrieb Arno Welzel:
>>>> Helmut Schellong:
[...]
>> Vollkommener Quatsch.
>> PRNG arbeiten grundsätzlich nicht mit Zufall, sondern deren Ausgabe sieht
>> innerhalb einer Maximallänge nur zufällig generiert aus!
>> Der Zufall kann durch den Key da hineinkommen, der die Sequenz bestimmt.
>
> 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.

Helmut Schellong

unread,
May 18, 2022, 9:29:14 AM5/18/22