Eure Anregungen für das DEC 5.3 gebraucht

[himitsu]

Zitat von Assertor:

@Hagen: Falls Du mitliest, was ist denn Dein MIME32 für ein Format? Die Ergebnisse aus der DEC 5.1 (und 5.2) stimmen z.B. mit Base32 überhaupt nicht überein. Du hattest es kommentiert mit "MIME ähnliches Base32". Also ein eigener Formatansatz. Ich würde lieber Base32 wie in RFC4648 umsetzen. Hatte es seinerzeit einen besonderen Grund ein eigenes MIME-ähnliches Format für Base32 einzuführen?

Base32 und Base64 sind kein festes Format.
Hier wird nur ausgesagt, daß der Datenstrom in einer bestimmten Art mit 32/64 Zeichen dargestellt wird.
Welche Zeichen verwendet werden und wie die Endemarkierung vorgenommen wird (es werden ja immer Guppen zu 3 Bytes umkodiert, aber was ist, wenn der Datenstrom am Ende nur 1 oder 2 Byte hat)
Mime32/Mime64 ist eine Unterart von Base32/Base64, wo auch noch festgelegt ist, welche Zeichen verwendet werden und wie der Abschluß aussieht.

Also Korrekt wäre es, wenn es es eine Base32-Klasse gibt, von welcher die Mime32-Klasse abgeleitet ist, in welcher nur der Zeichensatz und die Endebehandlung geändert/behandelt werden.

[Assertor]

Hallo,

Zitat von Angel4585:

Ah ein neues DEC? Kann ich gut gebrauchen wo ich jetz auf D2010 umstelle, da kommts doch zu en paar Problemen mit dem bestehenden. freu mich schon

Zitat von himitsu:

Base32 und Base64 sind kein festes Format.
Hier wird nur ausgesagt, daß der Datenstrom in einer bestimmten Art mit 32/64 Zeichen dargestellt wird.
Welche Zeichen verwendet werden und wie die Endemarkierung vorgenommen wird (es werden ja immer Guppen zu 3 Bytes umkodiert, aber was ist, wenn der Datenstrom am Ende nur 1 oder 2 Byte hat)
Mime32/Mime64 ist eine Unterart von Base32/Base64, wo auch noch festgelegt ist, welche Zeichen verwendet werden und wie der Abschluß aussieht.

Also Korrekt wäre es, wenn es es eine Base32-Klasse gibt, von welcher die Mime32-Klasse abgeleitet ist, in welcher nur der Zeichensatz und die Endebehandlung geändert/behandelt werden.

Nach RFC 4648 ist der Zeichensatz schon explizit für Base32, Base32hex und Base64 festgelegt (sofern es diesen Namen trägt). MIME/PEM unterscheiden sich im Soft-Wrap und Padding, alternative Zeichensatzimplementation gibt es hier und da im Internet. Sowas dann hinzuzufügen ist mit dem DEC Code jetzt und in Zukunft lächerlich einfach.

Die alten Encodings laufen nun alle, sprich: Base16 (HEX), Base16L (HEX Lowercase), DEC MIME32, Base64, Radix-64 (PGP Base64 mit 24-bit CRC), UU, XX und ESCAPE Encoding sind wieder lauffähig

Die Cipher und Utils sind auch nahezu fertig. Jetzt kommt noch Base32, Base32hex und dann ca. 1-2 Wochen Self-Tests Vektoren aufsetzen, UnitTests, Demos etc. Ich hatte auch schon einen Monte Carlo Test für Rijndael fertig (ja, die DEC besteht diesen natürlich) - mal sehen ob ich den noch mit als extra Test reinbekomme.

Da jetzt alles auf Bytes arbeitet, wird es einen neuen Wrapper zum kombinieren von Salt, Data und MAC geben. Ebenso einen Splitter für das Decoding. Das sollte die Nutzung mit früherem Code erleichtern. Für normale Strings bleibt, soweit ich es überblicken kann, alles gleich.

