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

Helmut Schellong

unread,

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

to

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().

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

to

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

[...]

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

Sie erzeugen eben doch Zufall - Pseudo-Zufall.
Die Ausgabe von Krypto-PRNG darf nicht von echtem Zufall unterscheidbar sein.
Folglich ist Pseudo-Zufall durch Krypto wirklich zufällig.

>> Steht auch im Titel des Threads (Dragon,Rabbit,Spritz sind PRNG=deterministisch).
>
> Und damit eben nicht mehr "Zufall". Genausowenig wie eine komprimierte
> Datei.

Doch, es ist Zufall; nur eben kein echter Zufall, sondern Pseudo-Zufall.

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

|Ein kryptographisch sicherer Zufallszahlengenerator (auch kryptographisch geeigneter
|Zufallszahlengenerator, bzw. englisch cryptographically secure pseudo-random number generator (CSPRNG))
|ist ein für die Kryptologie geeigneter Generator für Pseudozufallszahlen.
|Solche Zufallszahlen werden in vielen Bereichen der Kryptologie benötigt wie zum Beispiel bei:

Selbstverständlich sind Pseudo-Zufallszahlen auch Zufallszahlen.

|Zum einen darf die von ihm erzeugte Zahlenfolge nicht
|von einer echten Zufallszahlenfolge unterscheidbar sein.
|Zum anderen darf es nicht möglich sein, anhand der Ausgabe des Generators auf seinen
|internen Zustand zu schließen, auch wenn die genaue Funktionsweise bekannt ist.

Habe ich bereits vor vielen Wochen gepostet.
Verschwindet allerdings stets sogleich in den Sumpf der Vergessenheit.

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

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

Helmut Schellong

unread,

May 18, 2022, 9:43:07 AM5/18/22

to

On 05/18/2022 14:11, Arno Welzel wrote:
> Helmut Schellong:
>
>> On 05/17/2022 17:52, Arno Welzel wrote:
>>> Ole Jansen:
>>>
>>>> Am 17.05.22 um 03:40 schrieb Bonita Montero:
>>>>> Es hat sicher noch niemand bewiesen, dass komprimierte Daten
>>>>> ein guter Zufalls-Generator wären. Ganz einfach weil das eine
>>>>> komplett schwachsinnige Aussage ist.
>>>>
>>>> Je wirksamer ein Komprimierungsalgoritmus arbeitet um so eher vermeidet
>>>> dieser Redundanzen und Strukturen. Darf dann nicht wenigstens
>>>> angenommen werden dass komprimierte Daten ähnliche Eigenschasften
>>>> wie Zufallsdaten haben?
>>>
>>> Nein, da das Ergebnis auf *nicht* zufälligen Daten basiert.
>>>
>>>
>>
>> Es basiert aber doch auf zufälligen Daten.
>
> Ähm - nein.

Du widersprichst der Testsuite!

>> Ein guter Komprimierer entfernt alle redundanten und strukturierten Daten,
>> so daß quasi nur Zufallsdaten übrig bleiben.
>
> Nein, aus den Daten die übrig bleiben, lassen sich die Ausgangsdaten
> *exakt* wieder rekonstruieren.

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

>> Es verbleibt ein Rest, an dem keinerlei Abfolgeregel erkennbar ist.
>
> Aber sicher - wie sonst sollte der Komprimierer sonst daraus wieder das
> Original erzeugen können?
>
>

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

Helmut Schellong

unread,

May 18, 2022, 10:01:40 AM5/18/22

to

On 05/18/2022 14:12, Arno Welzel wrote:
> Helmut Schellong:
>
> [...]
>> Wie gesagt, haben _kryptographische_ Zufallszahlengeneratoren (PRNG)
>> _keine_ Periodizität.
>
> Dann sind es keine PRNG mehr. Denn genau deshalb nennt man die Dinger
> "pseudo", weil das Ergebnis eben *nicht* zufällig ist, auch wenn die
> Periode sehr lang sein kann.
>
>

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

|Grundsätzlich sind für einen CSPRNG dieselben Voraussetzungen
|wie für einen normalen Pseudozufallszahlengenerator vonnöten, nur dass
|für die Sicherheit noch einige zusätzliche Bedingungen erfüllt sein müssen.

|Zum einen darf die von ihm erzeugte Zahlenfolge nicht von einer
|echten Zufallszahlenfolge unterscheidbar sein.
|Zum anderen darf es nicht möglich sein, anhand der Ausgabe des Generators
|auf seinen internen Zustand zu schließen, auch wenn die genaue Funktionsweise bekannt ist.

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

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

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

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

Helmut Schellong

unread,

May 18, 2022, 10:10:58 AM5/18/22

to

Das wird nicht praktikabel sein.

Thomas Koenig

unread,

May 18, 2022, 10:25:24 AM5/18/22

to

Arno Welzel <use...@arnowelzel.de> schrieb:

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

In dem Kontext zwei Literaturstellen:

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

Axel Berger

unread,

May 18, 2022, 3:57:04 PM5/18/22

to

Arno Welzel wrote:
> Wenn etwa die EntschlÃ¼sselung mit einem Test-SchlÃ¼ssel mindestens 0,01

> Sekunden dauert, bis man feststellen kann, ob sie erfolgreich war oder
> nicht

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

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

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

Ole Jansen

unread,

May 19, 2022, 4:07:15 AM5/19/22

to

Am 18.05.22 um 16:02 schrieb Helmut Schellong:

> On 05/18/2022 14:12, Arno Welzel wrote:
>> Helmut Schellong:
>>
>> [...]
>>> Wie gesagt, haben _kryptographische_ Zufallszahlengeneratoren (PRNG)
>>> _keine_ Periodizität.
>>
>> Dann sind es keine PRNG mehr. Denn genau deshalb nennt man die Dinger
>> "pseudo", weil das Ergebnis eben *nicht* zufällig ist, auch wenn die
>> Periode sehr lang sein kann.
>>
>>
>
> Das ist eine falsche Aussage.
> Es ist oben 'kryptographische PRNG' ausgesagt worden.
> Nur für diese gilt die Nichtperiodizität, eben für 'CSPRNG'.

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

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

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

O.J.

Rolf Bombach

unread,

May 19, 2022, 5:10:35 AM5/19/22

to

Ole Jansen schrieb:

> Am 18.05.22 um 16:02 schrieb Helmut Schellong:
>> On 05/18/2022 14:12, Arno Welzel wrote:
>>> Helmut Schellong:
>>>
>>> [...]
>>>> Wie gesagt, haben _kryptographische_ Zufallszahlengeneratoren (PRNG)
>>>> _keine_ Periodizität.
>>>
>>> Dann sind es keine PRNG mehr. Denn genau deshalb nennt man die Dinger
>>> "pseudo", weil das Ergebnis eben *nicht* zufällig ist, auch wenn die
>>> Periode sehr lang sein kann.
>>>
>>>
>>
>> Das ist eine falsche Aussage.
>> Es ist oben 'kryptographische PRNG' ausgesagt worden.
>> Nur für diese gilt die Nichtperiodizität, eben für 'CSPRNG'.
>
> Wie sollen rein mathematische Zufallszahlengeneratoren
> ohne Periodizität denn funktionieren wenn die Zahl der
> Zustände der Maschine endlich ist?

Unendlich und abzählbar unendlich...

OK, ein suboptimales Beispiel:

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

Als Übungsbeispiel versuche man andere transzendente Konstanten oder Funktionen.

--
mfg Rolf Bombach

Rolf Bombach

unread,

May 19, 2022, 5:14:27 AM5/19/22

to

Axel Berger schrieb:

> Arno Welzel wrote:
>> Wenn etwa die EntschlÃ¼sselung mit einem Test-SchlÃ¼ssel mindestens 0,01
>> Sekunden dauert, bis man feststellen kann, ob sie erfolgreich war oder
>> nicht
>
> Es wird nie angesprochen, aber das zweite halte ich für das größere
> Problem. Schlüssel algorithmisch Durchiterieren ist einfach, aber wie
> erkenne ich den Erfolg? Je kürzer der Text, desto schwieriger wird das.
>
> Das Knacken von Enigma gelang nur, weil die Deutschen jede Sendung mit
> dem Wetterbericht begannen und der ausnahmslos mit denselben
> Eingangsworten anfing.

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

--
mfg Rolf Bombach

Rolf Bombach

unread,

May 19, 2022, 5:17:20 AM5/19/22

to

Arno Welzel schrieb:

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

--
mfg Rolf Bombach

Rolf Bombach

unread,

May 19, 2022, 5:25:42 AM5/19/22

to

Thomas Koenig schrieb:

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

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

--
mfg Rolf Bombach

Rolf Bombach

unread,

May 19, 2022, 5:29:15 AM5/19/22

to

Arno Welzel schrieb:

> Helmut Schellong:
>
>> On 05/17/2022 17:52, Arno Welzel wrote:
>>> Ole Jansen:
>>>
>>>> Am 17.05.22 um 03:40 schrieb Bonita Montero:
>>>>> Es hat sicher noch niemand bewiesen, dass komprimierte Daten
>>>>> ein guter Zufalls-Generator wären. Ganz einfach weil das eine
>>>>> komplett schwachsinnige Aussage ist.
>>>>
>>>> Je wirksamer ein Komprimierungsalgoritmus arbeitet um so eher vermeidet
>>>> dieser Redundanzen und Strukturen. Darf dann nicht wenigstens
>>>> angenommen werden dass komprimierte Daten ähnliche Eigenschasften
>>>> wie Zufallsdaten haben?
>>>
>>> Nein, da das Ergebnis auf *nicht* zufälligen Daten basiert.
>>>
>>>
>>
>> Es basiert aber doch auf zufälligen Daten.
>
> Ähm - nein.
>
>> Ein guter Komprimierer entfernt alle redundanten und strukturierten Daten,
>> so daß quasi nur Zufallsdaten übrig bleiben.
>
> Nein, aus den Daten die übrig bleiben, lassen sich die Ausgangsdaten
> *exakt* wieder rekonstruieren.

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

>
>> Es verbleibt ein Rest, an dem keinerlei Abfolgeregel erkennbar ist.
>
> Aber sicher - wie sonst sollte der Komprimierer sonst daraus wieder das
> Original erzeugen können?

?

--
mfg Rolf Bombach

Rolf Bombach

unread,

May 19, 2022, 5:31:55 AM5/19/22

to

Bonita Montero schrieb:

> Am 17.05.2022 um 15:47 schrieb Ole Jansen:
>> Am 17.05.22 um 03:40 schrieb Bonita Montero:
>>> Es hat sicher noch niemand bewiesen, dass komprimierte Daten
>>> ein guter Zufalls-Generator wären. Ganz einfach weil das eine
>>> komplett schwachsinnige Aussage ist.
>>
>> Je wirksamer ein Komprimierungsalgoritmus arbeitet um so eher vermeidet
>> dieser Redundanzen und Strukturen. Darf dann nicht wenigstens
>> angenommen werden dass komprimierte Daten ähnliche Eigenschasften
>> wie Zufallsdaten haben?
>

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

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

> Sind hier nur Idioten ?

Gewisse Statements sind manchmal reflexiv. Ausserdem plenkst du.

--
mfg Rolf Bombach

Helmut Schellong

unread,

May 19, 2022, 5:44:28 AM5/19/22

to

On 05/19/2022 10:07, Ole Jansen wrote:
> Am 18.05.22 um 16:02 schrieb Helmut Schellong:
>> On 05/18/2022 14:12, Arno Welzel wrote:
>>> Helmut Schellong:
>>>
>>> [...]
>>>> Wie gesagt, haben _kryptographische_ Zufallszahlengeneratoren (PRNG)
>>>> _keine_ Periodizität.
>>>
>>> Dann sind es keine PRNG mehr. Denn genau deshalb nennt man die Dinger
>>> "pseudo", weil das Ergebnis eben *nicht* zufällig ist, auch wenn die
>>> Periode sehr lang sein kann.
>>>
>>>
>>
>> Das ist eine falsche Aussage.
>> Es ist oben 'kryptographische PRNG' ausgesagt worden.
>> Nur für diese gilt die Nichtperiodizität, eben für 'CSPRNG'.
>
> Wie sollen rein mathematische Zufallszahlengeneratoren
> ohne Periodizität denn funktionieren wenn die Zahl der
> Zustände der Maschine endlich ist?

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

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

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

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

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

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

>> |Grundsätzlich sind für einen CSPRNG dieselben Voraussetzungen
>> |wie für einen normalen Pseudozufallszahlengenerator vonnöten, nur dass
>> |für die Sicherheit noch einige zusätzliche Bedingungen erfüllt sein müssen.
>> |Zum einen darf die von ihm erzeugte Zahlenfolge nicht von einer
>> |echten Zufallszahlenfolge unterscheidbar sein.
>> |Zum anderen darf es nicht möglich sein, anhand der Ausgabe des Generators
>> |auf seinen internen Zustand zu schließen, auch wenn die genaue Funktionsweise bekannt ist.
>
> Das ist praktisch so. Theoretisch geht es doch immer mit Brute Force?
>
>

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

Helmut Schellong

unread,

May 19, 2022, 6:17:35 AM5/19/22

to

Das wird 'One Time Pad' genannt.

Helmut Schellong

unread,

May 19, 2022, 6:22:41 AM5/19/22

to

(1+6)/2
Und bei Bytes lautet der Mittelwert 127,5 ([0+255]/2).

Helmut Schellong

unread,

May 19, 2022, 6:56:42 AM5/19/22

to

On 05/19/2022 11:31, Rolf Bombach wrote:
> Bonita Montero schrieb:
>> Am 17.05.2022 um 15:47 schrieb Ole Jansen:
>>> Am 17.05.22 um 03:40 schrieb Bonita Montero:
>>>> Es hat sicher noch niemand bewiesen, dass komprimierte Daten
>>>> ein guter Zufalls-Generator wären. Ganz einfach weil das eine
>>>> komplett schwachsinnige Aussage ist.
>>>
>>> Je wirksamer ein Komprimierungsalgoritmus arbeitet um so eher vermeidet
>>> dieser Redundanzen und Strukturen. Darf dann nicht wenigstens
>>> angenommen werden dass komprimierte Daten ähnliche Eigenschasften
>>> wie Zufallsdaten haben?
>>
>> Wie blöd ist das denn ?
>> Das ist sicher nicht der wissenschaftliche Beweis von Helmuts
>> Aussage, dass eine gepackte datei von der Datensequenz her wie
>> ein Zufallsgenerator streut.
>
> Das ist nicht ein Beweis, sondern eine plausible Erklärung.
> Den Beweis haben andere längst geliefert, das muss man ja nicht wiederholen.
>

So vor 15 Jahren habe ich schon mal was dazu gelesen.

Einen Beweis, daß genau die Datei 'z.a.xz' so streut wie ein guter CSPRNG
hat die Testsuite geliefert (zaxz).
Will nur eigentlich niemand wissen.

Bisher streuen alle mit xz komprimierten Dateien beinahe wie ein CSPRNG.
Jedenfalls beträchtlich besser als random().
Will augenscheinlich ebenso niemand wissen.

Bonita Montero

unread,

May 19, 2022, 7:09:05 AM5/19/22

to

