Verschlüsselung: Bedeutung der Blocklänge?

[Gunther Kral]

Welche Bedeutung hat die Blocklänge bei Verschlüsselung?

Ich frage aufgrund der folgenden Beschreibungen von AES-256 und
Rijndael-256:

"AES-256

Dieser Algorithmus entspricht dem AES-128 Algorithmus, arbeitet jedoch
mit einem 256-Bit-Schlüssel und 128 bit Blocklänge.

Rijndael-256

Dieser Algorithmus ist eine spezifische Implementierung des AES-256.
Er entspricht dem AES-256, verfügt jedoch über 256 bit Blocklänge."

Gruss, Gunther

[Philipp Neuhaus]

Post by Gunther Kral
Rijndael-256
Dieser Algorithmus ist eine spezifische Implementierung des AES-256.
Er entspricht dem AES-256, verfügt jedoch über 256 bit Blocklänge."

Wo hast du diese Beschreibungen gefunden?
Der Rijndael als spezielle Implementierung des AES zu sehen find' ich gut.

Grüße
Philipp

[Gunther Kral]

Post by Philipp Neuhaus

Post by Gunther Kral
Rijndael-256
Dieser Algorithmus ist eine spezifische Implementierung des AES-256.
Er entspricht dem AES-256, verfügt jedoch über 256 bit Blocklänge."

Wo hast du diese Beschreibungen gefunden?
Der Rijndael als spezielle Implementierung des AES zu sehen find' ich gut.

In der Dokumentation von SafeGuard Easy von Utimaco. Wie ist deine
Aussage zu verstehen?

Nachfolgend die Beschreibung aller Verschlüsselungsmethoden, die SGE
unterstützt:

"AES-128

Der Advanced Encryption Standard (AES) ist ein
Verschlüsselungsalgorithmus, welcher den DES Algorithmus ersetzt. Für
diesen Algorithmus wurde vom National Institute for Standards and
Technology (USA) der Algorithmus Rijndael ausgewählt. Es handelt sich
dabei um einen sehr schnellen und sicheren
Verschlüsselungsalgorithmus. AES-128 arbeitet mit einem
128-Bit-Schlüssel.

AES-256

Dieser Algorithmus entspricht dem AES-128 Algorithmus, arbeitet jedoch
mit einem 256-Bit-Schlüssel und 128 bit Blocklänge.

Rijndael-256

Dieser Algorithmus ist eine spezifische Implementierung des AES-256.
Er entspricht dem AES-256, verfügt jedoch über 256 bit Blocklänge.

IDEA

IDEA (International Data Encryption Algorithm) wurde Anfang der 90er
Jahre entwickelt. Es ist ein symmetrischer
Verschlüsselungsalgorithmus, der mit einem 128-Bit-Schlüssel arbeitet.
Er wird heutzutage als sicher angesehen, sowohl in Bezug auf
mathematische Verfahren als auch auf Schlüssellänge und gilt als
äußerst resistent gegenüber allen Angriffen der Kryptoanalyse.

DES

DES (Data Encryption Standard) wurde in den 70er Jahren entwickelt und
verwendet eine Schlüssellänge von 56 Bit.

Blowfish-16 / Blowfish-8

Blowfish ist ein relativ neuer, von Bruce Schneier entwickelter,
symmetrischer Algorithmus. Er verwendet einen
64-Bit-Blockchiffrieralgorithmus und verwendet eine Schlüssellänge von
256 Bit.
Der Blowfish-8-Algorithmus entspricht dem Blowfish- 16-Algorithmus,
ist jedoch auf acht Runden reduziert. Er verwendet eine Schlüssellänge
von 256 Bit. Auch bei diesem Algorithmus liegen noch keine genauen
Aussagen über seine Sicherheit vor. Er ist jedoch ebenfalls deutlich
sicherer als XOR.

STEALTH-40

Dieser Algorithmus ist etwa gleich schnell wie XOR, aber deutlich
sicherer. Der STEALTH-Algorithmus verwendet eine Schlüssellänge von
48-64 Bit.

XOR

XOR (eXclusive Or opeRation) ist ein symmetrischer Algorithmus und
verwendet eine Schlüssellänge von 64 Bit. Seine Sicherheit ist
allerdings als niedrig einzustufen.

TIPP:

Wenn Sie ein hochsicheres System aufsetzen wollen, verwenden Sie bitte
IDEA oder AES/Rijndael."

Gruss, Gunther

[Jörg W Mittag]

Post by Gunther Kral

Post by Philipp Neuhaus

Post by Gunther Kral
Rijndael-256
Dieser Algorithmus ist eine spezifische Implementierung des AES-256.
Er entspricht dem AES-256, verfügt jedoch über 256 bit Blocklänge."

Wo hast du diese Beschreibungen gefunden?
Der Rijndael als spezielle Implementierung des AES zu sehen find' ich gut.

In der Dokumentation von SafeGuard Easy von Utimaco. Wie ist deine
Aussage zu verstehen?

Als Belustigung über diese Verdrehung der Tatsachen, vermute ich: AES
ist die Standardisierung einer speziellen Implementierung von
Rijndael, nicht umgekehrt.

jwm

[Markus L. Dechert]

On 07/26/2004 02:58 PM, Gunther Kral wrote:
Hallo Gunther,

Post by Gunther Kral
Welche Bedeutung hat die Blocklänge bei Verschlüsselung?

ich versuche das mal auf den AES bezogen zu beantworten. In [1] finden
sich dazu einige Aussagen.

Daemen und Rijmen schreiben da:
<quote>
Variable block length:
The block lengths of 192 and 256 bits allow the construction of a
collision-resistant iterated hash function using Rijndael as the
compression function. The block length of 128 bits is not considered
sufficient for this purpose nowadays.
</quote>
Was ich ziemlich einleuchtend finde. Für die symmetrische
Verschlüsselung, sollte das allerdings garkeine Auswirkungen haben.

Einen Sicherheitsvorteil scheint die größere Blocklänge nach folgender
Aussage wohl nicht zu bringen:
<quote>
For Rijndael versions with a higher block length, the number of rounds
is raised by one for every additional 32 bits in the block length, for
the following reasons:

For a block length above 128 bits, it takes 3 rounds to realise full
diffusion, i.e., the diffusion power of a round, relative to the
block length, diminishes with the block length.

The larger block length causes the range of possible patterns that
can be applied at the input/output of a sequence of rounds to
increase. This added flexibility may allow to extend attacks by one
or more rounds.

We have found that extensions of attacks by a single round are even hard
to realise for the maximum block length of 256 bits. Therefore, this is
a conservative margin.
</quote>

