Ich habe mich gestern einmal gründlicher mit der Blockchiffre AES befaßt, weil
ich deren Implementierung starten wollte.

Als ich 2022 die Stromchiffren RABBIT und DRAGON implementierte, hatte ich bereits
die offizielle NIST-pdf zu AES.
Damals hatte ich mich gegen eine AES-Implementierung entschieden.
Dazu ist es auch gestern gekommen.

STROMCHIFFRE

Die Stromchiffren erzeugen kryptographisch einen zufälligen Datenstrom
mit einer Länge von z.B. 2^68 Byte _pro Schlüssel_.
Das ist etwa 295 Exa-Byte oder 10^(20,47)!
Es handelt sich um einen Zufallszahlengenerator.

Diese Zufallszahlen können XOR-verknüpft werden mit einer zu verschlüsselnden Datei:
.. datei = datei ^ random;
.. datei ist nun verschlüsselt.
.. datei = datei ^ random;
.. datei ist nun entschlüsselt.
Es kann zwischen verschlüsseltem und entschlüsseltem Zustand gewechselt werden, einfach
indem jeweils genau die gleiche Operation durchgeführt wird!

BLOCKCHIFFRE

Die Blockchiffre AES verschlüsselt in einem Lauf nur 16 Byte.
Die Daten aus 'datei' (16 Byte) werden ganz zu Anfang immer wieder neu zugeführt.
Ebenso, wie immer wieder ein (neuer) Schlüssel gegeben werden muß [1].

AES muß wegen Entschlüsselung quasi verdoppelt werden.
Zur Entschlüsselung arbeitet ein 'inverses AES'.
Es muß von fast allem eine inverse Funktion vorhanden sein, auch inverse Tabellen.
Auch für die Modi müssen inverse Versionen vorhanden sein (s.nachfolgend).

Ein großes Thema sind die Modi, die AES überhaupt erst fähig machen, um eine Datei
verschlüsseln zu können:
ECB, CBC, CFB, OFB, CTR, XTS, CCM, GCM, EAX, ...
Diese gehören nicht zum Algorithmus, sondern sind zusätzlicher gehöriger Aufwand!
Es gibt bessere und schlechtere Modi, manche sind 'viel besser', andere sind 'gefährlich'!

Es fällt sehr auf, daß AES /über den grünen Klee gelobt/ wird - auch die Performance!
Das wird wohl ungefähr berechtigt sein - allerdings nur im Vergleich mit den anderen Blockchiffren.
Stromchiffren sind Blockchiffren stark überlegen, hinsichtlich der Größe des Quellcodes
(z.B. 80 statt 500 Zeilen), der Verarbeitungsgeschwindigkeit über alles, der Ressourcenschonung
und der besseren Handhabung und Übersichtlichkeit.

Dem Netz kann entnommen werden, daß AES durch Optimierungen mehr als 30-fach beschleunigt
werden konnte. Dabei wurden die AES-intel-Instruktionen nicht erwähnt.
Es wurden u.a. viele statische Arrays angelegt, um dies zu erreichen.
Erwähnt wird, daß weitere 8 Arrays mit je 1024 Byte angelegt werden können.
Im Umkehrschluß ist erkennbar, daß ohne diese Optimierungen die Performance miserabel sein muß.
Solch eine Ressourcen-Ballerei ist bei Stromchiffren nicht anzutreffen.

Blockchiffren haben wohl prinzipielle Vorteile gegenüber den Stromchiffren.
Diese sind jedoch z.B. für mich völlig irrelevant, so daß fast nur Nachteile übrig bleiben.
Es ist jedenfalls günstiger, Stromchiffren zu verwenden, die mit Schlüsseln
hoher Entropie beschickt werden.
Beispielsweise kürzere Zeichenfolgen einem Hash-Kommando sha256 vorzulegen.