Am 19.05.2022 um 12:57 schrieb Helmut Schellong:
> On 05/19/2022 11:31, Rolf Bombach wrote:
>> Bonita Montero schrieb:
>>> Am 17.05.2022 um 15:47 schrieb Ole Jansen:
>>>> Am 17.05.22 um 03:40 schrieb Bonita Montero:
>>>>> Es hat sicher noch niemand bewiesen, dass komprimierte Daten
>>>>> ein guter Zufalls-Generator wären. Ganz einfach weil das eine
>>>>> komplett schwachsinnige Aussage ist.
>>>>
>>>> Je wirksamer ein Komprimierungsalgoritmus arbeitet um so eher vermeidet
>>>> dieser Redundanzen und Strukturen. Darf dann nicht wenigstens
>>>> angenommen werden dass komprimierte Daten ähnliche Eigenschasften
>>>> wie Zufallsdaten haben?
>>>
>>> Wie blöd ist das denn ?
>>> Das ist sicher nicht der wissenschaftliche Beweis von Helmuts
>>> Aussage, dass eine gepackte datei von der Datensequenz her wie
>>> ein Zufallsgenerator streut.
>>
>> Das ist nicht ein Beweis, sondern eine plausible Erklärung.
>> Den Beweis haben andere längst geliefert, das muss man ja nicht
>> wiederholen.
>>
>
> So vor 15 Jahren habe ich schon mal was dazu gelesen.
>
> Einen Beweis, daß genau die Datei 'z.a.xz' so streut wie ein guter CSPRNG
> hat die Testsuite geliefert (zaxz).

Wie blöd ist das denn ?

Das ist kein qualitativer Beweis.

Helmut Schellong

unread,

May 19, 2022, 7:41:43 AM5/19/22

to

Doch.
Wenn Dir das nicht paßt, mußt Du die Bewertungsdaten der Testsuite widerlegen.
Du mußt dann nachweisen, daß die Daten aufgrund der Datei z.a.xz sich _nicht_
in die Daten der drei getesteten CSPRNG einfügen.

Kryptographen, die kryptographische Algorithmen entwickeln, benutzen solche
und andere Testsoftware, um ständig die Qualität ihrer Entwicklung zu messen.
Das ist so, als ob ein Elektronikentwickler sein Oszilloskop verwendet.

NIST - Statistical Test Suite For Random And Pseudorandom Number Generators

Du willst also gegen Vorstehendes anstinken!

Bonita Montero

unread,

May 19, 2022, 7:44:32 AM5/19/22

to

> Doch.

Nein, das soll empirisch sein.
Aber sowas kann man nicht epirisch beweisen.
Das ist Mathematik die jenseits deines Horizonts ist.

> Das ist so, als ob ein Elektronikentwickler sein Oszilloskop verwendet.

Du bist echt sowas von blöd.

Helmut Schellong

unread,

May 19, 2022, 8:11:19 AM5/19/22

to

Und Du hast absolut keine Ahnung davon, wie CSPRNG entwickelt werden.

Ole Jansen

unread,

May 19, 2022, 8:40:49 AM5/19/22

to

Am 18.05.22 um 21:58 schrieb Axel Berger:

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

Das ist jetzt stark verkürzt. Eine Schwachstelle der Enigma
war die fehlende Möglichkeit dass ein Buchstabe mit sich selbst
verschlüsselt werden konnte. Wenn also die Marine Telegramme
Worte wie "BISKAYAWETTER" oder "LEUCHTTONNEERLOSCHEN"
usw. enthielten konnte alle Positionen ausgeschlossen werden
wo mindestens ein Buchstabe mit dem Schlüsseltext gleich war.
Da haben dann auch die ganzen zusätzlichen Walzen nichts genützt.

Das und die schlechte Kryptodisziplin (schliesslich dachte
man ja es sei "unknackbar" ) haben den Aufwand für Brute Force
Angriffe so weit verringert dass dieser mit den damaligen Mitteln
(Touring-Bombe) möglich wurde. Erschwerend kam hinzu
dass die Deutschen ihre eigenen Schlüssel nie selber kritisch
evaluiert haben.

Das Gegenbeispiel dürfte die Reichsbahn gewesen sein. Deren
Schlüsselnetz verwendete ganz normale umgelötete
Dreiwalzenmaschinen. Weil aber die Transportmeldungen selbst
schon einigermaßen kryptisch waren konnte man die Telegramme
nicht auf diese Weise knacken weil sie keinen vorhersehbaren
Inhalt hatten. Sozusagen pseudeozufällig. So wie die Ankunfts
und Abfahrtszeiten bei der DB heute...

O.J.

Hanno Foest

unread,

May 19, 2022, 8:45:07 AM5/19/22

to

Am 19.05.22 um 13:42 schrieb Helmut Schellong:

>>> Einen Beweis, daß genau die Datei 'z.a.xz' so streut wie ein guter
>>> CSPRNG
>>> hat die Testsuite geliefert (zaxz).
>>
>> Wie blöd ist das denn ?
>> Das ist kein qualitativer Beweis.
>
> Doch.
> Wenn Dir das nicht paßt, mußt Du die Bewertungsdaten der Testsuite
> widerlegen.

Nein. Beweis heißt Verifikation, das ist was anderes als qualitative
Bewertung.

> NIST - Statistical Test Suite For Random And Pseudorandom Number Generator

Einfach mal lesen, was da steht:

"These tests may be useful as a *first step* in determining whether or
not a generator is suitable for a particular cryptographic application.
However, no set of statistical tests can absolutely certify a generator
as appropriate for usage in a particular application, i.e., statistical
testing cannot serve as a substitute for cryptanalysis."

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

Bonita Montero

unread,

May 19, 2022, 8:51:39 AM5/19/22

to

Am 19.05.2022 um 14:12 schrieb Helmut Schellong:
> On 05/19/2022 13:44, Bonita Montero wrote:
>>> Doch.
>>
>> Nein, das soll empirisch sein.
>> Aber sowas kann man nicht epirisch beweisen.
>> Das ist Mathematik die jenseits deines Horizonts ist.
>>
>>> Das ist so, als ob ein Elektronikentwickler sein Oszilloskop verwendet.
>>
>> Du bist echt sowas von blöd.
>
> Und Du hast absolut keine Ahnung davon, wie CSPRNG entwickelt werden.

Deren Sicherheit wird ganz sicher nicht empirisch bewiesen.

Bonita Montero

unread,

May 19, 2022, 8:52:33 AM5/19/22

to

Am 19.05.2022 um 14:45 schrieb Hanno Foest:
> Am 19.05.22 um 13:42 schrieb Helmut Schellong:
>
>>>> Einen Beweis, daß genau die Datei 'z.a.xz' so streut wie ein guter
>>>> CSPRNG
>>>> hat die Testsuite geliefert (zaxz).
>>>
>>> Wie blöd ist das denn ?
>>> Das ist kein qualitativer Beweis.
>>
>> Doch.
>> Wenn Dir das nicht paßt, mußt Du die Bewertungsdaten der Testsuite
>> widerlegen.
>
> Nein. Beweis heißt Verifikation, das ist was anderes als qualitative
> Bewertung.
>
>> NIST - Statistical Test Suite For Random And Pseudorandom Number
>> Generator
>
> Einfach mal lesen, was da steht:
>
> "These tests may be useful as a *first step* in determining whether or
> not a generator is suitable for a particular cryptographic application.
> However, no set of statistical tests can absolutely certify a generator
> as appropriate for usage in a particular application, i.e., statistical
> testing cannot serve as a substitute for cryptanalysis."

Ja, eben.
Und der Helmut will studiert haben.
Wo denn ? An der Baumschule ?

Helmut Schellong

unread,

May 19, 2022, 9:17:23 AM5/19/22

to

On 05/19/2022 14:45, Hanno Foest wrote:
> Am 19.05.22 um 13:42 schrieb Helmut Schellong:
>
>>>> Einen Beweis, daß genau die Datei 'z.a.xz' so streut wie ein guter CSPRNG
>>>> hat die Testsuite geliefert (zaxz).
>>>
>>> Wie blöd ist das denn ?
>>> Das ist kein qualitativer Beweis.
>>
>> Doch.
>> Wenn Dir das nicht paßt, mußt Du die Bewertungsdaten der Testsuite widerlegen.
>
> Nein. Beweis heißt Verifikation, das ist was anderes als qualitative Bewertung.

