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

Helmut Schellong:

On 05/26/2022 17:08, Arno Welzel wrote:
Ralph A. Schmid, dk5ras:

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

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



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

Wozu dann dein wiederholter Hinweis darauf, dass komprimierte Daten die
Anforderungen an zufälliger Verteilung ausreichend erfüllen?


--
Arno Welzel
https://arnowelzel.de
 
On 06/07/2022 11:15, Arno Welzel wrote:
Helmut Schellong:

[...]
Das ist aber üblich:
Paßwörter soll(t)en oft jedes halbe Jahr geändert werden.

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

Ich schrieb \'sollen/sollten\'.
Früher war es \'sollen\', heute \'sollten\' (in der Vergangenheit).

Ich hatte ab 1988 mit SCO Unix/386 gearbeitet.
Dort gab es eine \'SysAdmSh\' - SystemAdministrationsShell.
Darin waren 60 Tage Distanz (Default) für ein neues Paßwort eingetragen.
Allerdings für \'root\' galten alle solche Sachen nicht.

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

Ich habe niemals eine solche dämliche Änderung vorgenommen.
Wenn überhaupt - in seltenen Fällen, kreierte ich ein komplett neues Paßwort.
Länger und komplexer als das vorherige.

Mein Paßwort für Unix-Betriebssysteme ist seit 1988 in Benutzung.
Warum? Weil das niemand kennt und niemals kennen wird.
Ich wohnte und wohne stets allein in allen meinen Wohnungen.

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

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

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

Ja, aus guten Gründen.
Drei Jahre bei datei.pfx ist aber okay.
Die müssen auch mal technologische Verbesserungen anbringen können.


--
Mit freundlichen Grüßen
Helmut Schellong var@schellong.biz
http://www.schellong.de/c.htm http://www.schellong.de/c2x.htm http://www.schellong.de/c_padding_bits.htm
http://www.schellong.de/htm/bishmnk.htm http://www.schellong.de/htm/rpar.bish.html http://www.schellong.de/htm/sieger.bish.html
http://www.schellong.de/htm/audio_proj.htm http://www.schellong.de/htm/audio_unsinn.htm http://www.schellong.de/htm/tuner.htm
http://www.schellong.de/htm/string.htm http://www.schellong.de/htm/string.c.html http://www.schellong.de/htm/deutsche_bahn.htm
http://www.schellong.de/htm/schaltungen.htm http://www.schellong.de/htm/rand.htm http://www.schellong.de/htm/dragon.c.html
 
On 06/07/2022 11:16, Arno Welzel wrote:
Helmut Schellong:

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

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



Das ist irrelevant.
Executables können nicht random sein.

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


Diese Aussage ist falsch.

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

Für \'zufällig\' gibt es verschiedene Definitionen.
Du verwendest beharrlich die im Kontext falsche Definition.
Obwohl ich das mehrfach erklärte.

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

Nein, Eingrenzung auf \"nicht zufällige Ausgangsdaten\". Wenn man die
Ausgangsdaten kennt, weiß man auch, wie die komprimierten Daten dazu
aussehen. Die Zahl der Komprimierungsverfahren ist ebenfalls endlich.
Irrelevant!
Ich schrieb _mehrmals_, daß ich die ersten 1000 Bytes entfernte.
Dadurch ist ein Entpacken nahezu/praktisch unmöglich.
Man weiß ja gar nicht, ob überhaupt eine komprimierte Datei vorliegt!
Zumal die Bitfolge den Ansprüchen von CSPRNG genügt.


--
Mit freundlichen Grüßen
Helmut Schellong var@schellong.biz
http://www.schellong.de/c.htm http://www.schellong.de/c2x.htm http://www.schellong.de/c_padding_bits.htm
http://www.schellong.de/htm/bishmnk.htm http://www.schellong.de/htm/rpar.bish.html http://www.schellong.de/htm/sieger.bish.html
http://www.schellong.de/htm/audio_proj.htm http://www.schellong.de/htm/audio_unsinn.htm http://www.schellong.de/htm/tuner.htm
http://www.schellong.de/htm/string.htm http://www.schellong.de/htm/string.c.html http://www.schellong.de/htm/deutsche_bahn.htm
http://www.schellong.de/htm/schaltungen.htm http://www.schellong.de/htm/rand.htm http://www.schellong.de/htm/dragon.c.html
 