[1]
Es gibt die Überlegung, daß nicht immer der gleiche Schlüssel gegeben werden kann, weil
dann bei gleichen 16-Byte-Blöcken aus der zu verschlüsselnden Datei die verschlüsselte
Datei entsprechend gleiche Stücke enthielte!
Ich könnte einen Schlüssel durch addieren von Zahlen 1..255 jeweils zu einem neuen Schlüssel machen.

--
Mit freundlichen Grüßen
Helmut Schellong

On Sat, 11 May 2024 19:51:54 +0200, Helmut Schellong
<var@schellong.biz> wrote:

>Ich habe mich gestern einmal gründlicher mit der Blockchiffre AES befaßt, weil
>ich deren Implementierung starten wollte.
>
>Als ich 2022 die Stromchiffren RABBIT und DRAGON implementierte, hatte ich bereits
>die offizielle NIST-pdf zu AES.
>Damals hatte ich mich gegen eine AES-Implementierung entschieden.
>Dazu ist es auch gestern gekommen.
>
>STROMCHIFFRE
>
>Die Stromchiffren erzeugen kryptographisch einen zufälligen Datenstrom
>mit einer Länge von z.B. 2^68 Byte _pro Schlüssel_.
>Das ist etwa 295 Exa-Byte oder 10^(20,47)!
>Es handelt sich um einen Zufallszahlengenerator.
>
>Diese Zufallszahlen können XOR-verknüpft werden mit einer zu verschlüsselnden Datei:
>. datei = datei ^ random;
>. datei ist nun verschlüsselt.
>. datei = datei ^ random;
>. datei ist nun entschlüsselt.
>Es kann zwischen verschlüsseltem und entschlüsseltem Zustand gewechselt werden, einfach
>indem jeweils genau die gleiche Operation durchgeführt wird!
>.........

Wie hammse denn seinerzeit die Stromchiffren geknackt,
zum Beispiel den Datenstrom um 1 Zeichen versetzt mit sich selbst
gexort, weil dann die Doppelbuchstaben rausfallen,
zB Su-mm-e der Gu-mm-ibeste-ll-ungen
und das ist doch heute genauso machbar, oder?
Bin nicht vom Fach und habe keene Ahnung nicht.

w.

Helmut Schellong <var@schellong.biz> wrote:
>Ich habe mich gestern einmal gründlicher mit der Blockchiffre AES befaßt, weil
>ich deren Implementierung starten wollte.

Warum? Es gibt hunderte, die alle besser sind als Deine.

--
----------------------------------------------------------------------------
Marc Haber | " Questions are the | Mailadresse im Header
Rhein-Neckar, DE | Beginning of Wisdom " |
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 6224 1600402

Marc Haber wrote:
> Helmut Schellong <var@schellong.biz> wrote:
>> Ich habe mich gestern einmal gründlicher mit der Blockchiffre AES befaßt, weil
>> ich deren Implementierung starten wollte.
>
> Warum? Es gibt hunderte, die alle besser sind als Deine.

Du erzählst von einem Paradoxon.
Anhand der Quellcodes müßtest Du erläutern, warum andere Implementationen
besser sind als meine, die jedoch gar nicht existiert.

--
Mit freundlichen Grüßen
Helmut Schellong