Es gibt auch Beweise anderer Art, nicht nur die mathematischen.
Habe ich bereits erklärt - wird offenbar nur nicht verstanden.

Wenn die Testsuite für drei CSPRNG Analysedaten erzeugt, und ein weiterer
Test Daten erzeugt, mit exakt gleicher Konfiguration, die vollkommen zu allen
Daten der CSPRNG passen, so ist das ein unerschütterlicher Beweis dafür, daß
der weitere Testkandidat die gleiche Qualität hat, wie die drei CSPRNG.

Das ist wie ein Vergleich von Kurvenzügen mit einem Oszilloskop.
Wenn Kurvenzüge zur Deckung gebracht werden können, mit z.B. nur 0,5% Abweichung,
ist die Signalqualität bewiesenermaßen gleich.

>> NIST - Statistical Test Suite For Random And Pseudorandom Number Generator
>
> Einfach mal lesen, was da steht:
>
> "These tests may be useful as a *first step* in determining whether or not a generator is suitable for a particular cryptographic application. However, no set of statistical tests can absolutely certify a generator as appropriate for usage in a particular application, i.e., statistical testing cannot serve as a substitute for cryptanalysis."
>
>

Habe ich schon vor Monaten gelesen.
Ist aber hier irrelevant.
Daß die Testsuite eine Krypto-Analyse nicht ersetzen kann ist ganz klar - aber irrelevant,
weil ich eine Krypto-Analyse gar nicht durch die Testsuite ersetzen will.
Die Testsuite erfüllt andere Aufgaben.

Helmut Schellong

unread,

May 19, 2022, 9:18:51 AM5/19/22

to

Auch empirisch.

Helmut Schellong

unread,

May 19, 2022, 9:21:41 AM5/19/22

to

Und Du begreifst hier nicht, was VERGLEICHSdaten sind.
Das ist eine ganz eigene Kategorie.

Bonita Montero

unread,

May 19, 2022, 9:25:11 AM5/19/22

to

Am 19.05.2022 um 15:19 schrieb Helmut Schellong:
> On 05/19/2022 14:51, Bonita Montero wrote:
>> Am 19.05.2022 um 14:12 schrieb Helmut Schellong:
>>> On 05/19/2022 13:44, Bonita Montero wrote:
>>>>> Doch.
>>>>
>>>> Nein, das soll empirisch sein.
>>>> Aber sowas kann man nicht epirisch beweisen.
>>>> Das ist Mathematik die jenseits deines Horizonts ist.
>>>>
>>>>> Das ist so, als ob ein Elektronikentwickler sein Oszilloskop
>>>>> verwendet.
>>>>
>>>> Du bist echt sowas von blöd.
>>>
>>> Und Du hast absolut keine Ahnung davon, wie CSPRNG entwickelt werden.
>>
>> Deren Sicherheit wird ganz sicher nicht empirisch bewiesen.
>>
>
> Auch empirisch.

Das ist nur bei untauglichen Zufallsgeneratoren möglich.
Depp.

Bonita Montero

unread,

May 19, 2022, 9:26:09 AM5/19/22

to

Eben, und nicht die, die Qualität des Zufallsgenerators zu beweisen.
Das ist empirisch nur bei trivialen Zufallsgeneratoren möglich.
Depp.

Hanno Foest

unread,

May 19, 2022, 9:43:38 AM5/19/22

to

Am 19.05.22 um 15:18 schrieb Helmut Schellong:

>> Nein. Beweis heißt Verifikation, das ist was anderes als qualitative
>> Bewertung.
>
> Es gibt auch Beweise anderer Art, nicht nur die mathematischen.

Wir sind hier nicht vor Gericht, und in Mathematik und Logik wird
verifiziert.

> Habe ich bereits erklärt - wird offenbar nur nicht verstanden.

Da gibt es nichts zu verstehen.

> Wenn die Testsuite für drei CSPRNG Analysedaten erzeugt, und ein weiterer
> Test Daten erzeugt, mit exakt gleicher Konfiguration, die vollkommen zu
> allen
> Daten der CSPRNG passen, so ist das ein unerschütterlicher Beweis dafür,
> daß
> der weitere Testkandidat die gleiche Qualität hat, wie die drei CSPRNG.

Allenfalls ist das ein Beweis für die Behauptung "a fool with a tool is
still a fool".

Bonita Montero

unread,

May 19, 2022, 9:49:05 AM5/19/22

to

Am 19.05.2022 um 15:43 schrieb Hanno Foest:
> Am 19.05.22 um 15:18 schrieb Helmut Schellong:
>
>>> Nein. Beweis heißt Verifikation, das ist was anderes als qualitative
>>> Bewertung.
>>
>> Es gibt auch Beweise anderer Art, nicht nur die mathematischen.
>
> Wir sind hier nicht vor Gericht, und in Mathematik und Logik wird
> verifiziert.

Nicht, dass ich die Fähigkeit hätte, alles andere als einen RNG
mathematisch zu beweisen. Aber Helmut ist ja wohl ein kompletter
Trottel.

Bonita Montero

unread,

May 19, 2022, 9:49:32 AM5/19/22

to

Am 19.05.2022 um 15:49 schrieb Bonita Montero:
> Am 19.05.2022 um 15:43 schrieb Hanno Foest:
>> Am 19.05.22 um 15:18 schrieb Helmut Schellong:
>>
>>>> Nein. Beweis heißt Verifikation, das ist was anderes als qualitative
>>>> Bewertung.
>>>
>>> Es gibt auch Beweise anderer Art, nicht nur die mathematischen.
>>
>> Wir sind hier nicht vor Gericht, und in Mathematik und Logik wird
>> verifiziert.
>
> Nicht, dass ich die Fähigkeit hätte, alles andere als einen RNG

trivialen ^

Helmut Schellong

unread,

May 19, 2022, 1:26:40 PM5/19/22

to

Schwachsinn.

Ein kleines Beispiel:

|The statistical tests on Rabbit were performed using the NIST Test Suite [17],
|the DIEHARD battery of tests [14] and the ENT test [22].
|Tests were performed on the internal state as well as on the extracted output.
|Furthermore, we also conducted various statistical tests on the key setup function.
|Finally, we performed the same tests on a version of Rabbit where each state variable
|and counter variable was reduced to 8 bit.
|No weaknesses were found in any of these cases.

|National Institute of Standards and Technology.
|A statistical test suite for the validation of random number generators
|and pseudo random number generators for cryptographic applications.
|NIST Special Publication 800-22, http://csrc.nist.gov/rng, 2001.

Helmut Schellong

unread,

May 19, 2022, 1:47:25 PM5/19/22

to

On 05/19/2022 15:43, Hanno Foest wrote:
> Am 19.05.22 um 15:18 schrieb Helmut Schellong:
>
>>> Nein. Beweis heißt Verifikation, das ist was anderes als qualitative Bewertung.
>>
>> Es gibt auch Beweise anderer Art, nicht nur die mathematischen.
>
> Wir sind hier nicht vor Gericht, und in Mathematik und Logik wird verifiziert.
>
>> Habe ich bereits erklärt - wird offenbar nur nicht verstanden.
>
> Da gibt es nichts zu verstehen.
>
>> Wenn die Testsuite für drei CSPRNG Analysedaten erzeugt, und ein weiterer
>> Test Daten erzeugt, mit exakt gleicher Konfiguration, die vollkommen zu allen
>> Daten der CSPRNG passen, so ist das ein unerschütterlicher Beweis dafür, daß
>> der weitere Testkandidat die gleiche Qualität hat, wie die drei CSPRNG.
>
> Allenfalls ist das ein Beweis für die Behauptung "a fool with a tool is still a fool".
>
>