Nach kurzer Überlegung scheint mir - aus dem Bauch heraus! - plausibel
zu sein, dass die Blocklänge der Schlüssellänge gegenüber eine
untergeordnete Rolle spielt. Der Schlüssel ist ja für die Randomisierung
wichtig. Ohnehin sollte man ja den Chiffre nicht im ECB betreiben. Nach
Schneier [2] gibt es wohl Diskussionen darüber, ob nicht sogar 64 Bit
für Blockchiffren ausreichen.

Post by Gunther Kral
Ich frage aufgrund der folgenden Beschreibungen von AES-256 und
"AES-256
Dieser Algorithmus entspricht dem AES-128 Algorithmus, arbeitet jedoch
mit einem 256-Bit-Schlüssel und 128 bit Blocklänge.
Rijndael-256
Dieser Algorithmus ist eine spezifische Implementierung des AES-256.
Er entspricht dem AES-256, verfügt jedoch über 256 bit Blocklänge."

Hä? Das klingt suspekt in meinen Ohren. Möglicherweise kommt die
Konfusion aber daher, dass beim AES Schlüssel- und Blocklänge getrennt
voneinander angepasst werden können [1].

Post by Gunther Kral
Gruss, Gunther

Gruß
Markus


[1] http://csrc.nist.gov/encryption/aes/rijndael/Rijndael.pdf
[2] B. Schneier, "Applied Cryptography", Addison Wesley

[Florian Weimer]

Post by Gunther Kral
Welche Bedeutung hat die Blocklänge bei Verschlüsselung?

Wenn man unbedingt den ECB-Modus verwenden muß (was man meist
krampfhaft zu vermeiden versucht), erschwert eine höhere Blocklänge
den typischen Angriff, bei dem versucht wird, Teile des Codebuchs zu
rekonstruieren. Die Auswirkungen von Chosen-Plaintext-Angriffen können
so ein wenig gemildert werden (weil man in Deinem Fall Blöcke von 32
statt 16 Bytes erraten muß), aber in den meisten Fällen dürfte das
kein so wesentlicher Gewinn sein, daß man den ECB-Modus plötzlich
ruhigen Gewissens einsetzen könnte.

[Gunther Kral]

Post by Florian Weimer

Post by Gunther Kral
Welche Bedeutung hat die Blocklänge bei Verschlüsselung?

Wenn man unbedingt den ECB-Modus verwenden muß (was man meist
krampfhaft zu vermeiden versucht), erschwert eine höhere Blocklänge
den typischen Angriff, bei dem versucht wird, Teile des Codebuchs zu
rekonstruieren.

Wofür steht ECB?

Via Google habe ich folgende Erklärung gefunden: "Hier erfolgt eine
Chiffrierung von Klartextblöcken (Gruppen von Bits) in die jeweils
dazugehörigen Geheimtextblöcke. Mehr nicht. Viele kommerzielle
Programme arbeiten nur im ECB (Electronic Codebook Mode) Modus. ECB
ist die einfachste Art, einen Blockalgorithmus in ein Programm zu
integrieren." (http://www.cryptolution.de/Cryptolution.htm) Kommt das
hin?

Welche Verschlüsselungsverfahren verwenden einen ECB-Modus?

Gruss, Gunther

[Lutz Donnerhacke]

Post by Gunther Kral

Post by Florian Weimer

Post by Gunther Kral
Welche Bedeutung hat die Blocklänge bei Verschlüsselung?

Wenn man unbedingt den ECB-Modus verwenden muß (was man meist
krampfhaft zu vermeiden versucht), erschwert eine höhere Blocklänge
den typischen Angriff, bei dem versucht wird, Teile des Codebuchs zu
rekonstruieren.

Wofür steht ECB?

Electronic CodeBook mode.

Post by Gunther Kral
Via Google habe ich folgende Erklärung gefunden: "Hier erfolgt eine
Chiffrierung von Klartextblöcken (Gruppen von Bits) in die jeweils
dazugehörigen Geheimtextblöcke. Mehr nicht. Viele kommerzielle
Programme arbeiten nur im ECB (Electronic Codebook Mode) Modus. ECB
ist die einfachste Art, einen Blockalgorithmus in ein Programm zu
integrieren." (http://www.cryptolution.de/Cryptolution.htm) Kommt das
hin?

Ja. Warum zweifelst Du?

Post by Gunther Kral
Welche Verschlüsselungsverfahren verwenden einen ECB-Modus?

Falsche Frage. Man verwendet Verschlüsselungsverfahren in Modi. ECB ist einer.

[Gunther Kral]

Post by Lutz Donnerhacke

Post by Gunther Kral
Via Google habe ich folgende Erklärung gefunden: "Hier erfolgt eine
Chiffrierung von Klartextblöcken (Gruppen von Bits) in die jeweils
dazugehörigen Geheimtextblöcke. Mehr nicht. Viele kommerzielle
Programme arbeiten nur im ECB (Electronic Codebook Mode) Modus. ECB
ist die einfachste Art, einen Blockalgorithmus in ein Programm zu
integrieren." (http://www.cryptolution.de/Cryptolution.htm) Kommt das
hin?

Ja. Warum zweifelst Du?

... wieso sollte ich nicht zweifeln, wo die Beschreibung doch aus
einer Quelle stammt, die ich nicht beurteilen kann?

Post by Lutz Donnerhacke

Post by Gunther Kral
Welche Verschlüsselungsverfahren verwenden einen ECB-Modus?

Falsche Frage. Man verwendet Verschlüsselungsverfahren in Modi. ECB ist einer.

Man entscheidet sich also beispielsweise für AES-256 und verwendet
dieses im ECB-Modus? Gibt es Verschlüsselungs-Software, wo man das
konfigurieren und nicht bloss das Verfahren auswählen kann?

Gruss, Gunther

[Lutz Donnerhacke]

Post by Gunther Kral

Post by Lutz Donnerhacke
Ja. Warum zweifelst Du?

... wieso sollte ich nicht zweifeln, wo die Beschreibung doch aus
einer Quelle stammt, die ich nicht beurteilen kann?

Kannst Du Usenet beurteilen?

Post by Gunther Kral

Post by Lutz Donnerhacke
Falsche Frage. Man verwendet Verschlüsselungsverfahren in Modi. ECB ist einer.

Man entscheidet sich also beispielsweise für AES-256 und verwendet
dieses im ECB-Modus?

Ja.

Post by Gunther Kral
Gibt es Verschlüsselungs-Software, wo man das konfigurieren und nicht
bloss das Verfahren auswählen kann?

Ja.

[Gunther Kral]

Post by Lutz Donnerhacke

Post by Gunther Kral

Post by Lutz Donnerhacke
Ja. Warum zweifelst Du?

... wieso sollte ich nicht zweifeln, wo die Beschreibung doch aus
einer Quelle stammt, die ich nicht beurteilen kann?

Kannst Du Usenet beurteilen?

Es geht nicht um das Medium, sondern um die Quelle. Im Usenet weiss
ich beispielsweise bei einigen Benutzern aus Erfahrung, wie
vertrauenswürdig ihre Aussagen sind.