Helmut Wabnig wrote:
> On Sat, 11 May 2024 19:51:54 +0200, Helmut Schellong
> <var@schellong.biz> wrote:
>
>> Ich habe mich gestern einmal gründlicher mit der Blockchiffre AES befaßt, weil
>> ich deren Implementierung starten wollte.
>>
>> Als ich 2022 die Stromchiffren RABBIT und DRAGON implementierte, hatte ich bereits
>> die offizielle NIST-pdf zu AES.
>> Damals hatte ich mich gegen eine AES-Implementierung entschieden.
>> Dazu ist es auch gestern gekommen.
>>
>> STROMCHIFFRE
>>
>> Die Stromchiffren erzeugen kryptographisch einen zufälligen Datenstrom
>> mit einer Länge von z.B. 2^68 Byte _pro Schlüssel_.
>> Das ist etwa 295 Exa-Byte oder 10^(20,47)!
>> Es handelt sich um einen Zufallszahlengenerator.
>>
>> Diese Zufallszahlen können XOR-verknüpft werden mit einer zu verschlüsselnden Datei:
>> . datei = datei ^ random;
>> . datei ist nun verschlüsselt.
>> . datei = datei ^ random;
>> . datei ist nun entschlüsselt.
>> Es kann zwischen verschlüsseltem und entschlüsseltem Zustand gewechselt werden, einfach
>> indem jeweils genau die gleiche Operation durchgeführt wird!
>> .........
>
> Wie hammse denn seinerzeit die Stromchiffren geknackt,
> zum Beispiel den Datenstrom um 1 Zeichen versetzt mit sich selbst
> gexort, weil dann die Doppelbuchstaben rausfallen,
> zB Su-mm-e der Gu-mm-ibeste-ll-ungen
> und das ist doch heute genauso machbar, oder?
> Bin nicht vom Fach und habe keene Ahnung nicht.

Das könnte eine Art Anekdote sein, die nicht ernst genommen werden sollte.

Seit etwa 2000 sind viele Stromchiffren entstanden, durch Wettbewerbe wie ECRYPT beflügelt.
Die gelten seit dieser Zeit als sicher.
Die sind überwiegend fähig, Schlüssel mit 256 Bit zu verarbeiten, mindestens 128 Bit.
Längere Schlüssel sind bis heute nicht verbreitet.
Diese neueren Stromchiffren sind folglich modern.

--
Mit freundlichen Grüßen
Helmut Schellong

On 2024-05-12, Helmut Wabnig <hwabnig@> wrote:

> Wie hammse denn seinerzeit die Stromchiffren geknackt,
> zum Beispiel den Datenstrom um 1 Zeichen versetzt mit sich selbst
> gexort, weil dann die Doppelbuchstaben rausfallen,
> zB Su-mm-e der Gu-mm-ibeste-ll-ungen

Nehmen wir mal "Summ" und verknüpfen es mit der Chiffrestromfolge
t x y z:

'S' ^ t
'u' ^ x
'm' ^ y
'm' ^ z

Jetzt verknüpfen wir das Ergebnis mit sich selbst um eine
Stelle verschoben:

'S' ^ t ^ ...
'u' ^ x ^ 'S' ^ t
'm' ^ y ^ 'u' ^ x
'm' ^ z ^ 'm' ^ y

Damit haben wir

...
'u' ^ x ^ 'S' ^ t
'm' ^ y ^ 'u' ^ x
z ^ y

Nach Ausfall des Buchstabens bleibt die Verknüpfung zweier Unbekannter.
Wie geht's jetzt weiter?

> Bin nicht vom Fach und habe keene Ahnung nicht.

Ich auch nicht. Ich versuche gerade soviel von Kryptografie zu
verstehen, dass ich sie anwenden kann.

Ein Problem von Stromchiffren ist die Formbarkeit (Malleability)
des verschlüsselten Texts: ein aktiver Angreifer kann einfach ein
Bit kippen und dann ist im entschlüsselten Text auch ein Bit gekippt.
Daher immer mit einem Nachrichtenauthentifizierungscode (Message
Authentication Code, MAC) verwenden.

Bei klassischen Stromchiffres kann nicht wahlfrei auf den Schlüsselstrom
zugegriffen werden, was für Parallelisierung und manche Anwendungen
unpraktisch ist.

--
Christian "naddy" Weisgerber naddy@mips.inka.de

On 2024-05-12, Marc Haber <mh+usenetspam1118@zugschl.us> wrote:

>>Ich habe mich gestern einmal gründlicher mit der Blockchiffre AES befaßt, weil
>>ich deren Implementierung starten wollte.
>
> Warum? Es gibt hunderte, die alle besser sind als Deine.

*Schulterzuck* Because we can?
https://github.com/gh2o/bash_tls/

--
Christian "naddy" Weisgerber naddy@mips.inka.de