On 06/07/2022 11:18, Arno Welzel wrote:
Helmut Schellong:

On 05/26/2022 17:08, Arno Welzel wrote:
Ralph A. Schmid, dk5ras:

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

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



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

Wozu dann dein wiederholter Hinweis darauf, dass komprimierte Daten die
Anforderungen an zufälliger Verteilung ausreichend erfüllen?
Ich wußte aus den 1990ern, daß komprimierte Daten recht zufällig sind.
Nun entdeckte ich bei Tests, daß sie sogar die höchsten Ansprüche von CSPRNG erfüllen!
Und genau das teilte ich mit - nicht mehr.
Auch diese Mitteilung der Mitteilung wiederhole ich nun zum x-ten Male.


--
Mit freundlichen Grüßen
Helmut Schellong var@schellong.biz
http://www.schellong.de/c.htm http://www.schellong.de/c2x.htm http://www.schellong.de/c_padding_bits.htm
http://www.schellong.de/htm/bishmnk.htm http://www.schellong.de/htm/rpar.bish.html http://www.schellong.de/htm/sieger.bish.html
http://www.schellong.de/htm/audio_proj.htm http://www.schellong.de/htm/audio_unsinn.htm http://www.schellong.de/htm/tuner.htm
http://www.schellong.de/htm/string.htm http://www.schellong.de/htm/string.c.html http://www.schellong.de/htm/deutsche_bahn.htm
http://www.schellong.de/htm/schaltungen.htm http://www.schellong.de/htm/rand.htm http://www.schellong.de/htm/dragon.c.html
 
On 07.06.22 11:58, Helmut Schellong wrote:

> Mein Paßwort für Unix-Betriebssysteme ist seit 1988 in Benutzung.

Also 8 Zeichen crypt().

Warum? Weil das niemand kennt und niemals kennen wird.
Ich wohnte und wohne stets allein in allen meinen Wohnungen.

Ist jedenfalls aus dem passwd-String (gab es damals schon shadow?)
einfachst rekonstruierbar.

Hanno

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

[...]
Drei Jahre bei datei.pfx ist aber okay.
Die müssen auch mal technologische Verbesserungen anbringen können.

Ja, da handelt es sich ja auch um ein *Zertifikat* und nicht um ein
Passwort. Hier ist es sinnvoll, dies auch ab und zu zu erneuern.


--
Arno Welzel
https://arnowelzel.de
 
Helmut Schellong:

On 06/07/2022 11:18, Arno Welzel wrote:
Helmut Schellong:
[...]
Das wird in der Praxis aber nicht gemacht.
Man will keine Zufallsdaten aus komprimierten Daten gewinnen!
Das ist Nonsens.

Wozu dann dein wiederholter Hinweis darauf, dass komprimierte Daten die
Anforderungen an zufälliger Verteilung ausreichend erfüllen?


Ich wußte aus den 1990ern, daß komprimierte Daten recht zufällig sind.
Nun entdeckte ich bei Tests, daß sie sogar die höchsten Ansprüche von CSPRNG erfüllen!
Und genau das teilte ich mit - nicht mehr.
Auch diese Mitteilung der Mitteilung wiederhole ich nun zum x-ten Male.

Diese Mitteilung war aber komplett überflüssig, da mit diesen Daten
niemand etwas macht, egal wie zufällig sie aussehen mögen.


--
Arno Welzel
https://arnowelzel.de
 
On 06/07/2022 14:40, Arno Welzel wrote:
Helmut Schellong:

[...]
Drei Jahre bei datei.pfx ist aber okay.
Die müssen auch mal technologische Verbesserungen anbringen können.

Ja, da handelt es sich ja auch um ein *Zertifikat* und nicht um ein
Passwort. Hier ist es sinnvoll, dies auch ab und zu zu erneuern.
Ich habe drei solche Dateien, die haben je 10495 Byte.
Die neueste hat 13183 Byte...

Ein Paßwort muß ja dort eh eingegeben werden, nach Angabe der Datei.


--
Mit freundlichen Grüßen
Helmut Schellong var@schellong.biz
 
On 06/07/2022 14:41, Arno Welzel wrote:
Helmut Schellong:

On 06/07/2022 11:18, Arno Welzel wrote:
Helmut Schellong:
[...]
Das wird in der Praxis aber nicht gemacht.
Man will keine Zufallsdaten aus komprimierten Daten gewinnen!
Das ist Nonsens.