Gruss, Gunther

[Florian Weimer]

Post by Gunther Kral

Post by Lutz Donnerhacke
Falsche Frage. Man verwendet Verschlüsselungsverfahren in Modi. ECB ist einer.

Man entscheidet sich also beispielsweise für AES-256 und verwendet
dieses im ECB-Modus? Gibt es Verschlüsselungs-Software, wo man das
konfigurieren und nicht bloss das Verfahren auswählen kann?

Meistens schreiben die Protokolle vor, welcher Modus einzusetzen ist,
weil die Wahl des Modus meist schwerwiegende Auswirkungen auf die
Sicherheitseigenschaften des Protokolls hat.

[Florian Weimer]

Post by Gunther Kral

Post by Lutz Donnerhacke
Falsche Frage. Man verwendet Verschlüsselungsverfahren in Modi. ECB ist einer.

Man entscheidet sich also beispielsweise für AES-256 und verwendet
dieses im ECB-Modus? Gibt es Verschlüsselungs-Software, wo man das
konfigurieren und nicht bloss das Verfahren auswählen kann?

Meistens schreiben die Protokolle vor, welcher Modus einzusetzen ist,
weil die Wahl des Modus meist schwerwiegende Auswirkungen auf die
Sicherheitseigenschaften des Protokolls hat. Bei generischen
Krypto-Bibliotheken, die verwendet werden, um solche Protokolle zu
implementieren, gibt es natürlich entsprechende Wahlmöglichkeiten,
aber diese werden mit gutem Grund dem Benutzer selten zur Wahl
gestellt.

[Volker Birk]

Post by Gunther Kral
Man entscheidet sich also beispielsweise für AES-256 und verwendet
dieses im ECB-Modus?

ECB-Modus vermeidet man grundsätzlich. Entweder man verwendet CBC, oder
aber man verwendet CFB (oder OFB).

Viele Grüße,
VB.

[Richard W. Könning]

Post by Volker Birk

Post by Gunther Kral
Man entscheidet sich also beispielsweise für AES-256 und verwendet
dieses im ECB-Modus?

ECB-Modus vermeidet man grundsätzlich. Entweder man verwendet CBC, oder
aber man verwendet CFB (oder OFB).

In neuerer Zeit findet auch der CTR- (für Counter-) Mode
(http://csrc.nist.gov/publications/nistpubs/800-38a/sp800-38a.pdf, p.
75) Interesse, zumindestens Ferguson/Schneier sind recht angetan von
ihm. Er hat insbesondere den Vorteil, daß die einzelnen Blöcke
unabhängig berechnet werden können. Dies bietet den Vorteil der
Geschwindigkeitserhöhung durch Parallelisierung.
Ciao,
Richard

[Ralf Muschall]

Post by Richard W. Könning
(http://csrc.nist.gov/publications/nistpubs/800-38a/sp800-38a.pdf, p.
75) Interesse, zumindestens Ferguson/Schneier sind recht angetan von
ihm. Er hat insbesondere den Vorteil, daß die einzelnen Blöcke
unabhängig berechnet werden können. Dies bietet den Vorteil der
Geschwindigkeitserhöhung durch Parallelisierung.

Potentielles Problem nach erstem Überfliegen: Wenn die Counter nicht
selbst einigermaßen wüst sind, liefert man dem Angreifer Futter für
Differential Cryptanalysis o.ä.

Ralf

[Richard W. Könning]

Post by Ralf Muschall
Potentielles Problem nach erstem Überfliegen: Wenn die Counter nicht
selbst einigermaßen wüst sind, liefert man dem Angreifer Futter für
Differential Cryptanalysis o.ä.

Was verstehst Du unter wüste Counter? Btw, ich habe das von mir
angegebene Paper noch nicht selbst gelesen, sondern nur eine
Quellenangabe aus "Practical Cryptography" wiedergegeben; ich vertraue
aber den beiden Autoren, daß sie einigermaßen wissen, was sie
empfehlen.
Ciao,
Richard

[Lutz Donnerhacke]

Post by Ralf Muschall
Potentielles Problem nach erstem Überfliegen: Wenn die Counter nicht
selbst einigermaßen wüst sind, liefert man dem Angreifer Futter für
Differential Cryptanalysis o.ä.

Counter-Mode wird i.d.R. bei Festplattenverschluesselung benutzt.
Da ist eh' genug Futter da.

[Christian Thöing]

Post by Lutz Donnerhacke
Counter-Mode wird i.d.R. bei Festplattenverschluesselung benutzt.

ACK.

Post by Lutz Donnerhacke
Da ist eh' genug Futter da.

Futter wofür? Moderne Verfahren bieten ausreichend Sicherheit gegen
known-plaintext-Angriffe. Auch im CTR-Modus.

[Lutz Donnerhacke]

Post by Christian Thöing

Post by Lutz Donnerhacke
Counter-Mode wird i.d.R. bei Festplattenverschluesselung benutzt.
Da ist eh' genug Futter da.

Futter wofür?

Know-Plaintext. Egal welcher Modus.

[Christian Thöing]

Post by Lutz Donnerhacke

Post by Christian Thöing

Post by Lutz Donnerhacke
Counter-Mode wird i.d.R. bei Festplattenverschluesselung benutzt.
Da ist eh' genug Futter da.

Futter wofür?

Know-Plaintext. Egal welcher Modus.

So what? Bei Blowfish/AES etc. kann ich eine Milliarde bekannte
Klartexte haben und die Chiffrierung trotzdem nicht brechen (nach
heutigem Stand der Kryptoanalyse).

[Lutz Donnerhacke]

Post by Christian Thöing

Post by Lutz Donnerhacke

Post by Christian Thöing

Post by Lutz Donnerhacke
Counter-Mode wird i.d.R. bei Festplattenverschluesselung benutzt.
Da ist eh' genug Futter da.

Futter wofür?

Know-Plaintext. Egal welcher Modus.

So what? Bei Blowfish/AES etc. kann ich eine Milliarde bekannte
Klartexte haben und die Chiffrierung trotzdem nicht brechen (nach
heutigem Stand der Kryptoanalyse).

Eben.

[Christian Thöing]

Post by Christian Thöing
So what? Bei Blowfish/AES etc. kann ich eine Milliarde bekannte
Klartexte haben und die Chiffrierung trotzdem nicht brechen (nach
heutigem Stand der Kryptoanalyse).

Eben.

Falls sich dieses "eben" auf die Aussage bezieht, dass "sichere"
Verfahren _nach heutigem Stand der Kryptoanalyse_ gegen
known-plain-text-Angriffe resistent zu sein scheinen, so weise ich
entschieden darauf hin, dass in der Kryptographie (fast) alles unter
diesem Vorbehalt zu beurteilen ist. Allerdings spricht momentan nichts
dafür, dass z.B. Blowfish anfällig für irgendeinen Angriff sein könnte.
Ich würde daher ohne Weiteres mehrere Gigabytes an Daten verschlüsseln,
selbst wenn der überwiegende Teil bekannt ist. --Oder missverstehe ich dich?