Am 12.05.24 um 08:38 schrieb Marc Haber:
> Helmut Schellong <var@schellong.biz> wrote:
>> Ich habe mich gestern einmal gründlicher mit der Blockchiffre AES befaßt, weil
>> ich deren Implementierung starten wollte.
> Warum? Es gibt hunderte, die alle besser sind als Deine.

Nu wart's mal ab. Er hat ja noch nicht mal angefangen.

BTW: Ist das Thema hier nicht Mega-OT?

Gruß

Gregor

--
Dreck ist Materie am falschen Platz. (Schotty)

Helmut Schellong <var@schellong.biz> wrote:
>Marc Haber wrote:
>> Helmut Schellong <var@schellong.biz> wrote:
>>> Ich habe mich gestern einmal gründlicher mit der Blockchiffre AES befaßt, weil
>>> ich deren Implementierung starten wollte.
>>
>> Warum? Es gibt hunderte, die alle besser sind als Deine.
>
>Du erzählst von einem Paradoxon.
>Anhand der Quellcodes müßtest Du erläutern, warum andere Implementationen
>besser sind als meine, die jedoch gar nicht existiert.

Ich weiß aus deinen Postings wie Du arbeitest und wie viel Zweifel Du
an Deiner eigenen Arbeit hast. Da KANN nichts anständiges bei
rauskommen.

Grüße
Marc
--
----------------------------------------------------------------------------
Marc Haber | " Questions are the | Mailadresse im Header
Rhein-Neckar, DE | Beginning of Wisdom " |
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 6224 1600402

Christian Weisgerber wrote:
> On 2024-05-12, Helmut Wabnig <hwabnig@> wrote:
>
>> Wie hammse denn seinerzeit die Stromchiffren geknackt,
>> zum Beispiel den Datenstrom um 1 Zeichen versetzt mit sich selbst
>> gexort, weil dann die Doppelbuchstaben rausfallen,
>> zB Su-mm-e der Gu-mm-ibeste-ll-ungen
>
> Nehmen wir mal "Summ" und verknüpfen es mit der Chiffrestromfolge
> t x y z:
>
> 'S' ^ t
> 'u' ^ x
> 'm' ^ y
> 'm' ^ z
>
> Jetzt verknüpfen wir das Ergebnis mit sich selbst um eine
> Stelle verschoben:
>
> 'S' ^ t ^ ...
> 'u' ^ x ^ 'S' ^ t
> 'm' ^ y ^ 'u' ^ x
> 'm' ^ z ^ 'm' ^ y
>
> Damit haben wir
>
> ...
> 'u' ^ x ^ 'S' ^ t
> 'm' ^ y ^ 'u' ^ x
> z ^ y
>
> Nach Ausfall des Buchstabens bleibt die Verknüpfung zweier Unbekannter.
> Wie geht's jetzt weiter?
>
>> Bin nicht vom Fach und habe keene Ahnung nicht.
>
> Ich auch nicht. Ich versuche gerade soviel von Kryptografie zu
> verstehen, dass ich sie anwenden kann.
>
> Ein Problem von Stromchiffren ist die Formbarkeit (Malleability)
> des verschlüsselten Texts: ein aktiver Angreifer kann einfach ein
> Bit kippen und dann ist im entschlüsselten Text auch ein Bit gekippt.
> Daher immer mit einem Nachrichtenauthentifizierungscode (Message
> Authentication Code, MAC) verwenden.

Ich kenne diese (angebliche) Schwäche.
Das ist beispielsweise für mich (und andere) irrelevant.
Die unverschlüsselte Datei liefert mir einen Hash sha256, den ich aufbewahre
und später für einen pauschalen Test verwende.

Wenn ich eine Datei verschlüssele und in eine Cloud kopiere, können dabei
und beim Download ohnehin Übertragungsfehler passieren.
Ein Hash ist folglich pauschal erforderlich.
Download-Inhalten stehen ohnehin meistens Hash-Dateien beiseite.