Quatsch.
Die Testsuite mißt umfangreich und zuverlässig die Zufälligkeit eines Bitstroms.
Diese Zufälligkeit ist die Haupteigenschaft von CSPRNG.
Gleiche Daten bedeuten eine gleich gute Zufälligkeit.

Bonita Montero

unread,

May 19, 2022, 10:41:51 PM5/19/22

to

Du lernst echt nix dazu.

Helmut Schellong

unread,

May 20, 2022, 9:26:14 AM5/20/22

to

Ein Nullargument, mal wieder.
Weil: ein Nicht-Nullargument geht nicht.

Rolf Bombach

unread,

May 21, 2022, 5:02:57 PM5/21/22

to

Ole Jansen schrieb:

> Am 18.05.22 um 21:58 schrieb Axel Berger:
>> Das Knacken von Enigma gelang nur, weil die Deutschen jede Sendung mit
>> dem Wetterbericht begannen und der ausnahmslos mit denselben
>> Eingangsworten anfing.
>
> Das ist jetzt stark verkürzt. Eine Schwachstelle der Enigma
> war die fehlende Möglichkeit dass ein Buchstabe mit sich selbst
> verschlüsselt werden konnte. Wenn also die Marine Telegramme
> Worte wie "BISKAYAWETTER" oder "LEUCHTTONNEERLOSCHEN"
> usw. enthielten konnte alle Positionen ausgeschlossen werden
> wo mindestens ein Buchstabe mit dem Schlüsseltext gleich war.

Das war kein Bug, sondern ein Feature. Jemand mit mehr Streifen
am Hut meinte eben, so wäre es sicherer.

> Da haben dann auch die ganzen zusätzlichen Walzen nichts genützt.
>
> Das und die schlechte Kryptodisziplin (schliesslich dachte
> man ja es sei "unknackbar" ) haben den Aufwand für Brute Force
> Angriffe so weit verringert dass dieser mit den damaligen Mitteln
> (Touring-Bombe) möglich wurde. Erschwerend kam hinzu
> dass die Deutschen ihre eigenen Schlüssel nie selber kritisch
> evaluiert haben.

Die Mathematiker hatten durchaus gemeldet, dass die Enigma
geknackt werden könnte, und daher eine Walze mehr bräuchte.
Die Warnungen wurden in den Wind geschlagen.

--
mfg Rolf Bombach

Bonita Montero

unread,

May 21, 2022, 10:54:12 PM5/21/22

to

>> Du lernst echt nix dazu.

> Ein Nullargument, mal wieder.
> Weil: ein Nicht-Nullargument geht nicht.

Ich bin nicht die einzige die dir sagte, dass sich RNGs
nicht durchgängig empirisch beweisen lassen. Wenn Du einen
kryptografischen RNG ohne Periode hast sowieso nicht.

Helmut Schellong

unread,

May 22, 2022, 4:09:13 AM5/22/22

to

Ich habe mehrfach versucht, das Prinzip des Vergleiches zu erklären.

Wenn die Eigenschaften eines Objekts absolut festgestellt und anerkannt wurden,
kann dieses Objekt als Referenz-Objekt gelten.
Wenn nun ein anderes Objekt genau gleich mit der Referenz ist, können die
Eigenschaften der Referenz auf dieses weitere Objekt (als Kopie) übertragen werden.
Es ist eine zweite Referenz.
Genau gleiche Objekte können keine unterschiedlichen Eigenschaften haben!

Dieser Zustand liegt vor, bei der einen komprimierten Datei, die quasi deshalb
die Eigenschaften der bekannten, anerkannten Algorithmen Rabbit,Dragon,Spritz erbt.
Ohne sie genau so aufwendig untersuchen zu müssen.

Arno Welzel

unread,

May 23, 2022, 6:43:56 AM5/23/22

to

Helmut Schellong:

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

Die Aussage ist in jedem Kontext falsch. Eine komprimierte Datei ist
eben *nicht* mit zufälligem Inhalt, nur weil sie komprimiert ist! Ob
das, was man da findet, zufälliger Inhalt ist oder nicht hängt von den
Daten ab, die komprimiert wurden.

> Isoliert und streng betrachtet ist dies durchaus mißverständlich.

Auch auch nicht isoliert.

> Ja - aber im Kontext betrachtet ist es _nicht mehr_ mißverständlich.
> Du willst es jedoch nicht - korrekt - im Kontext betrachten!

Doch, genau das tue ich.

[...]
>> 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.

Doch, hast Du. Du hast behauptet, dass eine maximal stark komprimierte
Datei zufälligen Inhalt hat. Und diese Aussage ist so pauschal schlicht
falsch. Der Zufall hat mit der Komprimierung GAR NICHTS zu tun.

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

Und genau deswegen ist der Test auch sinnfrei.

--
Arno Welzel
https://arnowelzel.de

Arno Welzel

unread,

May 23, 2022, 6:48:18 AM5/23/22

to

Helmut Schellong:

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

Ähm - nein.

> Andernfalls könnte nicht entschlüsselt werden.

Aber sicher.

Arno Welzel

unread,

May 23, 2022, 6:51:54 AM5/23/22

to

Helmut Schellong:

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

>>> On 05/17/2022 17:52, Arno Welzel wrote:
>>>> Ole Jansen:
>>>>
>>>>> Am 17.05.22 um 03:40 schrieb Bonita Montero:
>>>>>> Es hat sicher noch niemand bewiesen, dass komprimierte Daten
>>>>>> ein guter Zufalls-Generator wären. Ganz einfach weil das eine
>>>>>> komplett schwachsinnige Aussage ist.
>>>>>
>>>>> Je wirksamer ein Komprimierungsalgoritmus arbeitet um so eher vermeidet
>>>>> dieser Redundanzen und Strukturen. Darf dann nicht wenigstens
>>>>> angenommen werden dass komprimierte Daten ähnliche Eigenschasften
>>>>> wie Zufallsdaten haben?
>>>>

>>>> Nein, da das Ergebnis auf *nicht* zufälligen Daten basiert.
>>>>
>>>>
>>>
>>> Es basiert aber doch auf zufälligen Daten.
>>
>> Ähm - nein.
>
> Du widersprichst der Testsuite!

Nein, ich widerspreche deiner Annahme, dass Zufall durch Komprimierung
entsteht.

>>> Ein guter Komprimierer entfernt alle redundanten und strukturierten Daten,
>>> so daß quasi nur Zufallsdaten übrig bleiben.
>>
>> Nein, aus den Daten die übrig bleiben, lassen sich die Ausgangsdaten
>> *exakt* wieder rekonstruieren.
>
> Ja, dennoch genügen diese Daten den hohen Ansprüchen an eine Krypto-Zufälligkeit.
> Bescheinigt durch die Testsuite.

Was nichts daran ändert, dass sie nicht zufällig *sind*, egal was eine
Testsuite dazu sagt.

Arno Welzel

unread,

May 23, 2022, 6:54:09 AM5/23/22

to

Rolf Bombach:

> Arno Welzel schrieb:
>> Helmut Schellong:
[...]

>>> Ein guter Komprimierer entfernt alle redundanten und strukturierten Daten,
>>> so daß quasi nur Zufallsdaten übrig bleiben.
>>
>> Nein, aus den Daten die übrig bleiben, lassen sich die Ausgangsdaten
>> *exakt* wieder rekonstruieren.
>

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

Die Aussage war, dass Daten komprimiert werden und DESWEGEN(!) aussehen,
wie zufällige Daten.

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

Wenn man eine Datei mit gzip komprimiert, ist das Ergebnis nicht wieder
dekomprimierbar, weil man ihr nicht mehr ansieht, dass sie mit gzip
komprimiert wurde? Glaube ich nicht.

Helmut Schellong

unread,

May 23, 2022, 7:11:19 AM5/23/22