[Lutz Donnerhacke]

Post by Christian Thöing

Post by Christian Thöing
So what? Bei Blowfish/AES etc. kann ich eine Milliarde bekannte
Klartexte haben und die Chiffrierung trotzdem nicht brechen (nach
heutigem Stand der Kryptoanalyse).

Eben.

Falls sich dieses "eben" auf die Aussage bezieht, dass "sichere"
Verfahren _nach heutigem Stand der Kryptoanalyse_ gegen
known-plain-text-Angriffe resistent zu sein scheinen, so weise ich
entschieden darauf hin, dass in der Kryptographie (fast) alles unter
diesem Vorbehalt zu beurteilen ist.

Es ging um den Context, daß Counter Mode bekannten Klartext hat. Das hat man
bei Festplattenverschlüsselung faktisch immer.

[Florian Weimer]

Post by Lutz Donnerhacke
Counter-Mode wird i.d.R. bei Festplattenverschluesselung benutzt.

Wieso denn das? Es ist dafür nicht besser geeignet als CBC. (Ich bekam
schon einen Schreck, aber das ist sogar in einer der CTR-Reviews
erläutert.)

[Lutz Donnerhacke]

Post by Florian Weimer

Post by Lutz Donnerhacke
Counter-Mode wird i.d.R. bei Festplattenverschluesselung benutzt.

Wieso denn das?

Weil man die Blocknummer verschlüsselt und damit den Inhalt XORt.

Post by Florian Weimer
Es ist dafür nicht besser geeignet als CBC.

CBC kettet durch, damit ist Schreiben ein Problem.

Post by Florian Weimer
(Ich bekam schon einen Schreck, aber das ist sogar in einer der
CTR-Reviews erläutert.)

URL?

[Florian Weimer]

Post by Lutz Donnerhacke

Post by Florian Weimer

Post by Lutz Donnerhacke
Counter-Mode wird i.d.R. bei Festplattenverschluesselung benutzt.

Wieso denn das?

Weil man die Blocknummer verschlüsselt und damit den Inhalt XORt.

Aber Hallo! Wegen der Restmagnetisierung ist das deutlich schlimmer
als der ECB-Modus.

Post by Lutz Donnerhacke

Post by Florian Weimer
Es ist dafür nicht besser geeignet als CBC.

CBC kettet durch, damit ist Schreiben ein Problem.

Nicht, wenn man pro Block einen IV hat. Das braucht man beim CTR-Modus
auch.

Post by Lutz Donnerhacke

Post by Florian Weimer
(Ich bekam schon einen Schreck, aber das ist sogar in einer der
CTR-Reviews erläutert.)

URL?

NIST hat sie veröffentlicht.

[Lutz Donnerhacke]

Post by Florian Weimer

Post by Lutz Donnerhacke

Post by Florian Weimer

Post by Lutz Donnerhacke
Counter-Mode wird i.d.R. bei Festplattenverschluesselung benutzt.

Wieso denn das?

Weil man die Blocknummer verschlüsselt und damit den Inhalt XORt.

Aber Hallo! Wegen der Restmagnetisierung ist das deutlich schlimmer
als der ECB-Modus.

Ja, grausam.

Post by Florian Weimer

Post by Lutz Donnerhacke

Post by Florian Weimer
Es ist dafür nicht besser geeignet als CBC.

CBC kettet durch, damit ist Schreiben ein Problem.

Nicht, wenn man pro Block einen IV hat.

Halbe Platzausnutzung?

Post by Florian Weimer
Das braucht man beim CTR-Modus auch.

Bitte?

[Florian Weimer]

Post by Lutz Donnerhacke

Post by Florian Weimer

Post by Lutz Donnerhacke

Post by Florian Weimer
Es ist dafür nicht besser geeignet als CBC.

CBC kettet durch, damit ist Schreiben ein Problem.

Nicht, wenn man pro Block einen IV hat.

Halbe Platzausnutzung?

Äh, Block im Sinne des Dateisystems, meinetwegen auch "Sektor".

Post by Lutz Donnerhacke

Post by Florian Weimer
Das braucht man beim CTR-Modus auch.

Bitte?

Siehe oben.

[Lutz Donnerhacke]

Post by Florian Weimer

Post by Lutz Donnerhacke
Halbe Platzausnutzung?

Äh, Block im Sinne des Dateisystems, meinetwegen auch "Sektor".

Jetzt verstehe ich. Sorry.

[Christian Thöing]

Post by Ralf Muschall
Potentielles Problem nach erstem Überfliegen: Wenn die Counter nicht
selbst einigermaßen wüst sind, liefert man dem Angreifer Futter für
Differential Cryptanalysis o.ä.

Nein, der Counter muss keineswegs "wüst" sein, sondern kann aus einer
simplen Operation (wie n=n+1) bestehen. Chiffrierungen im OFB- und
Counter-Modus erzeugen einen pseudozufälligen Zeichenstrom (d.h. die
Blockchiffre verhält sich wie ein PRNG), völlig unabhängig vom Klartext.
Das Problem ist nun, dass die eigentliche Verschlüsselung, nämlich die
XOR-Verknüpfung mit dem Klartext, linear ist. Diese Linearität stellt in
einigen Szenarien eine teils gravierende Schwäche dar (vgl. z.B. die
Angriffe auf WEP, welche die äußerst unglückliche Verbindung von zwei
linearen Algorithmen, RC4-Verschlüsselung und CRC, ausnutzen). Mit
differenzieller oder linearer Kryptoanalyse hat das, CMIIW, nichts zu
tun; ganz beiseite, dass die meisten modernen Verfahren à la Blowfish
und AES ohnehin resistent gegen diese Art von Angriffen sind.

CTR hat allerdings den Vorteil, dass 1. sich der Schlüsselstrom im
Voraus berechnen lässt und 2. er wahlfreien Zugriff erlaubt (nützlich
vor allem bei Festplattenverschlüsselung).

[Florian Weimer]

Post by Christian Thöing
CTR hat allerdings den Vorteil, dass 1. sich der Schlüsselstrom im
Voraus berechnen lässt und 2. er wahlfreien Zugriff erlaubt (nützlich
vor allem bei Festplattenverschlüsselung).

Festplatten haben keine wahlfreien Zugriff, bloß einen
sektorweisen. 8-) Das Problem bei CBC & Co. ist, daß man den IV
irgendwie speichern muß, wodurch die Sektorgröße plötzlich sehr, sehr
seltsam ist. Das ist auch der Hauptgrund, warum ECB und selbst
erfundene CBC-Varianten in dem Bereich so beliebt ist.