Das ganze war bisher ziemlich aufwendig... Sehr vereinfacht gesagt, mußte für die Umstellung auf Byte Encoding und echte Unicode-Unterstützung (ohne auf Benutzerseite "* SizeOf(Char)" machen zu müssen) der ganze Code angefasst werden und die Zusammenarbeit zwischen den Teilbereichen angepasst werden. Zusätzlich war meine Voraussetzung für die Änderungen, dass keine Duplizierung von Plaintext-Daten im Speicher erfolgen darf, da dies die Sicherheit kompromitieren könnte. Dieses Ziel ist nun erreicht - wie Hagen in einem früheren Thread mal sinngemäß sagte: Diese Umstellung ist viel Arbeit und wenn man es macht, muß man große Brötchen backen Bisher läuft alles gut, aber ich werde noch einige Tests mit altem Code machen müssen, um sicherzustellen das Daten aus der DEC 5.1, 5.2 und 5.3 kompatibel zueinander sind.

Da die meisten DEC Anwender wohl ohne Salt, Key Derivation / Mask Generation und MAC unterwegs sind, wird es auch einen Wrapper geben der dies automatisch und anpassbar erledigt. Das soll Anfängern den Einstieg erleichtern.

Gruß,
Assertor

P.S.: @taaktaak - Es kommt immer auf das Hobby an

[himitsu]

PS: bei so großen Änderungen ... warum dann nicht DEC 6.0 ?

[Assertor]

Hallo Himitsu,

Zitat von himitsu:

PS: bei so großen Änderungen ... warum dann nicht DEC 6.0 ?

Wir sind doch hier nicht bei Microsoft Oder es wird passend zu EMBT einfach DEC 2011 genannt

Eigentlich bin ich kein Freund von inflationär gebrauchten Versionsnummern. Dafür sollte es schon immer einen guten Grund geben, z.B. ein Rewrite.

Wobei, je länger ich darüber nachdenke, die Idee mit DEC 6.0 gefällt mir So gesehen ist es ein "kleiner Rewrite". Und man kann man schnell unterscheiden, wenn eine Frage kommt (kenne das ja von Indy, da sagt jemand er nutzt 10.5.7 und stellt eine Frage mit Codeauszug aus 10.2.5).

Gruß,
Assertor

[himitsu]

Zitat von Assertor:

Wobei, je länger ich darüber nachdenke,

Vorteil wäre auch, daß du nicht "zwingend" zu den anderen DEC 5.x kompatibel sein müßtest, welches wohl auch das .Identity-Problemchen vereinfachen dürfte.

[Findus]

Hallo,

habe soeben ein D5 Projekt auf D2009 umgestellt. Dabei habe ich erst an der DEC-5.1 rumgefummelt, bis ich dann die Dec-5.2 gefunden habe. Mit zwei Fehler habe ich mit zu kämpfen gehabt.

1) Zu erst waren alle Identity gleich (in der 5.2 wohl gelößt). Doch ich konnte es auch in der 5.1 zum laufen bringen, indem ich die Procedure CRCTab in eine Konstante umsetzte.

Code:

  const
  CRCTab : TCRCTab = (
      (Poly:$000000D1; Bits:8; Init:$00000000; FInit:$00000000; Inverse:true),   // CRC_8  GSM/ERR
      (Poly:$00000233; Bits:10; Init:$00000000; FInit:$00000000; Inverse:true),   // CRC_10 ATM/OAM Cell
      (Poly:$0000080F; Bits:12; Init:$00000000; FInit:$00000000; Inverse:true),   // CRC_12
      (Poly:$00008005; Bits:16; Init:$00000000; FInit:$00000000; Inverse:true),   // CRC_16 ARC;IBM
      (Poly:$00001021; Bits:16; Init:$00001D0F; FInit:$00000000; Inverse:false),   // CRC_16 CCITT ITU
      (Poly:$00008408; Bits:16; Init:$00000000; FInit:$00000000; Inverse:true),   // CRC_16 XModem
      (Poly:$00864CFB; Bits:24; Init:$00B704CE; FInit:$00000000; Inverse:false),   // CRC_24
      (Poly:$9DB11213; Bits:32; Init:$FFFFFFFF; FInit:$FFFFFFFF; Inverse:true),   // CRC_32
      (Poly:$04C11DB7; Bits:32; Init:$FFFFFFFF; FInit:$FFFFFFFF; Inverse:true),   // CRC_32CCITT
      (Poly:$04C11DB7; Bits:32; Init:$FFFFFFFF; FInit:$00000000; Inverse:true)   // CRC_32ZModem
      );