Wozu dann dein wiederholter Hinweis darauf, dass komprimierte Daten die
Anforderungen an zufälliger Verteilung ausreichend erfüllen?


Ich wußte aus den 1990ern, daß komprimierte Daten recht zufällig sind.
Nun entdeckte ich bei Tests, daß sie sogar die höchsten Ansprüche von CSPRNG erfüllen!
Und genau das teilte ich mit - nicht mehr.
Auch diese Mitteilung der Mitteilung wiederhole ich nun zum x-ten Male.

Diese Mitteilung war aber komplett überflüssig, da mit diesen Daten
niemand etwas macht, egal wie zufällig sie aussehen mögen.
Diese Daten sind Gegenstand von intensiver Forschung.
Nicht ohne Grund wurde die Zufälligkeit in den 1960ern bewiesen. ...


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

On 06/07/2022 14:41, Arno Welzel wrote:
Helmut Schellong:

On 06/07/2022 11:18, Arno Welzel wrote:
Helmut Schellong:
[...]
Das wird in der Praxis aber nicht gemacht.
Man will keine Zufallsdaten aus komprimierten Daten gewinnen!
Das ist Nonsens.

Wozu dann dein wiederholter Hinweis darauf, dass komprimierte Daten die
Anforderungen an zufälliger Verteilung ausreichend erfüllen?


Ich wußte aus den 1990ern, daß komprimierte Daten recht zufällig sind.
Nun entdeckte ich bei Tests, daß sie sogar die höchsten Ansprüche von CSPRNG erfüllen!
Und genau das teilte ich mit - nicht mehr.
Auch diese Mitteilung der Mitteilung wiederhole ich nun zum x-ten Male.

Diese Mitteilung war aber komplett überflüssig, da mit diesen Daten
niemand etwas macht, egal wie zufällig sie aussehen mögen.


Diese Daten sind Gegenstand von intensiver Forschung.
Nicht ohne Grund wurde die Zufälligkeit in den 1960ern bewiesen. ...

Mag sein, das ist dennoch für den Kontext \"Verwendung als Grundlage für
Verschlüsselung\" nicht relevant.


--
Arno Welzel
https://arnowelzel.de
 
Helmut Schellong:

On 06/07/2022 14:40, Arno Welzel wrote:
Helmut Schellong:

[...]
Drei Jahre bei datei.pfx ist aber okay.
Die müssen auch mal technologische Verbesserungen anbringen können.

Ja, da handelt es sich ja auch um ein *Zertifikat* und nicht um ein
Passwort. Hier ist es sinnvoll, dies auch ab und zu zu erneuern.


Ich habe drei solche Dateien, die haben je 10495 Byte.
Die neueste hat 13183 Byte...

Ein Paßwort muß ja dort eh eingegeben werden, nach Angabe der Datei.

Es handelt sich dennoch um ein Zertifikat.


--
Arno Welzel
https://arnowelzel.de
 
Hanno Foest schrieb:
Helmut Schellong wrote:

Mein Paßwort für Unix-Betriebssysteme ist seit 1988 in Benutzung.

Also 8 Zeichen crypt().

Warum? Weil das niemand kennt und niemals kennen wird.
Ich wohnte und wohne stets allein in allen meinen Wohnungen.

Ist jedenfalls aus dem passwd-String (gab es damals schon shadow?)
einfachst rekonstruierbar.

shadow wurde wohl erst irgendwann Anfang der 1990er Jahre als Option
eingeführt mit SCO UNIX System V 3.2 Version 4.0

Helmuts Passwort (so denn seine Behauptung zuträfe - so dumm ist doch
nichtmal er) wäre demnach trivial zu \"knacken\". Jeder konnte es auslesen

MfG
Rupert
 
On 06/07/2022 15:39, Arno Welzel wrote:
Helmut Schellong:

On 06/07/2022 14:41, Arno Welzel wrote:
Helmut Schellong:

On 06/07/2022 11:18, Arno Welzel wrote:
Helmut Schellong:
[...]
Das wird in der Praxis aber nicht gemacht.
Man will keine Zufallsdaten aus komprimierten Daten gewinnen!
Das ist Nonsens.

Wozu dann dein wiederholter Hinweis darauf, dass komprimierte Daten die
Anforderungen an zufälliger Verteilung ausreichend erfüllen?