Ich glaube auch nicht, daß CTR für Festplattenverschlüsselung direkt
einsetzbar ist, weil man jedes Mal, wenn man einen Sektor
überschreibt, den Counter wechseln muß.

[Christian Thöing]

Post by Florian Weimer
Festplatten haben keine wahlfreien Zugriff, bloß einen
sektorweisen. 8-)

OK, stimmt schon... Wahlfreier Zugriff ist im Prinzip aber auch bei CBC
etc. möglich, wenn der letzte Chiffretextblock bzw. IV gelesen wird.

Post by Florian Weimer
Das Problem bei CBC & Co. ist, daß man den IV
irgendwie speichern muß, wodurch die Sektorgröße plötzlich sehr, sehr
seltsam ist. Das ist auch der Hauptgrund, warum ECB und selbst
erfundene CBC-Varianten in dem Bereich so beliebt ist.

ACK, die IVs müssen natürlich separat gespeichert werden. Das ist nun
mal ein Zugeständnis an die Chiffrierung...

Post by Florian Weimer
Ich glaube auch nicht, daß CTR für Festplattenverschlüsselung direkt
einsetzbar ist, weil man jedes Mal, wenn man einen Sektor
überschreibt, den Counter wechseln muß.

Ja nun, IVs müssen in sämtlichen Modi außer ECB gewählt werden. Das
lässt sich nicht ändern. Ich würde statt CTR/OFB aber eher CBC/CFB
einsetzen (auch bei Verschlüsselungs-Programmen wie Scramdisk und
TrueCrypt), sofern es möglich ist. CTR eignet sich IMHO eher für
Pseudozufallsgeneratoren.

[Ralf Muschall]

Post by Christian Thöing
Nein, der Counter muss keineswegs "wüst" sein, sondern kann aus einer
simplen Operation (wie n=n+1) bestehen. Chiffrierungen im OFB- und
Counter-Modus erzeugen einen pseudozufälligen Zeichenstrom (d.h. die
Blockchiffre verhält sich wie ein PRNG), völlig unabhängig vom Klartext.
Das Problem ist nun, dass die eigentliche Verschlüsselung,
nämlich die XOR-Verknüpfung mit dem Klartext, linear ist.

Bis hierher ist es eine ordinäre Stromchiffre. Dass das XOR linear
ist, ist erstmal egal (wenn man es beachtet und keine
Implementationsfehler macht).

Post by Christian Thöing
ausnutzen). Mit differenzieller oder linearer Kryptoanalyse hat das,
CMIIW, nichts zu tun; ganz beiseite,

Doch: Ich verschlüssle die natürlichen Zahlen mit einem konstanten Key.
Mit known-plaintext hat der Angreifer dann Input und Output des AES (o.ä.)
für viele Inputs, die sich in wenigen Bits unterscheiden, d.h. das ideale
Futter für genannte Verfahren.

Post by Christian Thöing
dass die meisten modernen Verfahren à la Blowfish und AES ohnehin
resistent gegen diese Art von Angriffen sind.

Erst das ist die eigentliche Rettung.

Lieber wäre mir eine Primzahl p knapp unter 2^256 und ein Generator g
der Restklassen % p, um mittels Counter:=g^laufende_Nummer % p eine
reproduzierbare wüste Permutation zu bekommen (dass man Null und die
letzten paar nicht durchläuft, sollte nur bei langen zu
transportierenden Files eine Rolle spielen ;-)).

Post by Christian Thöing
CTR hat allerdings den Vorteil, dass 1. sich der Schlüsselstrom im
Voraus berechnen lässt

Das haben alle reinen Stromchiffren. Der Vorteil des Missbrauchs von
Blockchiffren hierzu ist der, dass man Block N in O(1) statt O(N)
Schritten bekommt (und dadurch parallelisierbar wird). Der Nachteil
ist der, dass man auf Resistenz gegenüber Angriffen angewiesen ist,
die man erstmal nicht vermutet; und dass man für jeden Datenblock von
neuem den ganzen Feistel durchmacht (Stromchiffren variieren in jedem
Schritt einen kleinen Anteil eines großen Zustandes).

Ralf

[Andreas Beck]

Post by Ralf Muschall

Post by Christian Thöing
Das Problem ist nun, dass die eigentliche Verschlüsselung,
nämlich die XOR-Verknüpfung mit dem Klartext, linear ist.

Bis hierher ist es eine ordinäre Stromchiffre. Dass das XOR linear
ist, ist erstmal egal (wenn man es beachtet und keine
Implementationsfehler macht).

IMHO: Nein. Es ermöglicht in der naiven Anwendung als
Blockdevice-Verschlüsseler verschiedene Angriffe.

Zum einen kann man gezielt Bits umkippen. Ohne Integritätssicherung
merkt man das nicht und arbeitet u.U. nachher mit manipulierten Dateien.

Zum anderen genügt es, einmal einen Sektor mit known plaintext zu
haben, um denselben Sektor für alle Zukunft lesen zu können.

Bei einer datenabhängigen Verkettungsmethode wird sich dieser Angriff in
der Regel auf den ersten Block des Sektor beschränken.


CU, Andy

[Christian Thöing]

Post by Ralf Muschall
Bis hierher ist es eine ordinäre Stromchiffre. Dass das XOR linear
ist, ist erstmal egal (wenn man es beachtet und keine
Implementationsfehler macht).

Es ist ja insofern nicht egal, als XOR-Verknüpfung immer linear ist.
Ohne Integritätsprüfung lassen sich also beliebig Bits verändern. Und
wenn die Prüfung -- z.B. durch CRC -- selbst linear ist, kann die
Nachricht leicht manipuliert werden, ohne dass es der Empfänger bemerken
würde (Beispiel WEP).

Post by Ralf Muschall
Doch: Ich verschlüssle die natürlichen Zahlen mit einem konstanten Key.
Mit known-plaintext hat der Angreifer dann Input und Output des AES (o.ä.)
für viele Inputs, die sich in wenigen Bits unterscheiden, d.h. das ideale
Futter für genannte Verfahren.

Das ist richtig, nur sind moderne Verfahren gegen diese Form der
Kryptoanalyse resistent. Wären sie es nicht, würde man sie überhaupt
nicht erst einsetzen.

Post by Ralf Muschall

Post by Christian Thöing
dass die meisten modernen Verfahren à la Blowfish und AES ohnehin
resistent gegen diese Art von Angriffen sind.

Erst das ist die eigentliche Rettung.

Jedes halbwegs sichere Verfahren ist gegen differenzielle und lineare
Analyse gefeit. Bei Blowfish z.B. sind die Angriffe völlig wirkungslos,
weil das Verfahren geheime S-Boxen verwendet.