to

On 05/23/2022 12:43, Arno Welzel wrote:
> Helmut Schellong:
>
[...]

>> Ja, ich habe auch nichts anderes behauptet.
>
> Doch, hast Du. Du hast behauptet, dass eine maximal stark komprimierte
> Datei zufälligen Inhalt hat. Und diese Aussage ist so pauschal schlicht
> falsch. Der Zufall hat mit der Komprimierung GAR NICHTS zu tun.

Doch, sehr viel.
Eine starke Komprimierung wie xz erzeugt eine Datei, deren Abfolge
der Bits den Ansprüchen an einen CSPRNG genügt.
Und zwar gilt das offenbar für 100% aller so komprimierten Dateien.

Im Kontext wird weltweit beispielsweise gesagt, daß eine bestimmte
Zeichenfolge/Bitfolge 'zufällig' sei.
Damit ist stets gemeint, daß die entsprechende Abfolge von Informationseinheiten
den Anforderungen für einen (CSP)RNG genügt.

>>> 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.
>
> Und genau deswegen ist der Test auch sinnfrei.
>
>

Falsch, der Test ist in 100% aller Anwendungen besonders sinnvoll.
Er wird weltweit benutzt, um Bitketten zu validieren, ob sie
den gestellten Anforderungen (an einen CSPRNG) entsprechen.
Der Test ist hierfür eine gültige Referenz.

Helmut Schellong

unread,

May 23, 2022, 7:15:39 AM5/23/22

to

On 05/23/2022 12:48, Arno Welzel wrote:
> Helmut Schellong:
>
>> 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.
>
> Ähm - nein.

Doch, das ist so.

>> Andernfalls könnte nicht entschlüsselt werden.
>
> Aber sicher.
>

Nein, es kann ohne Determinismus nicht entschlüsselt werden.

Du wirfst hier die seit vielen Jahrzehnten gültigen Grundlagen aus dem Fenster.

Helmut Schellong

unread,

May 23, 2022, 7:20:36 AM5/23/22

to

On 05/23/2022 12:51, Arno Welzel wrote:
> Helmut Schellong:
>
>> On 05/18/2022 14:11, Arno Welzel wrote:
>>> Helmut Schellong:
>>>
>>>> On 05/17/2022 17:52, Arno Welzel wrote:
>>>>> Ole Jansen:
>>>>>

[...]

>> Du widersprichst der Testsuite!
>
> Nein, ich widerspreche deiner Annahme, dass Zufall durch Komprimierung
> entsteht.

Das ist keine Annahme von mir, sondern das ist Fakt, bewiesen durch die Testsuite.

>>>> Ein guter Komprimierer entfernt alle redundanten und strukturierten Daten,
>>>> so daß quasi nur Zufallsdaten übrig bleiben.
>>>
>>> Nein, aus den Daten die übrig bleiben, lassen sich die Ausgangsdaten
>>> *exakt* wieder rekonstruieren.
>>
>> Ja, dennoch genügen diese Daten den hohen Ansprüchen an eine Krypto-Zufälligkeit.
>> Bescheinigt durch die Testsuite.
>
> Was nichts daran ändert, dass sie nicht zufällig *sind*, egal was eine
> Testsuite dazu sagt.
>
>

Eine solche Komprimierung hinterläßt Daten, die den Ansprüchen an einen CSPRNG genügen.
Bewiesen durch die Testsuite.

Arno Welzel

unread,

May 23, 2022, 8:44:49 AM5/23/22

to

Helmut Schellong:

> On 05/23/2022 12:43, Arno Welzel wrote:
>> Helmut Schellong:
>>
> [...]
>>> Ja, ich habe auch nichts anderes behauptet.
>>
>> Doch, hast Du. Du hast behauptet, dass eine maximal stark komprimierte
>> Datei zufälligen Inhalt hat. Und diese Aussage ist so pauschal schlicht
>> falsch. Der Zufall hat mit der Komprimierung GAR NICHTS zu tun.
>
> Doch, sehr viel.
> Eine starke Komprimierung wie xz erzeugt eine Datei, deren Abfolge
> der Bits den Ansprüchen an einen CSPRNG genügt.
> Und zwar gilt das offenbar für 100% aller so komprimierten Dateien.

Nein, das ist ein großes Mißverständnis. Nur weil die Bitfolgen einer
komprimierten Datei zufällig *aussehen*, sind sie dennoch nicht zufällig
auch nur in der Nähe davon.

> Im Kontext wird weltweit beispielsweise gesagt, daß eine bestimmte
> Zeichenfolge/Bitfolge 'zufällig' sei.
> Damit ist stets gemeint, daß die entsprechende Abfolge von Informationseinheiten
> den Anforderungen für einen (CSP)RNG genügt.

Dann scheinen die Anforderungen für einen (CSP)RNG aber sehr niedrig zu
sein, wenn jede deterministische Bitfolge dem genügt, solange sie nur
weitgehend auf Redundanzen verzichtet.

>>>> 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.
>>
>> Und genau deswegen ist der Test auch sinnfrei.
>>
>>
>
> Falsch, der Test ist in 100% aller Anwendungen besonders sinnvoll.
> Er wird weltweit benutzt, um Bitketten zu validieren, ob sie
> den gestellten Anforderungen (an einen CSPRNG) entsprechen.
> Der Test ist hierfür eine gültige Referenz.

Dumm nur, wenn die Bitketten ganz einfach zu reproduzieren sind und das
komplette Gegenteil von "Zufall" sind. Wenn man nämlich bestimmte
Ausgangsdaten komprimiert, kommt *immer* exakt die gleiche Bitfolge
dabei heraus. Und wenn der Test genau das nicht berücksichtigt, taugt er
nicht als Beurteilung, ob die so produzierten Daten den Anforderungen an
einen CSPRNG genügen.

Wie gesagt: Komprimierung macht aus nicht tauglichen Ausgangsdaten nicht
auf magische Weise taugliche Daten. Wenn dem so wäre, müsste man nicht
komprimieren, sondern nimmt einfach die unkomprimierten Quelldaten, die
ja exakt die selbe Information darstellen, nur in anderer Form.

Arno Welzel

unread,

May 23, 2022, 8:47:25 AM5/23/22

to

Helmut Schellong:

> On 05/23/2022 12:48, Arno Welzel wrote:
>> Helmut Schellong:
>>
>>> On 05/18/2022 13:46, Arno Welzel wrote:

[...]

>>>> Deswegen ist eine andere Bezeichnung für PRNG - pseudorandom number
>>>> generator - auch DBRG - deterministic random bit generator. Abhängig von
>>>> den Eingangsparametern kommt nämlich *immer* genau derselbe "Zufall" heraus.
>>>>
>>> Das ist für Verschlüsselung jedoch zwingend notwendig.
>>
>> Ähm - nein.
>
> Doch, das ist so.
>
>>> Andernfalls könnte nicht entschlüsselt werden.
>>
>> Aber sicher.
>>
>
> Nein, es kann ohne Determinismus nicht entschlüsselt werden.

Entschlüsseln tut man nicht mit Zufallszahlen, sondern mit einem
Schlüssel. Der ist selbstverständlich deterministisch. Dennoch ist zu
dessen Erzeugung keine deterministische Zahlenfolge nötig.

Arno Welzel

unread,

May 23, 2022, 8:52:02 AM5/23/22

to

Helmut Schellong:

> On 05/23/2022 12:51, Arno Welzel wrote:
>> Helmut Schellong:
>>
>>> On 05/18/2022 14:11, Arno Welzel wrote:
>>>> Helmut Schellong:
>>>>
>>>>> On 05/17/2022 17:52, Arno Welzel wrote:
>>>>>> Ole Jansen:
>>>>>>
> [...]
>>> Du widersprichst der Testsuite!
>>
>> Nein, ich widerspreche deiner Annahme, dass Zufall durch Komprimierung
>> entsteht.
>
> Das ist keine Annahme von mir, sondern das ist Fakt, bewiesen durch die Testsuite.