Ich wußte aus den 1990ern, daß komprimierte Daten recht zufällig sind.
Nun entdeckte ich bei Tests, daß sie sogar die höchsten Ansprüche von CSPRNG erfüllen!
Und genau das teilte ich mit - nicht mehr.
Auch diese Mitteilung der Mitteilung wiederhole ich nun zum x-ten Male.

Diese Mitteilung war aber komplett überflüssig, da mit diesen Daten
niemand etwas macht, egal wie zufällig sie aussehen mögen.


Diese Daten sind Gegenstand von intensiver Forschung.
Nicht ohne Grund wurde die Zufälligkeit in den 1960ern bewiesen. ...

Mag sein, das ist dennoch für den Kontext \"Verwendung als Grundlage für
Verschlüsselung\" nicht relevant.
Doch, es ist eine erstaunliche Entdeckung, daß die Qualität genau so hoch ist,
wie bei den Bitstreams der drei CSPRNG (+ rand()+random()) im Vergleich.
Es geht um den Vergleich mit dedizierten CSPRNG.


--
Mit freundlichen Grüßen
Helmut Schellong var@schellong.biz
 
On 06/07/2022 15:39, Arno Welzel wrote:
Helmut Schellong:

On 06/07/2022 14:40, Arno Welzel wrote:
Helmut Schellong:

[...]
Drei Jahre bei datei.pfx ist aber okay.
Die müssen auch mal technologische Verbesserungen anbringen können.

Ja, da handelt es sich ja auch um ein *Zertifikat* und nicht um ein
Passwort. Hier ist es sinnvoll, dies auch ab und zu zu erneuern.


Ich habe drei solche Dateien, die haben je 10495 Byte.
Die neueste hat 13183 Byte...

Ein Paßwort muß ja dort eh eingegeben werden, nach Angabe der Datei.

Es handelt sich dennoch um ein Zertifikat.

Ja, dem habe ich nicht widersprochen.
Erst das Zertifikat, dann das Paßwort.


--
Mit freundlichen Grüßen
Helmut Schellong var@schellong.biz
http://www.schellong.de/c.htm http://www.schellong.de/c2x.htm http://www.schellong.de/c_padding_bits.htm
http://www.schellong.de/htm/bishmnk.htm http://www.schellong.de/htm/rpar.bish.html http://www.schellong.de/htm/sieger.bish.html
http://www.schellong.de/htm/audio_proj.htm http://www.schellong.de/htm/audio_unsinn.htm http://www.schellong.de/htm/tuner.htm
http://www.schellong.de/htm/string.htm http://www.schellong.de/htm/string.c.html http://www.schellong.de/htm/deutsche_bahn.htm
http://www.schellong.de/htm/schaltungen.htm http://www.schellong.de/htm/rand.htm http://www.schellong.de/htm/dragon.c.html
 
On 06/07/2022 17:12, Rupert Haselbeck wrote:
Hanno Foest schrieb:
Helmut Schellong wrote:

Mein Paßwort für Unix-Betriebssysteme ist seit 1988 in Benutzung.

Also 8 Zeichen crypt().

Warum? Weil das niemand kennt und niemals kennen wird.
Ich wohnte und wohne stets allein in allen meinen Wohnungen.

Ist jedenfalls aus dem passwd-String (gab es damals schon shadow?) einfachst rekonstruierbar.

shadow wurde wohl erst irgendwann Anfang der 1990er Jahre als Option eingeführt mit SCO UNIX System V 3.2 Version 4.0

Helmuts Passwort (so denn seine Behauptung zuträfe - so dumm ist doch nichtmal er) wäre demnach trivial zu \"knacken\". Jeder konnte es auslesen
Niemand konnte es auslesen, auch heute nicht, und auch nicht in Zukunft.
Wenn daran jemand zweifelt, dann soll er erzählen, wie man es bei mir ausliest.

Ich hatte bereits geschrieben, daß zu meinem PC in meiner Wohnung nur ich Zutritt habe.


--
Mit freundlichen Grüßen
Helmut Schellong var@schellong.biz
http://www.schellong.de/c.htm http://www.schellong.de/c2x.htm http://www.schellong.de/c_padding_bits.htm
http://www.schellong.de/htm/bishmnk.htm http://www.schellong.de/htm/rpar.bish.html http://www.schellong.de/htm/sieger.bish.html
http://www.schellong.de/htm/audio_proj.htm http://www.schellong.de/htm/audio_unsinn.htm http://www.schellong.de/htm/tuner.htm
http://www.schellong.de/htm/string.htm http://www.schellong.de/htm/string.c.html http://www.schellong.de/htm/deutsche_bahn.htm
http://www.schellong.de/htm/schaltungen.htm http://www.schellong.de/htm/rand.htm http://www.schellong.de/htm/dragon.c.html
 