Post by Ralf Muschall
Lieber wäre mir eine Primzahl p knapp unter 2^256 und ein Generator g
der Restklassen % p, um mittels Counter:=g^laufende_Nummer % p eine
reproduzierbare wüste Permutation zu bekommen (dass man Null und die
letzten paar nicht durchläuft, sollte nur bei langen zu
transportierenden Files eine Rolle spielen ;-)).

Das wäre vielleicht eine nette Zugabe, ist aber schlicht nicht nötig,
zumal es die Performance schmälert. n=n+1 reicht wohl für die als sicher
geltenden Verfahren aus.

Post by Ralf Muschall
Das haben alle reinen Stromchiffren. Der Vorteil des Missbrauchs von
Blockchiffren hierzu ist der, dass man Block N in O(1) statt O(N)
Schritten bekommt (und dadurch parallelisierbar wird).

Genau.

Post by Ralf Muschall
Der Nachteil
ist der, dass man auf Resistenz gegenüber Angriffen angewiesen ist,
die man erstmal nicht vermutet;

Prinzipiell ACK, nur sollte das einen nicht dazu verleiten,
Stromchiffren im Allgemeinen mehr zu trauen. Stromchiffren sind zwar
sehr, sehr schnell, aber, wie die Erfahrung gezeigt hat, oft viel
anfälliger für Angriffe als Blockchiffren, die, nebenbei bemerkt,
weitaus flexibler sind. Ich würde jedenfalls eher eine sichere
Blockchiffrierung im CTR/OFB-Modus anwenden als RC4 oder SEAL. Gibt es
überhaupt eine Stromchiffrierung, die sicherheitstechnisch einen
ähnlichen Status genießt wie Triple-DES, Blowfish, IDEA oder AES (und
schneller ist)?

[Markus Meier]

Post by Lutz Donnerhacke

Post by Gunther Kral
Wofür steht ECB?

Electronic CodeBook mode.

Dabei werden die unverschlüsselten Daten in gleich große Blöcke
unterteilt, wobei dann jeder Block für sich unabhängig von den anderen
verschlüsselt wird.

Sind 2 Blöcke im Klartext identisch, so sind nach einer Verschlüsselung
im ECB-Modus auch die chiffrierten Blöcke identisch - was natürlich ein
Sicherheitsrisiko darstellt.

Markus

[Florian Weimer]

Post by Gunther Kral

Post by Florian Weimer

Post by Gunther Kral
Welche Bedeutung hat die Blocklänge bei Verschlüsselung?

Wenn man unbedingt den ECB-Modus verwenden muß (was man meist
krampfhaft zu vermeiden versucht), erschwert eine höhere Blocklänge
den typischen Angriff, bei dem versucht wird, Teile des Codebuchs zu
rekonstruieren.

Wofür steht ECB?

Für einen Betriebsmodus für Block-Chiffrierverfahren. Der Klartext
wird dabei in Blücke entsprechend der Blockgröße des
Chiffrierverfahrens eingeteilt. Alle Blöcke werden völlig unabhängig
voneinander verschlüsselt, insbesondere werden Blöcke mit gleichem
Inhalt immer gleich verschlüsselt, was auch das größte Problem
darstellt.

[Vinzent 'Gadget' Hoefler]

Post by Florian Weimer
Alle Blöcke werden völlig unabhängig
voneinander verschlüsselt, insbesondere werden Blöcke mit gleichem
Inhalt immer gleich verschlüsselt, was auch das größte Problem
darstellt.

Wie sind dabei eigentlich Varianten zu beurteilen, die das Problem
dadurch minimieren, dass sie Klartext-Daten in kleinere Bloecke (z.B.
224 statt 256 Bit) aufteilen und dann vor der Verschluesselung des
Blocks entsprechend viele (Pseudo-)Zufallsbits einschieben?


Vinzent.

[Florian Weimer]

Post by Vinzent 'Gadget' Hoefler

Post by Florian Weimer
Alle Blöcke werden völlig unabhängig
voneinander verschlüsselt, insbesondere werden Blöcke mit gleichem
Inhalt immer gleich verschlüsselt, was auch das größte Problem
darstellt.

Wie sind dabei eigentlich Varianten zu beurteilen, die das Problem
dadurch minimieren, dass sie Klartext-Daten in kleinere Bloecke (z.B.
224 statt 256 Bit) aufteilen und dann vor der Verschluesselung des
Blocks entsprechend viele (Pseudo-)Zufallsbits einschieben?

Verfahren, die die zuverschlüsselnden Daten in dieser Weise aufblähen,
sind nicht besonders praxisrelevant und werden daher auch eher selten
untersucht.

[Vinzent 'Gadget' Hoefler]

Post by Florian Weimer

Post by Vinzent 'Gadget' Hoefler
Wie sind dabei eigentlich Varianten zu beurteilen, die das Problem
dadurch minimieren, dass sie Klartext-Daten in kleinere Bloecke (z.B.
224 statt 256 Bit) aufteilen und dann vor der Verschluesselung des
Blocks entsprechend viele (Pseudo-)Zufallsbits einschieben?

Verfahren, die die zuverschlüsselnden Daten in dieser Weise aufblähen,
sind nicht besonders praxisrelevant und werden daher auch eher selten
untersucht.

Schade. Ich hab' so was aehnliches naemlich durchaus schon verwendet.
Mich haette mal interessiert, inwiefern das eine dumme Idee war. ;-)


Vinzent.

[Richard W. Könning]

Post by Vinzent 'Gadget' Hoefler

Post by Florian Weimer

Post by Vinzent 'Gadget' Hoefler
Wie sind dabei eigentlich Varianten zu beurteilen, die das Problem
dadurch minimieren, dass sie Klartext-Daten in kleinere Bloecke (z.B.
224 statt 256 Bit) aufteilen und dann vor der Verschluesselung des
Blocks entsprechend viele (Pseudo-)Zufallsbits einschieben?

Verfahren, die die zuverschlüsselnden Daten in dieser Weise aufblähen,
sind nicht besonders praxisrelevant und werden daher auch eher selten
untersucht.

Schade. Ich hab' so was aehnliches naemlich durchaus schon verwendet.
Mich haette mal interessiert, inwiefern das eine dumme Idee war. ;-)

Weil es Verfahren gibt, die eine mindestens vergleichbare Sicherheit
bieten und ohne Aufblähung auskommen?
Ciao,
Richard

[Markus L. Dechert]

Hallo Vinzent,

Post by Vinzent 'Gadget' Hoefler

Post by Florian Weimer
Alle Blöcke werden völlig unabhängig
voneinander verschlüsselt, insbesondere werden Blöcke mit gleichem
Inhalt immer gleich verschlüsselt, was auch das größte Problem
darstellt.

Wie sind dabei eigentlich Varianten zu beurteilen, die das Problem
dadurch minimieren, dass sie Klartext-Daten in kleinere Bloecke (z.B.
224 statt 256 Bit) aufteilen und dann vor der Verschluesselung des
Blocks entsprechend viele (Pseudo-)Zufallsbits einschieben?