Ich müßte ja für ein Backup auch mit einer Blockchiffre eine Datei verschlüsseln
und in eine Cloud kopieren.
Das ist ja eine identische Situation mit einer Stromchiffre.

> Bei klassischen Stromchiffres kann nicht wahlfrei auf den Schlüsselstrom
> zugegriffen werden, was für Parallelisierung und manche Anwendungen
> unpraktisch ist.

Große Dateien können zerlegt und deren Teile parallel verschlüsselt werden.
Danach kann eine Archiv-Datei gebildet werden.

Es kann auch der innere Zustand einer Stromchiffre an bestimmten Positionen
festgehalten werden, um sie später zu verwenden.

--
Mit freundlichen Grüßen
Helmut Schellong

Gregor Szaktilla wrote:
> Am 12.05.24 um 08:38 schrieb Marc Haber:
>> Helmut Schellong <var@schellong.biz> wrote:
>>> Ich habe mich gestern einmal gründlicher mit der Blockchiffre AES befaßt, weil
>>> ich deren Implementierung starten wollte.
>> Warum? Es gibt hunderte, die alle besser sind als Deine.
>
> Nu wart's mal ab. Er hat ja noch nicht mal angefangen.

Ich werde auch nicht damit anfangen!
Genau das bekräftigte ich auch in dem Posting, auf das hier geantwortet wird.

Jedoch diese meine Aussagen wurden ja hier gelöscht.
Zu diesem fortwährenden Löschen gab es bereits einen kleinen Sub-Thread.

> BTW: Ist das Thema hier nicht Mega-OT?

Nein, es gibt beispielsweise Prozessor-Instruktionen, die kryptographische
Operationen vornehmen.
Außerdem gab es hier bereits andere Krypto-Threads, ohne daß es zu OFFtopic-Kritik kam.

--
Mit freundlichen Grüßen
Helmut Schellong

Marc Haber wrote:
> Helmut Schellong <var@schellong.biz> wrote:
>> Marc Haber wrote:
>>> Helmut Schellong <var@schellong.biz> wrote:
>>>> Ich habe mich gestern einmal gründlicher mit der Blockchiffre AES befaßt, weil
>>>> ich deren Implementierung starten wollte.
>>>
>>> Warum? Es gibt hunderte, die alle besser sind als Deine.
>>
>> Du erzählst von einem Paradoxon.
>> Anhand der Quellcodes müßtest Du erläutern, warum andere Implementationen
>> besser sind als meine, die jedoch gar nicht existiert.
>
> Ich weiß aus deinen Postings wie Du arbeitest und wie viel Zweifel Du
> an Deiner eigenen Arbeit hast. Da KANN nichts anständiges bei
> rauskommen.

Ich habe noch nie irgendwelche Zweifel an meiner konkreten Arbeit gehabt.
Allerdings weiß ich stets, welches notwendige Wissen ich bereits habe
und welches noch nicht.

--
Mit freundlichen Grüßen
Helmut Schellong

Marc Haber <mh+usenetspam1118@zugschl.us> writes:

> Helmut Schellong <var@schellong.biz> wrote:
>>Ich habe mich gestern einmal gründlicher mit der Blockchiffre AES befaßt, weil
>>ich deren Implementierung starten wollte.
>
> Warum? Es gibt hunderte, die alle besser sind als Deine.

Herr Sch. kann anscheinend nicht
Zufall von Pseuduzufall unterscheiden.
Ob man so jemanden irgendetwas zutrauen kann?

--
Stefan

On Sun, 12 May 2024 20:49:27 +0200, Helmut Schellong <var@schellong.biz> wrote:

>Marc Haber wrote:
>> Helmut Schellong <var@schellong.biz> wrote:
>>> Marc Haber wrote:
>>>> Helmut Schellong <var@schellong.biz> wrote:
>>>>> Ich habe mich gestern einmal gründlicher mit der Blockchiffre AES befaßt, weil
>>>>> ich deren Implementierung starten wollte.
>>>>
>>>> Warum? Es gibt hunderte, die alle besser sind als Deine.
>>>
>>> Du erzählst von einem Paradoxon.
>>> Anhand der Quellcodes müßtest Du erläutern, warum andere Implementationen
>>> besser sind als meine, die jedoch gar nicht existiert.
>>
>> Ich weiß aus deinen Postings wie Du arbeitest und wie viel Zweifel Du
>> an Deiner eigenen Arbeit hast. Da KANN nichts anständiges bei
>> rauskommen.
>
>Ich habe noch nie irgendwelche Zweifel an meiner konkreten Arbeit gehabt.

Genau.

Thomas Prufer

Stefan Wiens wrote:
> Marc Haber <mh+usenetspam1118@zugschl.us> writes:
>
>> Helmut Schellong <var@schellong.biz> wrote:
>>> Ich habe mich gestern einmal gründlicher mit der Blockchiffre AES befaßt, weil
>>> ich deren Implementierung starten wollte.
>>
>> Warum? Es gibt hunderte, die alle besser sind als Deine.
>
> Herr Sch. kann anscheinend nicht
> Zufall von Pseuduzufall unterscheiden.
> Ob man so jemanden irgendetwas zutrauen kann?

Erläutere doch mal, warum ich das angeblich nicht unterscheiden kann.
Das wirst Du nicht können.
Warum?
Du stellst einfach Behauptungen auf, weil Du irgendwas Argumentatives brauchst.

Ich habe schon in den 1980ern erfolgreich Hardware-Zufallsgeneratoren gebaut.
Früher, als hier manche geboren wurden.
Pseudozufalls-Generatoren habe ich zu dieser Zeit auch betrieben, unter SCO-Unix386.

Quatschkopp.

--
Mit freundlichen Grüßen
Helmut Schellong

Helmut Schellong <var@schellong.biz> writes:

> Stefan Wiens wrote:
>> Marc Haber <mh+usenetspam1118@zugschl.us> writes:
>>
>>> Helmut Schellong <var@schellong.biz> wrote:
>>>> Ich habe mich gestern einmal gründlicher mit der Blockchiffre AES befaßt, weil
>>>> ich deren Implementierung starten wollte.
>>>
>>> Warum? Es gibt hunderte, die alle besser sind als Deine.
>>
>> Herr Sch. kann anscheinend nicht
>> Zufall von Pseuduzufall unterscheiden.
>> Ob man so jemanden irgendetwas zutrauen kann?
>
> Erläutere doch mal, warum ich das angeblich nicht unterscheiden kann.
> Das wirst Du nicht können.
> Warum?
> Du stellst einfach Behauptungen auf, weil Du irgendwas Argumentatives brauchst.

Du schriebst, Klartext würde mit /Zufallszahlen/
XOR-verknüpft.

Wie will man das jemals entschlüsseln?

Einen Strom von Zufallszahlen kann man nicht reproduzieren.

--
Stefan

Helmut Schellong schrieb:

> Ich habe noch nie irgendwelche Zweifel an meiner konkreten Arbeit gehabt.

Nachvollziehbar. Das fällt bei von sich selber völlig überzeugten
Menschen immer wieder auf und ist regelmäßig ein zuverlässiges
Erkennungszeichen für Personen, die man zu nichts gebrauchen kann.
Wer noch nicht einmal fähig ist, sich und seine Arbeit kritisch zu
bewerten, den will man nicht an wichtigeren Positionen als evtl. dem
Fahrer der Kehrmaschine für den Ladehof haben

MfG
Rupert