Helmut Schellong <rip@schellong.biz> wrote:
On 06/07/2022 15:39, Arno Welzel wrote:
Helmut Schellong:

On 06/07/2022 14:40, Arno Welzel wrote:
Helmut Schellong:

[...]
Drei Jahre bei datei.pfx ist aber okay.
Die müssen auch mal technologische Verbesserungen anbringen können.

Ja, da handelt es sich ja auch um ein *Zertifikat* und nicht um ein
Passwort. Hier ist es sinnvoll, dies auch ab und zu zu erneuern.


Ich habe drei solche Dateien, die haben je 10495 Byte.
Die neueste hat 13183 Byte...

Ein Paßwort muß ja dort eh eingegeben werden, nach Angabe der Datei.

Es handelt sich dennoch um ein Zertifikat.

Ja, dem habe ich nicht widersprochen.
Erst das Zertifikat, dann das Paßwort.

Das Paßwort entschlüsselt den zum Zertifikat gehörenden privaten
Schlüssel.

--
-------------------------------------- !! No courtesy copies, please !! -----
Marc Haber | \" Questions are the | Mailadresse im Header
Mannheim, Germany | Beginning of Wisdom \" |
Nordisch by Nature | Lt. Worf, TNG \"Rightful Heir\" | Fon: *49 621 72739834
 
Helmut Schellong:

On 06/07/2022 17:12, Rupert Haselbeck wrote:
Hanno Foest schrieb:
Helmut Schellong wrote:

Mein Paßwort für Unix-Betriebssysteme ist seit 1988 in Benutzung.

Also 8 Zeichen crypt().

Warum? Weil das niemand kennt und niemals kennen wird.
Ich wohnte und wohne stets allein in allen meinen Wohnungen.

Ist jedenfalls aus dem passwd-String (gab es damals schon shadow?) einfachst rekonstruierbar.

shadow wurde wohl erst irgendwann Anfang der 1990er Jahre als Option eingeführt mit SCO UNIX System V 3.2 Version 4.0

Helmuts Passwort (so denn seine Behauptung zuträfe - so dumm ist doch nichtmal er) wäre demnach trivial zu \"knacken\". Jeder konnte es auslesen


Niemand konnte es auslesen, auch heute nicht, und auch nicht in Zukunft.
Wenn daran jemand zweifelt, dann soll er erzählen, wie man es bei mir ausliest.

Ich hatte bereits geschrieben, daß zu meinem PC in meiner Wohnung nur ich Zutritt habe.

Dann brauchst Du faktisch gar kein Passwort, es kommt ja niemand an den
PC heran.


--
Arno Welzel
https://arnowelzel.de
 
On 06/08/2022 21:29, Arno Welzel wrote:
Helmut Schellong:

On 06/07/2022 17:12, Rupert Haselbeck wrote:
Hanno Foest schrieb:
Helmut Schellong wrote:

Mein Paßwort für Unix-Betriebssysteme ist seit 1988 in Benutzung.

Also 8 Zeichen crypt().

Warum? Weil das niemand kennt und niemals kennen wird.
Ich wohnte und wohne stets allein in allen meinen Wohnungen.

Ist jedenfalls aus dem passwd-String (gab es damals schon shadow?) einfachst rekonstruierbar.

shadow wurde wohl erst irgendwann Anfang der 1990er Jahre als Option eingeführt mit SCO UNIX System V 3.2 Version 4.0

Helmuts Passwort (so denn seine Behauptung zuträfe - so dumm ist doch nichtmal er) wäre demnach trivial zu \"knacken\". Jeder konnte es auslesen


Niemand konnte es auslesen, auch heute nicht, und auch nicht in Zukunft.
Wenn daran jemand zweifelt, dann soll er erzählen, wie man es bei mir ausliest.

Ich hatte bereits geschrieben, daß zu meinem PC in meiner Wohnung nur ich Zutritt habe.