gute Frage. Ich denke, das bringt gar nichts.
Zwar müssen die Bits pro Block von der Chiffre vollständig durchmengt
werden und so alle Bits paarweise aufeinander Einfluss haben - die
Voraussetzungen für einen geeigneten RNG usw. sind ja klar! - jedoch
denke ich sind die Probleme überwiegend.

Als Nachteil gegenüber den übringen Betriebsmodi würde ich ganz klar
sehen, dass du hier nicht die volle Bandbreite ausnutzen kannst. Als
weiteren Nachteil sollte man in Betracht ziehen, dass die Randomisierung
an einer festen Stelle im Klartextblock erfolgen muss, das könnte für
differentielle Attacken vielleicht eine Schwachstelle darstellen.
Als Hauptproblem sehe ich: Wie kommt der Dechiffrierer an die
Zufallszahlenfolge? Wenn ich die auf einem anderen Kanal getrennt
übertrage, dann habe ich sowas wie ein One-Time-Pad für Arme oder eine
schlichte Schlüsselverlängerung, wenn ich sie auf dem selben Kanal
übertrage, kennt der Angreifer sogar noch einen Teil des Klartextes zum
abgefangenen Chiffretext.

Ergo: Die verwendete Zufallszahlenfolge ist nichts weiter als eine
(unnötige) Verlängerung des Schlüssels, die jedoch Angriffspunkte im
Chiffre schafft und mehr Chiffretext aus weniger Klartext produziert.
Die Chiffre wäre damit eine Dekompressionsfunktion.

Post by Vinzent 'Gadget' Hoefler
Vinzent.

Gruß
Markus

[Martin Vaeth]

Post by Markus L. Dechert

Post by Vinzent 'Gadget' Hoefler
Wie sind dabei eigentlich Varianten zu beurteilen, die das Problem
dadurch minimieren, dass sie Klartext-Daten in kleinere Bloecke (z.B.
224 statt 256 Bit) aufteilen und dann vor der Verschluesselung des
Blocks entsprechend viele (Pseudo-)Zufallsbits einschieben?

gute Frage. Ich denke, das bringt gar nichts.

Da bin ich anderer Ansicht, aber anscheinend hast Du den Vorschlag
anders verstanden als ich. (Ev. hast Du übersehen, dass Vinzent
"*vor* der der Verschluesselung" schrieb?)

Post by Markus L. Dechert
Als Nachteil gegenüber den übringen Betriebsmodi würde ich ganz klar
sehen, dass du hier nicht die volle Bandbreite ausnutzen kannst.

ACK. Aber das ist auch der einzige Nachteil.
Der ist natürlich manchmal sehr störend: Z.B. ist es dann in den
meisten Betriebssystemen wesentlich aufwendiger eine Verschlüsselung
einer Partition zu implementieren (da man ja dann auf die "tatsächlichen"
Blockadressen "remappen" muss) - das ist allerdings eher ein Problem
der Betriebs/Filesysteme, die für so etwas halt nicht ausgelegt sind.
In anderen Situationen (z.B. beim Archivieren sensibler Daten) ist
der Datenzuwachs weniger unangenehm und man behält den großen Vorteil
von ECB, dass bei Beschädigungen des Archivs in einem Block auch
tatsächlich nur dieser Block verlorengeht.

Post by Markus L. Dechert
Als weiteren Nachteil sollte man in Betracht ziehen, dass die
Randomisierung an einer festen Stelle im Klartextblock erfolgen muss,
das könnte für differentielle Attacken vielleicht eine Schwachstelle
darstellen.

Nur wenn der Algorithmus anfällig ist gegenüber einer ganz bestimmten
Klasse von "partly known plaintext"-Attacken. Aber auch das könnte
man nochmals minimieren, indem man auch die Stellen auswürfelt, wo
Zufallsbytes eingestreut werden (und diese Stellen natürlich nach
einem bestimmten Schema mitabspeichert) - es ist dann *sehr*
unwahrscheinlich, dass der benutzte Algorithmus gerade für des
gewählte Schema besonders anfällig ist. Und schlechter als reines
ECB kann das keinesfalls sein.

Post by Markus L. Dechert
Als Hauptproblem sehe ich: Wie kommt der Dechiffrierer an die
Zufallszahlenfolge?

??? Offensichtlich hast Du den Vorschlag anders verstanden als ich:
Der Dechiffrierer muss die doch nicht wissen, die steht doch dann
einfach in den dechiffrierten Daten und kann ignoriert werden.

[Markus L. Dechert]

Hallo Martin,

[snip]

Post by Martin Vaeth

Post by Markus L. Dechert
Als Nachteil gegenüber den übringen Betriebsmodi würde ich ganz klar
sehen, dass du hier nicht die volle Bandbreite ausnutzen kannst.

ACK. Aber das ist auch der einzige Nachteil.

[snip]

Post by Martin Vaeth
In anderen Situationen (z.B. beim Archivieren sensibler Daten) ist
der Datenzuwachs weniger unangenehm

doch, weil unnötig.

Dabei kommt mir eine Frage: Richtige Zufallsdaten haben ja die höchste
Entropie. Wie ist das denn, wenn ich nun wirklich dem Klartext solche
Zufallszahlen hinzumische, das Ganze dann verschlüssele und dann
Komprimiere? Also ist das Resultat von n Byte zufälliger,
verschlüsselter und komprimierter Daten bytemäßig größer als das von n
Byte nicht-zufälliger (z.B. ein Programm, Text oder eine Media-Datei),
verschlüsselter und komprimierter?

Post by Martin Vaeth
und man behält den großen Vorteil
von ECB, dass bei Beschädigungen des Archivs in einem Block auch
tatsächlich nur dieser Block verlorengeht.

Wenn ich eine Blockgröße von 128 Byte oder 256 Byte habe, dann kann ich
*praktisch* auch den CBC verwenden. Hier habe ich den Vorteil, dass die
Blöcke vom jeweiligen Vorgänger abhängen und mir bei Beschädigung eines
Blockes auch nur ein viertel/halbes KByte im Ggs. zu einem
achtel/viertel KByte flöten geht. Das investiere ich doch gerne für das
Plus an Resistenz.

Post by Martin Vaeth

Post by Markus L. Dechert
Als weiteren Nachteil sollte man in Betracht ziehen, dass die
Randomisierung an einer festen Stelle im Klartextblock erfolgen muss,
das könnte für differentielle Attacken vielleicht eine Schwachstelle
darstellen.

Nur wenn der Algorithmus anfällig ist gegenüber einer ganz bestimmten
Klasse von "partly known plaintext"-Attacken. Aber auch das könnte
man nochmals minimieren, indem man auch die Stellen auswürfelt, wo
Zufallsbytes eingestreut werden (und diese Stellen natürlich nach
einem bestimmten Schema mitabspeichert) - es ist dann *sehr*
unwahrscheinlich, dass der benutzte Algorithmus gerade für des
gewählte Schema besonders anfällig ist. Und schlechter als reines
ECB kann das keinesfalls sein.