Stefan Wiens wrote:
> Helmut Schellong <var@schellong.biz> writes:
>
>> Stefan Wiens wrote:
>>> Marc Haber <mh+usenetspam1118@zugschl.us> writes:
>>>
>>>> Helmut Schellong <var@schellong.biz> wrote:
>>>>> Ich habe mich gestern einmal gründlicher mit der Blockchiffre AES befaßt, weil
>>>>> ich deren Implementierung starten wollte.
>>>>
>>>> Warum? Es gibt hunderte, die alle besser sind als Deine.
>>>
>>> Herr Sch. kann anscheinend nicht
>>> Zufall von Pseuduzufall unterscheiden.
>>> Ob man so jemanden irgendetwas zutrauen kann?
>>
>> Erläutere doch mal, warum ich das angeblich nicht unterscheiden kann.
>> Das wirst Du nicht können.
>> Warum?
>> Du stellst einfach Behauptungen auf, weil Du irgendwas Argumentatives brauchst.
>
> Du schriebst, Klartext würde mit /Zufallszahlen/
> XOR-verknüpft.

In beiden/allen Krypto-Threads wurde ausnahmslos von kryptografischen Algorithmen geschrieben.
Solche können nur Pseudo-Zufallszahlen generieren.
Das ist der Kontext.

11.05.2024, 19:51
|Die Stromchiffren erzeugen kryptographisch einen zufälligen Datenstrom
|mit einer Länge von z.B. 2^68 Byte _pro Schlüssel_.
|Das ist etwa 295 Exa-Byte oder 10^(20,47)!
|Es handelt sich um einen Zufallszahlengenerator.
| |Diese Zufallszahlen können XOR-verknüpft werden mit einer zu verschlüsselnden Datei:

Vorstehend der Original-Text.
Das Wort 'Zufallszahlen' bezieht sich direkt auf das Wort 'Zufallszahlengenerator' zuvor.
Echte Zufallszahlen können nicht von einem Zufallszahlengenerator generiert werden, sondern
es werden dazu Hardware-Ereignisse abgetastet, was keine Generierung ist.

Auf jeden Fall beweisen die ersten vier Zeilen des Original-Textes mehrfach, daß der
dort genannte 'Zufallszahlengenerator' Pseudo-Zufallszahlen generiert.

> Wie will man das jemals entschlüsseln?
>
> Einen Strom von Zufallszahlen kann man nicht reproduzieren.

Ja, das wußte ich allerdings bereits in den 1980ern.

--
Mit freundlichen Grüßen
Helmut Schellong

Rupert Haselbeck wrote:
> Helmut Schellong schrieb:
>
>> Ich habe noch nie irgendwelche Zweifel an meiner konkreten Arbeit gehabt.
>
> Nachvollziehbar. Das fällt bei von sich selber völlig überzeugten Menschen immer wieder auf und ist regelmäßig ein zuverlässiges
> Erkennungszeichen für Personen, die man zu nichts gebrauchen kann.
> Wer noch nicht einmal fähig ist, sich und seine Arbeit kritisch zu bewerten, den will man nicht an wichtigeren Positionen als evtl.
> dem Fahrer der Kehrmaschine für den Ladehof haben

|> Ich weiß aus deinen Postings wie Du arbeitest und wie viel Zweifel Du
|> an Deiner eigenen Arbeit hast. Da KANN nichts anständiges bei
|> rauskommen.
| |Ich habe noch nie irgendwelche Zweifel an meiner konkreten Arbeit gehabt.
|Allerdings weiß ich stets, welches notwendige Wissen ich bereits habe
|und welches noch nicht.

Der Originaltext entlarvt Eure irrationalen Tricksereien, Täuschereien und Betrügereien.

--
Mit freundlichen Grüßen
Helmut Schellong

>> BTW: Ist das Thema hier nicht Mega-OT?

Nein.
100%ige OFFtopics kannst Du Dir derzeit erneut massenhaft anschauen.
Nämlich Politik, Gesellschaft, Psychiatrie, Gesetze, BGB, etc.

Niemand klagt dagegen, oder fragt, ob das OFFtopic ist, sondern diese
Total-OFFtopics werden begeistert und intensiv aufgenommen und fortgeführt.

Übrigens:
Ich habe hier beispielhaft alles gelöscht, auf das ich nicht direkt antworte.
So, wie es verbreitet bevorzugt wird.

--
Mit freundlichen Grüßen
Helmut Schellong