Seufz...

Kompriere bitte den String "Dieser Text ist kein Zufall" mit LZW.
Wiederhole das dann ein zweites Mal. Vergleiche, ob sich das zweite
Ergebnis vom ersten znterscheidet.

Wenn nicht - warum? Die komprimierte Version sollte doch zufällig sein
und nicht deterministisch.

[...]

> Eine solche Komprimierung hinterläßt Daten, die den Ansprüchen an einen CSPRNG genügen.
> Bewiesen durch die Testsuite.

So langsam ahne ich, wie Sicherheitslücken trotz vermeintlichem
Expertenwissen entstehen.

Bonita Montero

unread,

May 23, 2022, 2:07:02 PM5/23/22

to

Am 22.05.2022 um 10:10 schrieb Helmut Schellong:
> On 05/22/2022 04:54, Bonita Montero wrote:
>>>> Du lernst echt nix dazu.
>>
>>> Ein Nullargument, mal wieder.
>>> Weil: ein Nicht-Nullargument geht nicht.
>>
>>
>> Ich bin nicht die einzige die dir sagte, dass sich RNGs
>> nicht durchgängig empirisch beweisen lassen. Wenn Du einen
>> kryptografischen RNG ohne Periode hast sowieso nicht.
>
> Ich habe mehrfach versucht, das Prinzip des Vergleiches zu erklären.
>
> Wenn die Eigenschaften eines Objekts absolut festgestellt und anerkannt
> wurden,
> kann dieses Objekt als Referenz-Objekt gelten.
> Wenn nun ein anderes Objekt genau gleich mit der Referenz ist, können die
> Eigenschaften der Referenz auf dieses weitere Objekt (als Kopie)
> übertragen werden.

Darum ging es in der ganzen Diskussion nicht, sondern darum, dass man
die Qualität eines RNGN nicht empirisch anhand des Outputs beweisen
kann.
Und auch so wie Du es jetzt drehst klappt das nicht, denn eine Algo-
riehmus der 100 Jahre lang die selben Ergebnisse liefert ist eben
kein qualitativer Beweis für die Implementation.
Dass Du die ganze Diskussion bisher nicht verstanden hast, die darauf
basierte, dass Du dich obendrein ursprünglich noch unglücklich und
nicht unmissverständlich ausgedrückt hast, das wundert mich schon.

Helmut Schellong

unread,

May 23, 2022, 2:57:04 PM5/23/22

to

Du schreibst wirr.
Um die Erzeugung eines Schlüssels geht es gar nicht, sondern um die
Erzeugung eines entschlüsselten Keystreams.
Und der kann nur mittels eines deterministischen Generators erzeugt werden.

Helmut Schellong

unread,

May 23, 2022, 3:12:30 PM5/23/22

to

On 05/23/2022 14:52, Arno Welzel wrote:
> Helmut Schellong:
>
>> On 05/23/2022 12:51, Arno Welzel wrote:
>>> Helmut Schellong:
>>>
>>>> On 05/18/2022 14:11, Arno Welzel wrote:
>>>>> Helmut Schellong:
>>>>>
>>>>>> On 05/17/2022 17:52, Arno Welzel wrote:
>>>>>>> Ole Jansen:
>>>>>>>
>> [...]
>>>> Du widersprichst der Testsuite!
>>>
>>> Nein, ich widerspreche deiner Annahme, dass Zufall durch Komprimierung
>>> entsteht.
>>
>> Das ist keine Annahme von mir, sondern das ist Fakt, bewiesen durch die Testsuite.
>
> Seufz...
>
> Kompriere bitte den String "Dieser Text ist kein Zufall" mit LZW.
> Wiederhole das dann ein zweites Mal. Vergleiche, ob sich das zweite
> Ergebnis vom ersten znterscheidet.

Du schreibst wirr.
Es geht gar nicht um Determinismus dabei, sondern darum, daß ein
starker Komprimierer wie xz eine zufällige Bitfolge hinterläßt.

Ich habe doch bereits geschrieben, daß unter 'zufällig' im Kontext
die zufällige Abfolge der Bits der Bitkette gemeint ist.

> Wenn nicht - warum? Die komprimierte Version sollte doch zufällig sein
> und nicht deterministisch.
>
> [...]
>> Eine solche Komprimierung hinterläßt Daten, die den Ansprüchen an einen CSPRNG genügen.
>> Bewiesen durch die Testsuite.
>
> So langsam ahne ich, wie Sicherheitslücken trotz vermeintlichem
> Expertenwissen entstehen.
>
>

Vielleicht solltest Du irgendwann einmal die Beweise beachten!
Hatte ich doch bereits gepostet.

=======================================================================================================================
Die Kolmogorow-Komplexität (nach Andrei Nikolajewitsch Kolmogorow) ist ein Maß für die Strukturiertheit
einer Zeichenkette und ist durch die Länge des kürzesten Programms gegeben, das diese Zeichenkette erzeugt.
Dieses kürzeste Programm gibt somit eine beste Komprimierung der Zeichenkette an, ohne dass Information verloren geht.

Wenn die Kolmogorow-Komplexität einer Zeichenkette mindestens so groß ist wie die Zeichenkette selbst, dann
bezeichnet man die Zeichenkette als unkomprimierbar, zufällig oder auch strukturlos.
Je näher die Kolmogorow-Komplexität an der Länge der Zeichenkette liegt, desto 'zufälliger'
ist die Zeichenkette (und desto mehr Information enthält sie).

Die Kolmogorow-Komplexität wird manchmal auch Algorithmische Komplexität oder Beschreibungskomplexität
genannt, darf aber nicht mit der Zeit- oder Raumkomplexität von Algorithmen verwechselt werden.
Etwas präziser ist die Bezeichnung Algorithmischer Informationsgehalt, die auch die Verbindung
zu dem Begriff des Informationsgehalts nach Shannon herstellt.
=======================================================================================================================

Helmut Schellong

unread,

May 23, 2022, 3:17:34 PM5/23/22

to

On 05/23/2022 20:07, Bonita Montero wrote:
> Am 22.05.2022 um 10:10 schrieb Helmut Schellong:
>> On 05/22/2022 04:54, Bonita Montero wrote:
>>>>> Du lernst echt nix dazu.
>>>
>>>> Ein Nullargument, mal wieder.
>>>> Weil: ein Nicht-Nullargument geht nicht.
>>>
>>>
>>> Ich bin nicht die einzige die dir sagte, dass sich RNGs
>>> nicht durchgängig empirisch beweisen lassen. Wenn Du einen
>>> kryptografischen RNG ohne Periode hast sowieso nicht.
>>
>> Ich habe mehrfach versucht, das Prinzip des Vergleiches zu erklären.
>>
>> Wenn die Eigenschaften eines Objekts absolut festgestellt und anerkannt wurden,
>> kann dieses Objekt als Referenz-Objekt gelten.
>> Wenn nun ein anderes Objekt genau gleich mit der Referenz ist, können die
>> Eigenschaften der Referenz auf dieses weitere Objekt (als Kopie) übertragen werden.
>
> Darum ging es in der ganzen Diskussion nicht, sondern darum, dass man
> die Qualität eines RNGN nicht empirisch anhand des Outputs beweisen
> kann.

Doch.
Die Testsuite beweist bei jeder ihrer Anwendung, ob eine Bitkette
den Ansprüchen an Zufälligkeit genügt oder nicht.
Die Testsuite ist ein Validierungs-Werkzeug.

> Und auch so wie Du es jetzt drehst klappt das nicht, denn eine Algo-
> riehmus der 100 Jahre lang die selben Ergebnisse liefert ist eben
> kein qualitativer Beweis für die Implementation.

?