Dann brauchst Du faktisch gar kein Passwort, es kommt ja niemand an den
PC heran.
Das ist korrekt.
Aber nicht alle BS gestatten es, keines zu definieren.
Deshalb besteht mein Paßwort für meine BS auch nur aus 3 Kleinbuchstaben.
Es gibt hier immerhin 17576 verschiedene.

Ich kann jedoch im Prinzip irgendwann einmal eine körperliche Schwäche
bekommen, wenn ich gerade Besuch habe.
Deshalb doch ein Paßwort, wenn auch ein schwaches.

Zu behaupten, mein Paßwort konnte seit 1988 /von jedem ausgelesen werden/, ist
absurd und mit geistigem Schwachsinn gekoppelt.


--
Mit freundlichen Grüßen
Helmut Schellong var@schellong.biz
http://www.schellong.de/c.htm http://www.schellong.de/c2x.htm http://www.schellong.de/c_padding_bits.htm
http://www.schellong.de/htm/bishmnk.htm http://www.schellong.de/htm/rpar.bish.html http://www.schellong.de/htm/sieger.bish.html
http://www.schellong.de/htm/audio_proj.htm http://www.schellong.de/htm/audio_unsinn.htm http://www.schellong.de/htm/tuner.htm
http://www.schellong.de/htm/string.htm http://www.schellong.de/htm/string.c.html http://www.schellong.de/htm/deutsche_bahn.htm
http://www.schellong.de/htm/schaltungen.htm http://www.schellong.de/htm/rand.htm http://www.schellong.de/htm/dragon.c.html
 
Arno Welzel schrieb:
Holger Schieferdecker:

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

Dann könnte man die Ausgangsdaten also bildlich gesprochen als Seed für
den \"Zufallszahlengenerator\" betrachten?

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

Jein. Hier wird dezent[tm] aneinander vorbei geredet. Die informations-
theoretischen Infos hat Helmut schon angeführt.
Aus Sicht des Laien (obwohl ich mich gelegentlich kryptisch äussere, bin
ich kein Kryptologe oder Informatiker).

Kompression bedeutet Entfernen von redundanter Information. Also Entfernen
von Mustern und Strukturen, insbesondere repetitiven, insbesondere periodischen.
Dazu kommt auch die Entfernung aller Hinweise auf den verwendeten Algorithmus.

Man braucht nicht viel zu überlegen, um auf folgende Schlussfolgerungen
zu kommen.
- Maximal komprimiert sind die Daten, wenn sie nicht mehr von Zufallsdaten
zu unterscheiden sind.
https://de.wikipedia.org/wiki/Datenkompression#Verlustfreie_Kompression
- Jede Datei benötigt für die maximale Kompression ihren eigenen Algorithmus.
(Diese Schlussfolgerung schiesst die meisten \"Argumente\" ab.)
- Da man dem Empfänger den Algorithmus zum Dekoprimieren liefern muss, endet
das ganze beim one time pad.
- Das ganze ist _theoretisch_, und wie vieles in der Praxis nicht relevant.
- Annäherungen an maximale Kompression sind maximal riskant:
https://www.youtube.com/watch?v=7FeqF1-Z1g0
Meiner Meinung nach eine der grösseren Informatikkatastrophen und als
solche völlig unterbewertet.

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

Was ist \"statistisch verteilt\"?

Die Häufigkeit der Werte ist flach verteilt, ohne Häufung, ohne sparkle codes
und so weiter. Die zeitliche Entwicklung ist dabei egal.

--
mfg Rolf Bombach
 
Arno Welzel schrieb:
Nein, Eingrenzung auf \"nicht zufällige Ausgangsdaten\". Wenn man die
Ausgangsdaten kennt, weiß man auch, wie die komprimierten Daten dazu
aussehen. Die Zahl der Komprimierungsverfahren ist ebenfalls endlich.

Stöhn. Nein, die Zahl der Kompressionsverfahren ist definitionsgemäss
(abzählbar) unendlich. Allein schon deshalb, weil das Verfahren zur
maximalen Kompression für jeden Text anders ist. Daher kommt dann auch
die \"Zufälligkeit\" des Resultats. Ob dann die \"Ausgangsdaten\" \"zufällig\"
waren, spielt damit keine Rolle mehr.
Und nein, praxisrelevant ist das nicht, da hast du schon Recht.

--
mfg Rolf Bombach
 

Welcome to EDABoard.com

Sponsor

Back
Top