Helmut Schellong wrote:
> Christian Weisgerber wrote:
>> On 2024-05-12, Helmut Wabnig <hwabnig@> wrote:
>>
>>> [...]

>> Ich auch nicht. Ich versuche gerade soviel von Kryptografie zu
>> verstehen, dass ich sie anwenden kann.
>>
>> Ein Problem von Stromchiffren ist die Formbarkeit (Malleability)
>> des verschlüsselten Texts: ein aktiver Angreifer kann einfach ein
>> Bit kippen und dann ist im entschlüsselten Text auch ein Bit gekippt.
>> Daher immer mit einem Nachrichtenauthentifizierungscode (Message
>> Authentication Code, MAC) verwenden.
>
> Ich kenne diese (angebliche) Schwäche.
> Das ist beispielsweise für mich (und andere) irrelevant.
> Die unverschlüsselte Datei liefert mir einen Hash sha256, den ich aufbewahre
> und später für einen pauschalen Test verwende.
>
> Wenn ich eine Datei verschlüssele und in eine Cloud kopiere, können dabei
> und beim Download ohnehin Übertragungsfehler passieren.
> Ein Hash ist folglich pauschal erforderlich.
> Download-Inhalten stehen ohnehin meistens Hash-Dateien beiseite.
>
> Ich müßte ja für ein Backup auch mit einer Blockchiffre eine Datei verschlüsseln
> und in eine Cloud kopieren.
> Das ist ja eine identische Situation mit einer Stromchiffre.

Zur Nutzung von Kryptographie sollte eine Konzentration auf geeignete
Algorithmen erfolgen (Chiffre, Hash, Random).
Sobald ein solcher ausgewählt wurde, kann damit beispielsweise eine Datei verschlüsselt werden.

Viel Augenmerk auf die Theorie zu richten, kann ein Irrweg sein, denn fast alles
aus diesem Bereich wird irrelevant in der konkreten Praxis sein (s.o.).

Schwachstellen ergeben sich jeweils aus einem konkreten Anwendungsfall fast von selbst.
Beispielsweise sollte ein Schlüssel selbst eine Zufallsfolge mit hoher Entropie sein.
Schlüssel wie '0..' oder '11112222333344445555..' gibt es nur zwecks Demonstration.

Die Eigenschaft eines nicht authentifizierten Datenstroms, der verändert werden kann, gilt
_ebenso_ für Blockchiffre - wie für Stromchiffre!
Für Blockchiffre stehen drei von neun Betriebs-Modi zur Verfügung, die eine
zusätzliche Authentifizierung gestatten.
Dazu muß die Blockchiffre doppelt durchlaufen werden und der (erhebliche) Aufwand
für die Authentifizierung kommt hinzu.

Letztlich erfüllt der obligatorische Hash von der unverschlüsselten Datei (s.o.)
den gleichen Zweck.
Der vergleichsweise riesige Aufwand mit Blockchiffren kann eingespart werden.

>> Bei klassischen Stromchiffres kann nicht wahlfrei auf den Schlüsselstrom
>> zugegriffen werden, was für Parallelisierung und manche Anwendungen
>> unpraktisch ist.
>
> Große Dateien können zerlegt und deren Teile parallel verschlüsselt werden.
> Danach kann eine Archiv-Datei gebildet werden.

Die Teile einer Datei müssen keine mit Namen versehenen Dateien außerhalb sein, sondern
es können Dateiteile gezielt 'von..bis von..bis ..' verschlüsselt werden (lseek() z.B.).
Ein Eltern-Prozeß kann auch per fork() Kinder-Prozesse erzeugen (Kopien von sich selbst).

Eine Stromchiffre kann so schnell verschlüsseln, daß eine pure Dateioperation kaum schneller ist.
https://en.wikipedia.org/wiki/Rabbit_(cipher)

> Es kann auch der innere Zustand einer Stromchiffre an bestimmten Positionen
> festgehalten werden, um sie später zu verwenden.
>
>

--
Mit freundlichen Grüßen
Helmut Schellong