> Dass Du die ganze Diskussion bisher nicht verstanden hast, die darauf
> basierte, dass Du dich obendrein ursprünglich noch unglücklich und
> nicht unmissverständlich ausgedrückt hast, das wundert mich schon.

Auch Du schreibst hier wirr.
Es scheint zwecklos zu sein...

Rolf Bombach

unread,

May 23, 2022, 3:18:38 PM5/23/22

to

Helmut Schellong schrieb:
> On 05/19/2022 11:14, Rolf Bombach wrote:
>>
>> Wie Arno schon implizierte: Spätestens dann, wenn der Schlüssel länger
>> als der Text ist, kann man den Code nicht mehr knacken. Wenn du deine
>> Kreditkartennummer mit einem zwanzigstelligen Code verschlüsselst,
>> erfüllen beim Knacken ganz viele Resultate das Kriterium Kreditkartennummer.
>>
>
> Das wird 'One Time Pad' genannt.

Ja und nein. Ich meinte eine "normale" Verschlüsselung, für die gilt
das auch. One time pad erfordert sicheren Weg für den Schlüssel.

--
mfg Rolf Bombach

Helmut Schellong

unread,

May 23, 2022, 3:21:06 PM5/23/22

to

Ja, weshalb ein OneTimePad in der Praxis fast gar nicht angewandt wird.

Bernd Laengerich

unread,

May 23, 2022, 3:58:16 PM5/23/22

to

Am 23.05.2022 um 21:18 schrieb Rolf Bombach:

> Ja und nein. Ich meinte eine "normale" Verschlüsselung, für die gilt
> das auch. One time pad erfordert sicheren Weg für den Schlüssel.

Man braucht *immer* einen sicheren Weg für den Schlüssel bei symmetrischer
Verschlüsselung. Egal wie dieser beschaffen ist, z.B. über
Hilfstransportverschlüsselung mittels asymmetrischer Verfahren (dort muß dann
nicht der öffentliche Schlüssel sicher transportiert, aber beglaubigt
eingebracht werden) oder als shared secret eingebracht. One time pad ist
*sehr* häufig eingesetzt: Jede PIN-Kartenzahlung in DE mit on-line-PIN
arbeitet so (in CH, BE, NL sehr ähnlich, aber der verwendete symmetrische
Schlüssel wird dort anders abgeleitet). Der verwendete Schlüssel wird synchron
beidseitig von einem Terminalindividuellen Schlüssel abgeleitet. Der übliche
Weg ist die Einbringung der Masterschlüssel über 2 key custodians als 2
"Hälften" jeweils in die Key loading center der beteiligten Gerätehersteller
und in das HSM des Acquirers.

Bernd

Hanno Foest

unread,

May 23, 2022, 4:36:38 PM5/23/22

to

On 23.05.22 21:18, Helmut Schellong wrote:

> Doch.
> Die Testsuite beweist bei jeder ihrer Anwendung, ob eine Bitkette
> den Ansprüchen an Zufälligkeit genügt oder nicht.

Wenn die Testsuite irgendwas beweisen würde, wäre sie eine Beweis-Suite.
Der Corona-Test ist auch kein Beweis.

> Die Testsuite ist ein Validierungs-Werkzeug.

Eben gerade nicht. Ich hab dir schon in
<jemseg...@mid.individual.net> aus der Doku vorlesen müssen, daß das
Werkzeug nur ein "first step" auf dem Weg der Überprüfung eines
Zufallsgenerators ist, und gerade keine Cryptanalyse ersetzt. Wäre das
Resultat des Werkzeugs eine Validierung, könnte man sich alles weitere
sparen.

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

Bonita Montero

unread,

May 23, 2022, 9:37:28 PM5/23/22

to

> Doch.
> Die Testsuite beweist bei jeder ihrer Anwendung, ob eine Bitkette
> den Ansprüchen an Zufälligkeit genügt oder nicht.
> Die Testsuite ist ein Validierungs-Werkzeug.

Nein, die macht keine _qualitativen_ Aussagen.

>> Und auch so wie Du es jetzt drehst klappt das nicht, denn eine Algo-
>> riehmus der 100 Jahre lang die selben Ergebnisse liefert ist eben
>> kein qualitativer Beweis für die Implementation.

> ?

Ich sag ja: Du verstehst nicht was ich sage.
Du willst studiert haben ? Wo ? An der Baumschule ?

Helmut Schellong

unread,

May 24, 2022, 4:29:35 AM5/24/22

to

On 05/23/2022 22:36, Hanno Foest wrote:
> On 23.05.22 21:18, Helmut Schellong wrote:
>
>> Doch.
>> Die Testsuite beweist bei jeder ihrer Anwendung, ob eine Bitkette
>> den Ansprüchen an Zufälligkeit genügt oder nicht.
>
> Wenn die Testsuite irgendwas beweisen würde, wäre sie eine Beweis-Suite. Der Corona-Test ist auch kein Beweis.

Diese Argumentation ist falsch.
Tests beweisen fast immer etwas.
Messungen beweisen fast immer etwas.
Eine TÜV-Prüfung beweist, ob ein Auto VU ist oder nicht.
Messungen beweisen, ob eine lebensgefährliche Spannung da ist oder nicht.
Etc.

Die meisten Dinge lassen sich nicht mathematisch beweisen.
Folglich müssen sie auf andere Weise bewiesen werden.

>> Die Testsuite ist ein Validierungs-Werkzeug.
>
> Eben gerade nicht. Ich hab dir schon in <jemseg...@mid.individual.net> aus der Doku vorlesen müssen, daß das Werkzeug nur ein "first step" auf dem Weg der Überprüfung eines Zufallsgenerators ist, und gerade keine Cryptanalyse ersetzt. Wäre das Resultat des Werkzeugs eine Validierung, könnte man sich alles weitere sparen.
>
>

Hatte ich bereits gepostet:

|17. National Institute of Standards and Technology.

| A statistical test suite for the validation of random number generators
| and pseudo random number generators for cryptographic applications.
| NIST Special Publication 800-22, http://csrc.nist.gov/rng, 2001.

Und weiter:

|some recommended statistical tests are provided.
|These tests may be useful as a first step in determining whether or not a generator
|is suitable for a particular cryptographic application.
|However, no set of statistical tests can absolutely certify a generator as appropriate
|for usage in a particular application, i.e., statistical testing cannot serve
|as a substitute for cryptanalysis.
|The design and cryptanalysis of generators is outside the scope of this paper.

Du versuchst oben, per falscher Interpretation die Leser aufs Glatteis zu führen.
Ich selbst habe den Link auf die bezogene PDF gepostet.
Zuvor habe ich darin den 'Abstract' gelesen - und korrekt verstanden.

Die ≤15 statistischen Tests untersuchen _nur_ die Zufälligkeit
jeder beliebigen Bitfolge, die der Suite als Eingabe zugeführt wird.
Die Eigenschaften dieser Bitfolge werden validiert.

Viele weitere Eigenschaften eines Algorithmus' können _nicht_ untersucht werden.
Der ausgebende Algorithmus an sich wird _gar nicht_ untersucht!
Beispielsweise, wie breit ein Key ist oder ob ein Init-Vektor angegeben werden kann.

Helmut Schellong

unread,

May 24, 2022, 4:34:53 AM5/24/22

to

On 05/24/2022 03:37, Bonita Montero wrote:
>> Doch.
>> Die Testsuite beweist bei jeder ihrer Anwendung, ob eine Bitkette
>> den Ansprüchen an Zufälligkeit genügt oder nicht.
>> Die Testsuite ist ein Validierungs-Werkzeug.
>
> Nein, die macht keine _qualitativen_ Aussagen.

Hatte ich bereits mehrfach gepostet:

|17. National Institute of Standards and Technology.

| A statistical test suite for the validation of random number generators
| and pseudo random number generators for cryptographic applications.
| NIST Special Publication 800-22, http://csrc.nist.gov/rng, 2001.