Hi
InitVector kannst nil übergeben. Allerdings wird dann intern dieser als $FFFFFFF...FFFFF angenommen. Dies kann sich von Tool zu Tool unterscheiden. Es ist also besser bei beiden Tools den gleichen IV explizit zu übergeben.
DCPCrypt und
DEC sind soweit kompatibel, wenn man in beiden Tools auch die gleichen Daten, Initialisierungen, Modis usw. benutzt.
Zitat:
Ein spezielles Problem bleibt aber bestehen: Twofich in der offizielle
DEC Part 3 Version hat einen klitzekleinen Bug im KeySetup.
Das heißt?
Das der Twofish im
DEC ein anderes KeySetup besitzt und somit immer anders arbeitet
Überschreibe im KeySetup die Funktion F32() mit nachfolgender:
Delphi-Quellcode:
function F32(X: Integer; K:
array of Integer): Integer;
var
A, B, C, D: LongWord;
begin
A := X
and $FF;
B := X
shr 8
and $FF;
C := X
shr 16
and $FF;
D := X
shr 24;
if Size = 32
then
begin
A := Twofish_8x8[1, A]
xor K[3]
and $FF;
B := Twofish_8x8[0, B]
xor K[3]
shr 8
and $FF;
C := Twofish_8x8[0, C]
xor K[3]
shr 16
and $FF;
D := Twofish_8x8[1, D]
xor K[3]
shr 24;
end;
if Size >= 24
then
begin
A := Twofish_8x8[1, A]
xor K[2]
and $FF;
B := Twofish_8x8[1, B]
xor K[2]
shr 8
and $FF;
C := Twofish_8x8[0, C]
xor K[2]
shr 16
and $FF;
D := Twofish_8x8[0, D]
xor K[2]
shr 24;
end;
A := Twofish_8x8[0, A]
xor K[1]
and $FF;
B := Twofish_8x8[1, B]
xor K[1]
shr 8
and $FF;
C := Twofish_8x8[0, C]
xor K[1]
shr 16
and $FF;
D := Twofish_8x8[1, D]
xor K[1]
shr 24;
A := Twofish_8x8[0, A]
xor K[0]
and $FF;
B := Twofish_8x8[0, B]
xor K[0]
shr 8
and $FF;
C := Twofish_8x8[1, C]
xor K[0]
shr 16
and $FF;
D := Twofish_8x8[1, D]
xor K[0]
shr 24;
Result := Twofish_Data[0, A]
xor Twofish_Data[1, B]
xor
Twofish_Data[2, C]
xor Twofish_Data[3, D];
end;
var
I,J,A,B: Integer;
E,O:
array[0..3]
of Integer;
K:
array[0..7]
of Integer;
begin
FillChar(K, SizeOf(K), 0);
Move(Key, K, Size);
if Size <= 16
then Size := 16
else
if Size <= 24
then Size := 24
else Size := 32;
J := Size
shr 3 - 1;
for I := 0
to J
do
begin
E[I] := K[I
shl 1];
O[I] := K[I
shl 1 + 1];
BoxKey[J].L := Encode(E[I], O[I]);
Dec(J);
end;
J := 0;
for I := 0
to 19
do
begin
A := F32(J, E);
B := F32(J + $01010101, O);
B := B
shl 8
or B
shr 24;
SubKey[I
shl 1] := A + B;
B := A + B
shl 1;
// here buggy instead shr 1 it is correct shl 1
SubKey[I
shl 1 + 1] := B
shl 9
or B
shr 23;
Inc(J, $02020202);
end;
end;
Zitat:
negaH hat folgendes geschrieben:
DEC benutzt standardmäßig dem Cipher.Mode := cmCTS. cmCTS ist eine Entwicklung von mir, die sicherer als der Standard cmCBC ist. Ein fast identisches Verfahren wie mein CTS wurde in der AES Ausschreibung von Belgischen Cryptoexperten als Ersatz für CBC vorgeschlagen. Da aber CTS kein offizieller Standard ist (wobei es eigentlich bis heute überhaupt keinen offiziellen Standard gibt ) kann DCPCrypt oder andere Tools garnicht kompatibel zum
DEC sein.
Ohne die Umstellung des Modus? Oder generell nicht?
Ohne Umstellung dieses Modis, ansonsten kompatibel.
Zitat:
1. Sollte bei Twofish 256bit sein oder nicht?
8. Von Stream zu Stream gibts keine Formatierung oder doch?
Twofish kann verschiedene Schlüssellängen benutzen. 128, 192 und 256 Bit.
DEC nimmt abhängig von der übergebenen Schlüssellänge den entsprechenden Modus.
Zitat:
Was bewirkt die Änderung des Modis überhaupt?
Init Vector, Padding Schemata z.b. Sagt mir rein gar nix, für was soll das beides gut sein
Hmmmm, die meisten Cipher sind Block-verschlüsselungen. D.h. die Nachricht wird in einzelne kurze Datenblöcke zerlegt, zb. 8,16,32 oder 64 Bytes. Dann wird die Verschlüsselungsfunktion auf diese Blöcke angewendet. Nun der Cipher Modus bestimmt wie die einzelnen Blöcke vor und nach der Verschlüsselung untereinander verknüpft werden. Der ECB Mode zb. verknüpft diese Blöcke überhaupt nicht untereinander, deshalb sollte man diesen Modus nicht in real benutzen. Die meisten anderen Modis benutzen ein zusätzliches Feedback Register. Der Anfangswert in diesem Register wird durch den IV=InitVector bestimmt und sollte zufällig sein. Natürlich muß man dann aber auch dieses Zufallsmuster mit in die Daten speichern damit man korrekt entschlüsseln kann.
Es gibt aber nun Nachrichten die nicht ein Vielfaches der Blockgröße in der Länge sind. Bei solchen Nachrichten wird also der letzte Block unvollständig und somit falsch verschlüsselt. Denn damit der Verschl. Algo. arbeiten kann benötig er ja einen kompletten Datenblock mit 6,16,32 oder 64 Bytes. In diesem Moment kommt das Padding zum Tragen, also das Auffüllen der fehldenen Bytes nach einem bestimmten Muster. Dieses Paddingist nichtwirklich standardisiert.
DEC benutzt zudem ein ganz spezielles "Padding", den Cipher Text Stealing. Dabei wird der letzte Block so verschlüsselt das er eben NICHT gepaddet werden muß, und somit die Länge der verschlüsselten Daten identisch zu der Länge der unverschlüsselten Nachricht ist.
Zitat:
Vielleicht kannst du ein Buch empfehlen, so als quasi Crypto-Experte möglichst Deutsch
siehe vorheriges Posting, schließe mich dieser Empfehlung voll und ganz an.
Gruß hagen