ACK. (s.u.)

Post by Martin Vaeth

Post by Markus L. Dechert
Als Hauptproblem sehe ich: Wie kommt der Dechiffrierer an die
Zufallszahlenfolge?

Der Dechiffrierer muss die doch nicht wissen, die steht doch dann
einfach in den dechiffrierten Daten und kann ignoriert werden.

*klatsch* (gegen die Stirn hau)
Logisch, hab mir wohl einen Knoten ins Hirn gemacht ;-) Danke.

Damit reduzieren sich die Nachteile in der Tat auf den des
Chiffretext-Overheads.

Gruß
Markus

[Martin Vaeth]

Post by Markus L. Dechert

Post by Martin Vaeth
In anderen Situationen (z.B. beim Archivieren sensibler Daten) ist
der Datenzuwachs weniger unangenehm

doch, weil unnötig.

Jein: Man kauft sich mit dem Zuwachs halt auch Vorteile ein
(Das Verhältnis muss man natürlich abwägen): Will man mehr
Versicherung gegen Datenverlust oder lieber sparsamer speichern?

Post by Markus L. Dechert
Wenn ich eine Blockgröße von 128 Byte oder 256 Byte habe, dann kann ich
*praktisch* auch den CBC verwenden.

Nebenbei bemerkt scheint mir der Zufallszahlen-Ansatz irgendwie
"sicherer" zu sein als CBC. Er ist eher vergleichbar mit dem Mode,
der die *unverschlüsselten* Daten des vorherigen Blocks benutzt
(hat dieser Mode einen Standard-Namen?) - bei diesem Mode wäre
natürlich die Beschädigung eines einzigen Blocks fatal.

Post by Markus L. Dechert
Dabei kommt mir eine Frage: Richtige Zufallsdaten haben ja die höchste
Entropie. Wie ist das denn, wenn ich nun wirklich dem Klartext solche
Zufallszahlen hinzumische, das Ganze dann verschlüssele und dann
Komprimiere? Also ist das Resultat von n Byte zufälliger,
verschlüsselter und komprimierter Daten bytemäßig größer als das von n
Byte nicht-zufälliger (z.B. ein Programm, Text oder eine Media-Datei),
verschlüsselter und komprimierter?

Die Daten mit den Zufallsbits sollten tatsächlich eine höhere
Kolmogorov-Komplexität besitzen. "Praktisch" lassen sich
verschlüsselte Daten aber ohnehin nicht komprimieren.

[Andreas Beck]

Post by Vinzent 'Gadget' Hoefler

Post by Florian Weimer
Alle Blöcke werden völlig unabhängig
voneinander verschlüsselt, insbesondere werden Blöcke mit gleichem
Inhalt immer gleich verschlüsselt, was auch das größte Problem
darstellt.

Wie sind dabei eigentlich Varianten zu beurteilen, die das Problem
dadurch minimieren, dass sie Klartext-Daten in kleinere Bloecke (z.B.
224 statt 256 Bit) aufteilen und dann vor der Verschluesselung des
Blocks entsprechend viele (Pseudo-)Zufallsbits einschieben?

Als Quark. Man bläht den Nutzdatenstrom auf, braucht halbwegs brauchbare
(Pseudo-)Zufallsbits (weil man sonst dauernd partial-known-plaintext hat)
und hat einen Tradeoff zwischen der Anzahl der "Salt"-Bits und der
Aufblähung. Zu wenige Salt-Bits vergrößern halt nur die Tabellen
entsprechend.

Eher unübliche Sache, das.

[Martin Vaeth]

Post by Andreas Beck

Post by Vinzent 'Gadget' Hoefler
Wie sind dabei eigentlich Varianten zu beurteilen, die das Problem
dadurch minimieren, dass sie Klartext-Daten in kleinere Bloecke (z.B.
224 statt 256 Bit) aufteilen und dann vor der Verschluesselung des
Blocks entsprechend viele (Pseudo-)Zufallsbits einschieben?

Als Quark. Man bläht den Nutzdatenstrom auf, braucht halbwegs brauchbare
(Pseudo-)Zufallsbits (weil man sonst dauernd partial-known-plaintext hat)

Ja, brauchbare Zufallsbits braucht man - aber das ist hier wohl
kein wesentliches Problem, da man für deren Generierung neben
den existierenden starken Zufallszahlen-Generatoren (oder gar
"echten" Zufallsquellen) vor allem auch die Plain-Daten des letzten
Blocks benutzen könnte (wenn man so will, wäre das dann ein Zwitter
mit CBC-Mode, aber ohne dessen Nachteile bei Datenverlusten).

Post by Andreas Beck
und hat einen Tradeoff zwischen der Anzahl der "Salt"-Bits und der
Aufblähung.

Klar. Abwägen muss man immer.

[Markus L. Dechert]

[snip]

Post by Gunther Kral
Wofür steht ECB?

Wie schon geschrieben für Electronic CodeBook Mode. Das kann man sich
auch bildlich so vorstellen, dass einer in einem Kodebuch nachschlägt so
dass ein Block im Klartext immer in denselben Block im Chiffretext
resultiert.

[snip]

Post by Gunther Kral
Welche Verschlüsselungsverfahren verwenden einen ECB-Modus?

Du kannst im Allgemeinen alle symmetrischen Verschlüsselungsverfahren in
verschiedenen Betriebsmodi betreiben. Die haben natürlich ihre Vor- und
Nachteile. Gebräuchlich sind der ECB für Leute, die keine Ahnung haben,
oder wenn es wirklich sein muss, sowie der CBC (CipherBlock Chaining
Mode), der CFB (Cipher FeedBack Mode) und der OFB (Output Feedback Mode).
Am Besten veranschaulicht man sich das an Blockdiagrammen. Eine gute
Übersicht findet man aber im Handbook of Applied Cryptography als
OpenBook unter
http://www.cacr.math.uwaterloo.ca/hac/
Kapitel 7, S. 228ff (besonders die Blockdiagramme auf S. 229 sind hier
sehr gut).
Johannes Buchmann hat in seiner "Einführung in die Kryptographie"
(Springer Verlag) zwar die gleichen Diagramme, aber eine etwas
kompaktere (und deutsche) Erklärung.

Post by Gunther Kral
Gruss, Gunther

Gruß
Markus

[Richard W. Könning]

Post by Gunther Kral
Welche Verschlüsselungsverfahren verwenden einen ECB-Modus?

Schlechte ;-). Ich zitiere aus Ferguson/Schneier: "Practical
Cryptography", p. 69:

|Do not ever use ECB for anything. It has serious weaknesses, and
|is only included here so that we can warn you away from it.
Ciao,
Richard