Entschlüsseln einer Datei (DEC) mit Java problematisch

[Eldarion]

Hallo Klaus,

ich denke es ist Rijndael mit cmCBCx. Habe diese Codezeile bei der Verschlüsselung gefunden:

var
ACipherClass: TDECCipherClass = TCipher_Rijndael;
ACipherMode: TCipherMode = cmCBCx;
AHashClass: TDECHashClass = THash_Whirlpool;
ATextFormat: TDECFormatClass = TFormat_Mime64;
AKDFIndex: LongWord = 1;

Hilft das weiter?

[gammatester]

Ist eine der berühmt/berüchtigten proprietären Verschlüsselungsmethoden:

cmCBCx = Cipher Block Chainung, with CFB8 padding of truncated final block

Das muss dementsprechend in Java nachgebildet werden; bzw. wenn Du ohne einen letzten unvollständigen Block leben kannst, schneide den Schüsseltext auf Vielfache von 16 Bytes ab und benutze Standard-CBC.

[Deep-Sea]

cmCBCx = RBT?

[gammatester]

Zitat von Deep-Sea:

cmCBCx = RBT?

Nein. Wie am Quellcode sieht, wird wirklich für die restlichen Bytes CFB8 benutzt.

Delphi-Quellcode:

  procedure EncodeCBCx(S,D: PByteArray; Size: Integer);
  var
    F: PByteArray;
    I: Integer;
  begin
    Dec(Size, FBufferSize);
    F := FFeedback;
    I := 0;
    while I <= Size do
    begin
      XORBuffers(S[I], F[0], FBufferSize, D[I]);
      F := @D[I];
      DoEncode(F, F, FBufferSize);
      Inc(I, FBufferSize);
    end;
    if F <> FFeedback then
      Move(F[0], FFeedback[0], FBufferSize);
    Dec(Size, I - FBufferSize);
    if Size > 0 then
    begin  // padding
      EncodeCFB8(@S[I], @D[I], Size);
      FState := csPadded;
    end else FState := csEncode;
  end;

[Deep-Sea]

Zitat von gammatester:

Nein. Wie am Quellcode sieht, wird wirklich für die restlichen Bytes CFB8 benutzt.

RBT fällt auf CFB zurück, auch wenn es in der Wikipedia nicht so offensichtlich da steht.
(Auf was bezieht sich die "8" von CFB8? Darauf, das es Byte- und nicht Bitweise arbeitet?)

[Eldarion]

Seh ich eigmentlich richtig, dass Standardmäßig im cmCTSx Modus geschrieben wird?

Ich denke ich habs jetzt soweit verstanden, dass nur noch CBCx richtig implementiert werden muss (Delphi-Seite) und dann die Java-Seite dran kommt. Denn da muss ich dann die Datei analysieren und auseinander nehmen.

[gammatester]

Zitat von Deep-Sea:

Zitat von gammatester:

Nein. Wie am Quellcode sieht, wird wirklich für die restlichen Bytes CFB8 benutzt.

RBT fällt auf CFB zurück, auch wenn es in der Wikipedia nicht so offensichtlich da steht.
(Auf was bezieht sich die "8" von CFB8? Darauf, das es Byte- und nicht Bitweise arbeitet?)

Das kann aber nicht sein:

* Encrypt the ⌊N/L⌋ full blocks of plaintext using the cipher block chaining mode
* Encrypt the last full encrypted block again;
* XOR the remaining bits of the plaintext with leftmost bits of the re-encrypted block.

Wenn Du im letzen Teil zb 11 Bytes hast, wird bei CFB8 das 11-te Byte abhängig von den vorherigen 10 Bytes via Feedback behandelt. Das ist dem zitierten RBT nicht der Fall. (Eventuell bei CFB<Blocksize> also bei AES/CFB128).

(CFB8 sollte mit 8 Feedback-Bits arbeiten, CFB1 mit einem, CFB mit einem ganzen Block, aber die Bezeichnungen sind wohl nicht eindeutig)

[Deep-Sea]

Zitat von gammatester:

(CFB8 sollte mit 8 Feedback-Bits arbeiten, CFB1 mit einem, CFB mit einem ganzen Block, aber die Bezeichnungen sind wohl nicht eindeutig)

Achso, ja darum fragte ich ja auch gerade, wofür die 8 steht. Kenne das DEC ja nicht - wenn dem also so ist, hast du natürlich recht. Dann wäre RBT nur gleichbedeutend mit CBCx, wenn auf CFB und nicht auf CFB8 zurückgegriffen würde ...

[Eldarion]

Zitat von gammatester:

Ist eine der berühmt/berüchtigten proprietären Verschlüsselungsmethoden:

cmCBCx = Cipher Block Chainung, with CFB8 padding of truncated final block

Das muss dementsprechend in Java nachgebildet werden; bzw. wenn Du ohne einen letzten unvollständigen Block leben kannst, schneide den Schüsseltext auf Vielfache von 16 Bytes ab und benutze Standard-CBC.

Was genau meinst du mit: wenn ich ohne einen letzten unvollständigen Block leben kann? Ich kenn leider auch die Verschlüsselungen nicht, also verstehe ich NOCH Bahnhof

Schlag mich grad mit der Cipher API von Java rum. Gibts da nicht schon was fertiges?

Und wenn ich es richtig sehe, dann wird ja das Passwort mit KDFx verschlüsselt und vorne in die Datei geschrieben. Benötige ich diese Information dann überhaupt, wenn ich das Passwort eh schon kenne?

Also ich kann mir gerade auch noch nicht den Aufbau einer solch verschlüsselten Datei vorstellen. Läuft das dann in etwa so:
/Modus/ /Passwort/ /Der Seed mit dem das Passwort verschlüsselt ist/ /Der verschlüsselte Inhalt/

Oder steht zum Schluss nur der verschlüsselte Inhalt in der Datei?

*Edit: Ich füge euch mal den Quellcode an der Verschlüsselung. Vielleicht hilft der ja weiter.

Delphi-Quellcode:

 var 
  ACipherClass: TDECCipherClass = TCipher_Rijndael;
  ACipherMode: TCipherMode      = cmCBCx;
  AHashClass: TDECHashClass     = THash_Whirlpool;
  ATextFormat: TDECFormatClass  = TFormat_Mime64;
  AKDFIndex: LongWord           = 1;

function ZipEncodeFileStream(const AFileStream: TMemoryStream; const APassword: Binary;
                             ACipher: TDECCipherClass = nil; AMode: TCipherMode = cmCTSx;
                             AHash: TDECHashClass = nil) : TMemoryStream;
  procedure Write(const Value; Size: Integer);
  begin
    Result.WriteBuffer(Value, Size);
  end;

  procedure WriteByte(Value: Byte);
  begin
    Write(Value, SizeOf(Value));
  end;

  procedure WriteLong(Value: LongWord);
  begin
    Value := SwapLong(Value);
    Write(Value, SizeOf(Value));
  end;

  procedure WriteBinary(const Value: Binary);
  begin
    WriteByte(Length(Value));
    Write(Value[1], Length(Value));
  end;

var
  Seed: Binary;
  i : integer;
  aZip  : TVCLZip;
begin
  aZip    := TVCLZip.Create(nil);
  Result  := TMemoryStream.Create;
  Result.Clear;
  Result.Position       := 0;
  AFileStream.Position  := 0;
  ACipher               := ValidCipher(ACipher);
  AHash                 := ValidHash(AHash);
  Seed                  := RandomBinary(16);

  with ACipher.Create do
  try
    Mode := AMode;
    Init(AHash.KDFx(APassword, Seed, Context.KeySize));

    WriteLong(Identity);
    WriteByte(Byte(Mode));
    WriteLong(AHash.Identity);
    WriteBinary(Seed);
    WriteLong(AFileStream.Size);
    EncodeStream(AFileStream, Result, AFileStream.Size);
    WriteBinary(CalcMAC);
  finally
    Free;
  end;
  ProtectStream(AFileStream);
  AFileStream.Clear;
  Result.Position       := 0;
  AFileStream.CopyFrom(Result,Result.Size);
  Result.Clear;
  AFileStream.Position  := 0;
  aZip.PackLevel        := 9;
  aZip.ZLibCompressStream(AFileStream,Result);
  aZip.Free;
end;

[gammatester]

Was drum herum passiert, kann ich Dir nicht sagen. Ich rede nur von der eigentlichen Ver/Entschlüsselung des Klartextes mit Dec CBCx. Dazu braucht man

- einen Schlüssel (dazu mußt Du auch wissen ob mit 128 oder 256 Bit verschlüsselt wird)

- ein Initialisierungsvektor (Du mußt wissen, ob der zB am Anfang der Datei steht, oder fix ist, oder ...)

- Dann werden immer 16 Bytes im CBC-Modus ver/entschlüsselt

- Wenn die Länge Deines Textes kein Vielfaches von 16 ist, wird für den verbleibenden Rest der CFB8-Modus verwendet.

Ein weiteres Problem könnte der Weg vom Passwort zum Schlüssel sein (eventuell via Whirlpoolhash). Wenn Du schon den Delphi/DEC-Quellcode hast, ist es vielleicht besser ihn anzuhängen, vielleicht kann dann ein DEC-Experte (ich bin keiner) mehr sagen.