Die Procedure CRCTab erinnerte mich an meine Assembler Zeiten vor 30 Jahren. Daten in Code zu speichern wurde nicht richtig umgesetzt. Auch sollten wohl bald Daten und Code sauber getrennt sein, so das ich es in der 5.2 für mich geändert habe.

2) Alte Daten konnte ich nicht mehr einlesen, da die Identity geändert haben. Schuld war die geänderte Erzeugung der Indentiy nun ein widestring mit 512 Bytes und damals ein ansistring mit 256 Bytes. Klar das die dann unterschiedlich sein muss. Für mich habe ich das dann so geändert:

Code:

class function TDECObject.Identity: LongWord;
var
  Signature: AnsiString;
begin
  Signature :=  AnsiString(StringOfChar(#$5A, 256 - Length(Classname)) + UpperCase(ClassName));
  Result := CRC32(IdentityBase, Signature[1], Length(Signature));
end;

Da der Classname sicher ohne Fehler auf AnsiString abzubilden ist, wäre das kein Problem das so zu machen. Da aber die 5.2 mit widestring geht, sollte man dies mit einer Compilerdirektive in der Source machen. Dass man das sogar programmiertechnisch macht, um alte und neue Dateien zu lesen, ist wohl ein größere Aufwand.

Gruß
Thomas

[Findus]

Zitat von himitsu:

Zitat von Assertor:

Wobei, je länger ich darüber nachdenke,

Vorteil wäre auch, daß du nicht "zwingend" zu den anderen DEC 5.x kompatibel sein müßtest, welches wohl auch das .Identity-Problemchen vereinfachen dürfte.

Mir kraust es immer vor dieser Nach mir die Sintflut Mentalität. Wenn eine neue Version nicht alte Daten lesen kann, dann ist die Akzeptanz für die neue Version sehr gering und für das Tool an sich. Altanwender bleiben bei dem Alten oder wechseln dann auf was Richtiges, auf etwas, was Bestand hat. Neuanwender hätten kein Problem mit alten Daten, aber die müssten sich fragen: Lauf ich übermorgen in die Falle?

Ich denke nicht, das es ein Identity Problem geben müsste.

[himitsu]

@Findus: Ich wollte damit nur sagen: Wenn es bekannte Probleme oder Ideen zur Verbesserung gibt, wozu aber eine größere Änderung nötig wäre, dann wäre ein Versionswechsel zumindestens ein guter Zeitpunkt.

PS: MD5 und GUID sind gleich groß, also falls die Identity geändert wird, dann könnte man schon das TGUID als Typ verwenden und wie die 128 Bit nun berechnet werden, daß ist ja erstmal egal.
Aber 128 Bit böten einen größeren Spielraum, gegenüber den aktuellen 32 Bit (für Identity).

[negaH]

Zitat:

Die Procedure CRCTab erinnerte mich an meine Assembler Zeiten vor 30 Jahren. Daten in Code zu speichern wurde nicht richtig umgesetzt. Auch sollten wohl bald Daten und Code sauber getrennt sein, so das ich es in der 5.2 für mich geändert habe.

Ja ich weiß. Der Grund warum diese "Daten" im BSS zu liegen kommen sollten, ist die Überprüfbarkeit der richtigen Funktion der CRC während der Laufzeit. Wenn die CRCs dazu benutzt werden innerhalb des Programmes zb. Testvektoren der Cipher/Hash vor Manipulationen zu schützen dann benötigen wir auch einen einfachen Weg die CRC selber vor Manipuation zu schützen. Mit der Speicherung im Codesegement kann man nun über den kompletten CRC Code eine CRC ziehen und so Laufzeitmanipulationen am CRC Code erkennen.

Das wurde von mir so angedacht aber niemals bis zu Ende implementiert. Und das hat auch einige Gründe. Kryptographisch gut wäre diese Lösung nämlich nicht. 100% vor cleveren Manipulationen wird sie auch nicht schützen. Deswegen CRC so belassen wie es war und die finalen Prüfungen nicht weiter implementiert.
So bleibt wenigstens das Feature das man diese BSS-Konstanten, auf Grunde des Schreibschutzes des CRC Codes im Speicher, als echte schreibgeschützte Konstanten benutzt, und so unabsichitliche Änderungen dieser Konstanten verhindert.

Gruß Hagen

[OTS]

Hallo Leute,

Erst mal vielen Dank für die tolle Arbeit an DEC. Ich nutze die Komponente schon lange und würde sie gerne weiter einsetzten.
Ich weiß nicht ob das hier die richtige Stelle ist, aber ich hab da mal ne Frage zu einer Portierung von D2007 -> D2010.
Ich habe bis D2007 die DEC Version 3.0 eingesetzt und bin mit der Portierung auf D2010 auf die DEC Version 5.2 umgestiegen. Ich habe nun ein Problem bei der Dekodierung von Dateien die mit der 3.0 Version Blowfish-Verschlüsselt wurden. Die letzten Bytes einer DEC 5.2 Verschlüsselung unterscheiden sich von der DEC 3.0 Verschlüsselung. Ich habe das Problem auf die folgenden Stellen im Quellcode zurückgeführt:

Delphi-Quellcode:

  procedure EncodeCTSx(S,D: PByteArray; Size: Integer);
  var
    I: Integer;
  begin
    Dec(Size, FBufferSize);
    I := 0;
    while I <= Size do
    begin
      XORBuffers(S[I], FFeedback[0], FBufferSize, D[I]);
      DoEncode(@D[I], @D[I], FBufferSize);
      XORBuffers(D[I], FFeedback[0], FBufferSize, FFeedback[0]);
      Inc(I, FBufferSize);
     end;
     Dec(Size, I - FBufferSize);
     if Size > 0 then
     begin // padding
       //EncodeCFS8(@S[I], @D[I], Size);    -------original code
          MyEncodeCFS8(@S[I], @D[I], Size); //my modification 
          FState := csPadded;
     end else FState := csEncode;
  end;

procedure EncodeCFS8(S,D: PByteArray; Size: Integer);
  // CFS-8, CTS as CFB
  var
    I: Integer;
  begin
    I := 0;
    while I < Size do
    begin
      DoEncode(FFeedback, FBuffer, FBufferSize);
      D[I] := S[I] xor FBuffer[0];
      Move(FFeedback[1], FFeedback[0], FBufferSize -1);
      FFeedback[FBufferSize -1] := FFeedback[FBufferSize -1] xor D[I];
      Inc(I);
    end;
    FState := csEncode;
  end;



procedure MyEncodeCFS8(S,D: PByteArray; Size: Integer);
   begin
    Move(FFeedback[0], FBuffer[0], FBufferSize);
    DoEncode(FBuffer,FBuffer,FBufferSize);
    XORBuffers(S[0], FBuffer[0], Size, D[0]);
    XORBuffers(FBuffer[0], FFeedback[0], FBufferSize, FFeedback[0]);
    FState := csEncode;
  end;

Ich habe DEC 3.0 und DEC 5.2 verglichen und mit der Modifikation "MyEncodeCFS8" funktioniert es wieder.
Mein Problem ist das ich nicht wirklich verstehe warum das so ist.

Kann mir da jemand weiter helfen?

Gruß

Malcolm