Eure Anregungen für das DEC 5.3 gebraucht

[Assertor]

Hallo DPler,

wie einige von Euch vielleicht schon wissen, arbeite ich derzeit an der DEC 5.3.

Bisher sind folgende Änderungen schon fertig:

• Eine recht umfangreiche interne Umstellung von Binary/RawByteString auf TBytes (array of Bytes in älteren Delphis)
• Bugfixes für C++ Builder Kompatibilität
• Anpassung der Conditional Defines
• Erweitere Fehlerbehandlung und Prüfung von Eingabedaten

Folgendes ist geplant:

• Rewrite aller Formattings (hex, base32, base64 etc)
• Komplexe GUI Demo
• Self-Tests mit Testvektoren
• Unittests

Wenn alles fertig ist, gibt es auch einen Link zum neuen "zu Hause" der DEC (Luckie bekommt natürlich auch wieder ein Release).

In diesem Thread geht es um Überlegungen und Wünschen zum nächsten Release. Neue Hashes und Cipher wird es in dieser Version nicht geben, dafür fehlt leider die Zeit. Konkret ergeben sich durch meine Arbeit einige Umstellungen, wobei ich den Aufwand für die Konvertierung von DEC 5.1 und 5.2 nutzenden Projekten so gering wie möglich halten werde. Prinzipiell entfällt aber der Datentyp Binary, da nun alles auf Bytes arbeitet. Im Gegensatz zu früheren Code-Snippets hier im Forum, wird diese Umstellung keine zusätzlichen Sicherheitsprobleme schaffen, da immer auf den Eingabedaten gearbeitet wird, diese also nicht unnötig vervielfältigt werden und im Speicher rumfliegen.

Wo ich jetzt die Anregung von Euch, den DEC Nutzern, gebrauchen kann: Das gewünschte Stringhandling in den Formatierungsklassen (TDECFormat, TFormat_xyz). Es soll ja auch die Möglichkeit geben z.B. HEX zu Strings und Strings zu HEX zu wandeln. Technisch soweit kein Problem, aber es kommen je nach Art des Ziels natürlich unterschiedliche Ergebnisse raus.

Angenommen, es gäbe z.B. die folgenden Funktionen für TDECFormat:

Delphi-Quellcode:

class function EncodeString(const Value: string): string; overload;
class function DecodeString(const Value: RawByteString): string; overload;
class function EncodeAnsiString(const Value: AnsiString): AnsiString; overload;
class function DecodeAnsiString(const Value: RawByteString): AnsiString; overload;
class function EncodeWideString(const Value: WideString): WideString; overload;
class function DecodeWideString(const Value: RawByteString): WideString; overload;

Würde ich nun TFormat_HEX.DecodeString('74657374') in einem aktuellen unicodefähigen Delphi aufrufen, bekäme ich ja nur unlesbaren Quatsch heraus, bei TFormat_HEX.DecodeAnsiString('74657374') jedoch den AnsiString "test". TFormat_HEX.EncodeString('test') liefert bei Unicode ja das Ergebnis 7400650073007400, bei EncodeAnsiString('test') natürlich die 74657374.

Ich hätte das gerne zusammengelegt, jedoch finde ich keine allgemeingültige Lösung. Es wäre Hellsehen gefordert zu wissen, ob die Eingabedaten in HEX Ansi oder Unicode sind.

Hat jemand eine Idee hierzu? Was wäre Euch lieber, wäre es so wie oben gepostet für jedermann verständlich? Oder würdet Ihr für DecodeString('74657374') das Ergebnis "test" immer erwarten, egal ob Unicode oder ANSI (was ja eigentlich verkehrt wäre)?

Es geht hier nur um das Format-Handling von Strings, die Byte/Buffer-Methoden und Cipher/Hashes sind hiervon natürlich nicht betroffen.

Gruß,
Assertor

[jaenicke]

Vorweg: Ich kenne das DEC nicht wirklich (man hat ja nie genug Zeit, eigentlich wollte ich es mir schon lange genauer ansehen...).

Was Unicode angeht: Dafür gibt es doch das entsprechende Compiler Define, anhand dessen man das Vorgehen unterscheiden kann. Heißt: Gibt es dieses define, dann ist ein String ein UnicodeString, andernfalls ein AnsiString. Lässt sich das nicht auch in deinem Fall so umsetzen?

Bei mir sieht das z.B. so aus:

Delphi-Quellcode:

  {$ifdef UNICODE}
  Result := Utf8ToString(ResultString);
  {$else}
  Result := Utf8Decode(ResultString);
  {$endif}

[Assertor]

Hallo jaenicke,

Zitat:

Zitat von jaenicke

Vorweg: Ich kenne das DEC nicht wirklich (man hat ja nie genug Zeit, eigentlich wollte ich es mir schon lange genauer ansehen...).

Was Unicode angeht: Dafür gibt es doch das entsprechende Compiler Define, anhand dessen man das Vorgehen unterscheiden kann. Heißt: Gibt es dieses define, dann ist ein String ein UnicodeString, andernfalls ein AnsiString. Lässt sich das nicht auch in deinem Fall so umsetzen?

Bei mir sieht das z.B. so aus:

Delphi-Quellcode:

  {$ifdef UNICODE}
  Result := Utf8ToString(ResultString);
  {$else}
  Result := Utf8Decode(ResultString);
  {$endif}

Die IFDEFs sind nicht das Problem, aber UTF8 ist eine gute Idee, da es ja transparent für Plain-ASCII ist. Das wäre doch schonmal eine gute Lösung für das Encode/DecodeString! Auf die banale Idee einen UTF8 String zu nehmen, bin ich nicht mehr gekommen. So einfach und effektiv, danke :thumb:

Ich muß mal testen, wie sich das im Zusammenhang mit den Funktionen Encode/DecodeAnsiString und -WideString verhält, damit ein möglichst intuitives Verhalten verhanden ist.

Viele Grüße,
Assertor

P.S.:

Zitat:

man hat ja nie genug Zeit

Weise Worte, so ist es!

[Zacherl]

Sau gut dass du das DEC weiterentwickelst :) Ich denke mal in dieser Version kann man das vergessen aber für auf lange Zeit gesehen wären eigene Implementierungen von SSL, SRP, etc. ziemlich interessant.
Zum Unicode Problem:
Da würde ich zweigleisig mit DecodeWideString und DecodeAnsiString bzw. mit DecodeStringW und DecodeStringA, ganz nach API Vorbild arbeiten. Ist wohl am wenigsten verwirrend. Zusätzlich kann man eine Funktion DecodeString implementieren die je nach Delphi Version (prüfen mit {$IFDEF UNICODE}) die W oder A Variante aufruft.

[Assertor]

Hi,

Zitat:

Zitat von Zacherl

Sau gut dass du das DEC weiterentwickelst :)

Danke :-D

Zitat:

Zitat von Zacherl

Ich denke mal in dieser Version kann man das vergessen aber für auf lange Zeit gesehen wären eigene Implementierungen von SSL, SRP, etc. ziemlich interessant.

Ja, das würde für dieses Release den Rahmen sprengen. Ich habe jetzt schon dutzende Stunden dafür investiert. Aber sobald die neuen Grundlagen stehen, kann ich für zukünftige Releases ein Augenmerk auf neue Verfahren setzen.

Zitat:

Zitat von Zacherl

Zum Unicode Problem:
Da würde ich zweigleisig mit DecodeWideString und DecodeAnsiString bzw. mit DecodeStringW und DecodeStringA, ganz nach API Vorbild arbeiten. Ist wohl am wenigsten verwirrend. Zusätzlich kann man eine Funktion DecodeString implementieren die je nach Delphi Version (prüfen mit {$IFDEF UNICODE}) die W oder A Variante aufruft.

Jein, es wird aber so ähnlich sein. Hintergrund ist, ich möchte die Referenzzählung für UnicodeStrings nicht verlieren. Würde ich hier auf WideString setzen wäre das der Fall, da die Compiler Magic dann hier zuschlägt. Ich könnte natürlich den UnicodeString als Typ für ältere Delphis einführen, aber dadurch gewinne ich nicht viel...

Ich habe nun EncodeString() und DecodeString() überladen für Unicode/Ansi/Wide-String und zusätzlich Encode/DecodeAnsiString und -WideString eingeführt. Das erlaubt auch das explizite aufrufen einer gewünschten Funktion, ohne vorher einen Typcast machen zu müssen - das übernimmt dann die Compiler Magic für uns.

Die Idee mit UTF8 war toll, danke nochmal an Sebastian :thumb: In jetzigen Tests läuft alles problemlos mit TFormat_Copy / TFormat_HEX - in allen 3 Stringvarianten unter D2010 bzw. 2 Varianten unter D7. Jetzt bin ich gerade an der Re-Implementierung von Base64, PGP, XX, UU und Escaped Encoding. Da hier jetzt nicht mehr auf PAnsiChar sondern PByte gearbeitet wird, ist es halt etwas Arbeit...

@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?

Gruß,
Assertor
:dp:

[taaktaak]

Hmm, wer lernen will, muss manchmal Fragen stellen.
Ich traue mich mal: Wer oder Was ist DEC?
Wiki hilft mir da nicht so weiter...
:oops:

[Matze]

DEC steht für Delphi Encryption Compendium. Dabei handelt es sich um eine Unit-Sammlung von Hagen Reddmann, die einiges bzgl. Verschlüsselung und Hashing beinhaltet.

[taaktaak]

Vielen Dank!
Also für den Hobby-Programmierer (so er sich nicht akademisch mit dem Thema beschäftigt) wohl eher ein Randthema, oder?

[Zacherl]

Zitat:

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?

Ich würde vermuten, dass Hagen am base32 Algo lediglich noch eigene Verbesserungen mit eingebracht hat. Ähnlich wie bei seinem RCx Cipher, der ja eine Verbesserung von RC4 (oder wars RC5) darstellt. Den "original" base32 könnte man ja zusätzlich implementieren, ohne den alten MIME32 rauszuschmeißen oder zu ersetzen :)

Zitat:

Zitat von taaktaak

Also für den Hobby-Programmierer (so er sich nicht akademisch mit dem Thema beschäftigt) wohl eher ein Randthema, oder?

Ganz wie dus nimmst. Ich habe mit dem DEC Hobby mäßig bereits einen Kennwort Manager programmiert und wenns um Netzwerk Kommunikation geht, kommt das DEC sowohl zum hashen als auch bei der Verschlüsselung regelmäßig in meinen privaten Projekten zum Einsatz.

[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 :D

[himitsu]

Zitat:

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:

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 :D

:)

Zitat:

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 :-D

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:

Zitat von himitsu

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

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

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 :thumb: 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:

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. :angel2:

[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:

Zitat von himitsu

Zitat:

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. :angel2:

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. :angel2:

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

[Assertor]

Hallo,

Zitat:

Zitat von Findus

Zitat:

Zitat von himitsu

Zitat:

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. :angel2:

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.

Also mein Zitat hast Du gut aus dem Zusammenhang gerissen, Findus ;)

Ich sprach vor den Versionsnummern, nun steht es im Kontext von fehlender Kompatibilität... Ich werde sicher nicht die Nach mir die Sintflut Mentalität an den Tag legen, deswegen verzögern sich ja auch die Arbeiten an der nächsten DEC.

Generell möchte ich aber anmerken, dass ich Deinen Ausführen nicht 100% zustimmen kann. Manchmal sind Änderungen die daten- oder interfaceinkompatibel sind, schlicht notwendig. Beispielsweise hat Hagen dies bei dem Rewrite der DEC 3 zur Version 5 auch gemacht, da weiterentwickeltes Wissen auch im Bereich der Kryptographie einfloss. Und es finden sich viele weitere Beispiele großer Hersteller (auch in und um den Bereich Delphi). Etwas Richtiges, was Bestand hat zu finden, kann dann schon eine philosophische Lebensaufgabe werden. Software im Allgemeinen und auch Delphi Komponenten im Speziellen überaltern ebenso, wie Betriebssysteme, Formate, Schnittstellen etc.pp.

Das geschieht bei OpenSource ebenso wie bei kommerziellen Projekten. Wir alle wissen, dass viele kommerzielle Delphi Tools und Komponenten auch nicht überlebt haben. Bei OpenSource ist dann natürlich der Vorteil, dass es andere weiterpflegen könnten. Bestes Beispiel sind die notwendigen Unicode Umstellungen alter Komponenten auf Delphi 2009, wobei viele Portierungen meiner Meinung nach halbherzlich und oder fehlerhaft waren bzw. sind.

Konkret für die DEC: Ich werden den Teufel tun, ein Code Breaking Release zu veröffentlichen, wenn es nicht irgendwie vermeidbar ist. Schließlich werde ich sonst mit den ganzen Fragen bombardiert. Es gibt leider genügend Menschen, die für eine kostenlose Komponente einen Support im Stil eines Kaufproduktes erwarten (und den natürlich auch kostenlos).

Das ist die Kehrseite der Medaille, sei es drum - mir macht es Spaß und ich helfe der Community gerne!

Gruß,
Assertor

[Assertor]

Hallo OTS,

Zitat:

Zitat von OTS

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 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?

Ja, das von Dir beobachtete Verhalten liegt am veränderten Padding zwischen der DEC 3 und DEC 5. Diese Änderung liegt also schon ein paar Jahre zurück und hat nichts mit Deiner Delphi 2010 Umstellung zu tun.

Hagen hat seinerzeit bei der Entwicklung der DEC 5.1 das Padding für den CTS Feedback Mode ersetzt. Deswegen auch cmCTSx. Die DEC 3 hatte dort ein CFS Padding (CFS auf Blockgröße), nun ist es ein CFS8 (im DEC Source steht es auch bei cmCFS8 vermerkt als 8Bit CFS, double CFB).

In der nächsten DEC wird es sehr wahrscheinlich ein zusätzlichen Cipher Mode für genau diese Abwärtskompatibilität geben. Deine Anpassung entspricht übrigens einem Padding von cmCFSx auf Blockgröße - und genau dies wird in Zukunft automatisch im Cipher Mode cmCTSxx zur Verfügung stehen (aber bitte nur für Abwärtskompatibilität nutzen!).

Gruß,
Assertor

P.S.: Wenn Du es für Dich anpasst, denke auch an den Decoder. Dort ist dies auch zu machen.

[OTS]

Hallo Assertor,

vielen Dank für die super schnelle Antwort :thumb: .

Zitat:

Wenn Du es für Dich anpasst, denke auch an den Decoder. Dort ist dies auch zu machen

.. werd ich machen.

[Assertor]

Hallo OTS,

Zitat:

Zitat von OTS

Hallo Assertor,

vielen Dank für die super schnelle Antwort :thumb: .

Keien Ursache! Sehe gerade, Du bist ja neu, also: Herzlich willkommen in der Delphi-Praxis!

:dp:

Gruß,
Assertor

[MaBuSE]

Zitat:

Zitat von Assertor (Beitrag 1021006)

wie einige von Euch vielleicht schon wissen, arbeite ich derzeit an der DEC 5.3.

Wie ist denn der Stand der Dinge?

[x000x]

Zitat:

Zitat von MaBuSE (Beitrag 1072612)

Wie ist denn der Stand der Dinge?

Das würde mich auch interessieren...

[ringli]

Ich wollte auch mal Anfragen wie denn der aktuelle Stand der Überarbeitung ist :oops:

[Schorschi5566]

Sehe gerade, dass DEC 5.3 in Arbeit ist.

Ich schlage mich gerade damit rum DEC 5.2 nach Lazarus zu portieren. Könnte man das nicht auch gleich für die neue Version berücksichtigen?

Bin gerade erst bei der DECUtils und weiß nicht, was noch alles zu ändern ist aber wäre bestimmt besser, wenn das jemand macht, der sich mit dem Paket gut auskennt. ;)

Nur so als Vorschlag...


Grüße,
Uwe

[MaBuSE]

Zitat:

Zitat von Schorschi5566 (Beitrag 1104779)

Sehe gerade, dass DEC 5.3 in Arbeit ist. ...

DEC scheint leider gestorben zu sein.

Der erte Beitrag in diesem Thema war:

Zitat:

Zitat von Assertor (Beitrag 1021006)

... wie einige von Euch vielleicht schon wissen, arbeite ich derzeit an der DEC 5.3. ...

Das war Mai. 2010. Bisher ist nichts passiert. Das deutet darauf hin, dass das Projekt gestorben ist.

Assertor scheint wohl doch nicht die nötige Zeit gefunden zu haben es weiterzuentwickeln.

Schade :-(

Ich mache Assertor keinen Vorwurf. Ich kenne das Problem. Ich habe auch noch ein paar Duzend Projekte, die ich gerne fertigstellen würde, aber leider keine Zeit dazu. So ist das nun eben mal :cry:

Viele Grüße
MaBuSE

[alphaflight83]

Tag auch,

ich bin jetzt auch in die Verlegenheit gekommen das DEC zu benötigen.
Momentan sollte das mit Version 5.2 auch tun, denke ich.
Für die Zukunft wäre ein Update aber schon interessant.
Deswegen die Frage: Weiß jemand, ob da noch was geht, oder ist das Projekt wirklich tot, wie MaBuSE schon vermutet hat?
(Nicht dass die Wahrscheinlichkeit ein halbes Jahr nach dieser Vermutung geringer geworden wäre ;) )

Gruß alphaflight83

[Luckie]

Ich hoste es nur. Kann dir aber leider auch nichts dazu sagen.

[MaBuSE]

Zitat:

Zitat von alphaflight83 (Beitrag 1140023)

Deswegen die Frage: Weiß jemand, ob da noch was geht, oder ist das Projekt wirklich tot, wie MaBuSE schon vermutet hat?
(Nicht dass die Wahrscheinlichkeit ein halbes Jahr nach dieser Vermutung geringer geworden wäre ;) )

Es ist nicht tot. Es schläft ;-)

Ich habe mit Assertor auf den DelphiTagen 2011 gesprochen.
Er hat im Moment wenig Zeit, entwickelt aber hin und wieder an dem Projekt.
Es ist im Moment nur nicht in einem Zustand, dass man es veröffentlichen könnte (Baustelle).

Aber ich bin zuversichtlich, dass es irgendwann kommt :thumb:

[Codehunter]

Ich bin gerade auf diesen Thread aufmerksam geworden. Mich würde interessieren, in welchem Zusammenhang die DEC-Version 5.3 von Assertor zur 5.1 von Hagen Reddmann steht. Ist das eine abgestimmte Weiterentwicklung oder eher ein Fork?

[alphaflight83]

Assertor hat das DEC seit der letzten Version 5.2 in Abstimmung mit Hagen weitergeführt.
Siehe Release-Blogeintrag zu 5.2

Edit: Im Blog ist dann auch ein Eintrag von gestern zu finden, der MaBuSEs Post bestätigt.

Zitat:

If I am able to find some spare time ...

Na, dann wünsche ich schon mal jede Menge Freizeit :stupid:

[Assertor]

Hallo DP Community,

ich scheine keine Benachrichtigungen mehr für meine (sehr) alten DP Threads zu bekommen, da übersieht man schlicht manche Diskussion. Mea culpa!

Nun zum aktuellen Stand:

Die Kurzfassung
Die DEC ist nicht tot, aber nicht x64-kompatibel.

Die Langfassung
Wie richtig erahnt wurde, kamen andere Dinge dazwischen. Nennen wir es Leben, vorrangig aber Arbeit. Ich bin eben nicht in einer Position, wie z.B. angestellte Entwickler, die nach einem 8-10 Stunden Arbeitstag in einer 5 Tage-Woche sich Ihren Interessen widmen können, sondern stehe als Selbständiger immer an vorderster Front.

Seit Eröffnung dieses Threads ist viel Zeit vergangen. Ich habe das damalige Feedback aufgegriffen und experimentell an der DEC weitergearbeitet. Dies bezieht sich auf Umstrukturierung, neue Kompatibilitätsansätze zu alten Versionen und einer besseren Unicode Unterstützung, insbesondere durch extensive Nutzung von Bytes statt Chars, wo immer möglich.

Diese ganzen Änderungen hatten noch nichts spezifisch mit Delphi 2010, XE oder XE2 zu tun. Nun kam das absehbare XE2 Release. Wie einige von mir wissen, bin ich hauptsächlich im Indy Project aktiv. Wer jetzt die Verbindung und Abhängigkeit von Indy und Delphi kennt, kann 1 und 1 zusammenzählen und sich denken, was vor dem XE2 Release bei Indy los war. Ergo blieb weniger als keine Zeit, um mich zeitnah um die DEC zu kümmern.

@Codehunter: Ich habe es so aufgefasst, dass ich das Projekt übernommen habe, in Übereinstimmung und mit Hagens Segen - ohne das für Ihn hieraus Verpflichtungen oder Aufwand entstehen. Es ist also eine Weiterentwicklung, kein Fork. Wir standen hierfür auch - bei Diskussionsbedarf - über dieses Forum hinaus in Kontakt.

Es steht natürlich jedem Frei, einen eigenen Fork anzulegen. Besser wäre imo aber in diesem Fall eine Beteiligung an diesem Projekt!

Der Zukunftsplan

1. Schritt: Ich muss meine experimentellen Änderungen von Mai 2010 wieder aufgreifen, ein Diff/Merge auf den 5.2 Source fahren, um zu sehen, wo ich genau war und was mich aufhielt. Dieser Source wird hoffentlich zeitnah in einem XE2 x32 Release mit einigen Fehlerbereinigungen, verbesserter Unicode-Unterstützung und Kompatibilitätspatches münden. Alte D5-D7 DCUs-only von Hagen fliegen raus, ASN1/CPU Unit wahrscheinlich ebenfalls.

Das ganze am liebsten garniert mit Unittests (u.a. Monte Carlo Tests für AES) und einem besonderem Bonbon an dem ich arbeitete. Ich hab dieses Subprojekt DEC CryptoLab getauft.

Das ganze kann leider noch etwas dauern, da ich bis Ende März vollständig "ausgebucht" bin und sich schon das nächste Großprojekt anbahnt.

2. Schritt: Ich muss prüfen, *ob* sich der ASM Source in den notwendigen Bereichen zu PurePascal portieren lässt. Dies ist nicht ohne weiteres möglich.

Als gute Analogie denke man an Komponenten/Tools wie Tb2k/SpTBXLib, madExcept etc.pp., diese sind aktuell ebenfalls nicht x64-fähig. Teilweise gibt es auch keine Zeitpläne von kommerziellen Komponentenherstellern!

Der Umfang einer Portierung in diesem Bereich ist ungleich größer gegenüber der Unicode Portierung von D2009. Jeder der in einem Produktivsystem einen Wechsel über die D2007/2009-Barriere vollziehen durfte, weiß welche Probleme es gab. Dies ist im Vergleich zum jetzigen Umstellungsaufwand "Pille-Palle" (TM).

Ich werde es mir ansehen und mein möglichstes tun. Es soll aber jeder, der Druck macht, sich diese ganze Umstände nocheinmal verinnerlichen. Ich erhalte zu diesem Thema viele Mails, die wegen der x64 DEC fragen - und das bereits wenige Tage nach dem offziellen XE2 Release.

Fakt: Es ist OpenSource, ich arbeite alleine an diesem Projekt, ich habe wenig Freizeit. Der Delphi x64 Compiler unterstützt nur x64 ASM oder Pascal, kein Mixed-Mode, wie in x32. Und Andreas Hausladen (jbg) hat auch kürzlich hier in einem Thread ein ASM Bug im x64 Compiler bestätigt, der mich ebenfalls nerven wird. Schöne neue Welt.

Gerade die DEC muss nunmal eben mit Vorsicht gepflegt werden, da hier schnell kleine Fehler zu großen Problemen führen. Qualität dauert eben länger, ich will nicht jedes Jahr im August ein neues DEC Release raushauen, nur um die Versionsnummern zu erhöhen und mit Compilerherstellern gleich zu ziehen :mrgreen:

Ich würde aber jedem empfehlen, den Einsatz von x64 immer an gute Unittests zu koppeln ;)

Also getreu dem etwas angepassten Motto "le DEC est mort, vive le DEC", wird es weitergehen. Nur nicht als DEC 5.3, sondern als DEC 6.0. Falls mich jemand unterstützen möchte, z.B. beim PurePascal Port, Freiwillige vor! Dies würde ja auch z.B. der FPC-Kompatibilität helfen.

Auf jedenfall danke ich mabuse für die korrekte Weitergabe der Info von den DT 2011 :thumb: Der 20er sollte aber keine Bestechung hierfür sein ;)

@alphaflight83: Danke :lol: Mehr Freizeit wünsch ich mir selbst auch immer ;)

Viele Grüße
Assertor

P.S: @Luckie - Das ist mein offizielles Statement :)

Offizielle Downloadseite: http://dec.michael-puff.de

[blackdrake]

Ein sehr großer Wunsch von mir war ja immer die Asynchrone Verschlüsselung zu Implementieren. Ich bin deswegen sogar von Delphi abgedriftet, da es für OpenSource Projekte keine PKI Implementierungen gibt. In Java kann man mit 5 Quelltextzeilen eine asynchrone Verschlüsselung hinbekommen.

Einen Bug, den ich damals fand war, dass der Shark Cipher nicht funktioniert. Beim Ver- und Entschlüsseln kommen unterschiedliche Ergebnisse raus.

Gruß
blackdrake

[Codehunter]

@Assertor:

Zuerstmal ein gesundes und erfolgreiches neues Jahr!

Falls du meine Frage als Kritik aufgefasst haben solltest, es war nicht als solches gemeint. Ich bin schon lange Anwender der 5.2er und damit mehr als zufrieden. Dass es überhaupt eine Weiterentwicklung gab/gibt hat mich ehrlich gesagt ein wenig überrascht, ich verfolge die DP ja auch nicht in allen Einzelheiten und bin eben eher zufällig über den Thread hier gestolpert.

Warum ich nach einem Fork bzw. Nicht-Fork fragte hat einen aktuellen Grund: Open-Libre-Office. Als Anwender (!!!) weiß man nicht, in welche Richtung man schwenken soll. Libre ist besser, Open ist populärer. Inzwischen gibt es die ersten Inkompatibilitäten.

Übertragen auf DEC muss man als Anwender dann damit rechnen, dass Anwendungen der älteren 5.2er, die ja nach wie vor in der weiten Welt genutzt werden, möglicherweise nicht mit Anwendungen basierend auf einem neueren DEC arbeiten würden. Da frage ich lieber vorab mal genauer nach.

Betreffs x64: Ich sehe das mit gemischten Gefühlen. Einerseits ist x64 ein Verkaufsargument, andererseits ist der Portierungsaufwand generell schon teils erheblich. Verschläft man den Punkt X kanns passieren dass einem die Konkurrenz irgendwann mit x64-Produkten das Wasser abgräbt. Ist man aber vorzeitig dabei, verschenkt man unnütz Portierungsaufwand.

Im Moment ist in der Delphi-Szene noch nicht viel zu reißen mit x64. Die größeren Komponentenanbieter sind auch noch nicht am Start und wenn dann mit Teilmengen der Komponenten oder mit Pre-Alphas. Für manche Projekte bringt x64 auch schlicht keine Vorteile (z.B. weil man nicht so viel RAM braucht). Da ist inzwischen Multithreading fast interessanter als 64 Bit.

[Assertor]

Hallo Codehunter,

danke, Dir (und allen anderen) auch ein frohes, gesundes Neues Jahr!

Nein, kein Problem - ich hab das nicht als Kritik aufgefasst. Meine Forumulierung war um die Uhrzeit nicht mehr ideal. Ich weiß, dass hier im Forum z.B. ein FPC Portierungsversuch läuft. Das wäre dann ein Fork, von meinem Standpunkt aus.

Zur Kompatibilität:
Ich werde den Source der DEC 6 so kompatibel wie möglich machen. Als Ziel habe ich mir 99% vorgenommen. Es wird sich bei der Identitybase nicht vermeiden lassen, etwas zu ändern, da mein 5.2 Port hier fehlerhaft war. Ich stelle also dort die Kompatibilität zur DEC 5.1 wieder her und führe ein neues Schema parallel dazu ein.

Der ältere 5.2 Port war ja auch schon von mir.

Zu x64: Deine Einschätzung teile ich in vielen Punkten. Gerade Multithreading ist ein großer Nachteil in Delphi - ohne externe C Libraries kommt man häufig nicht auf die gewünschte Geschwindigkeit. Als Intel Technology Partner weiß ich, dass Delphi Kompilate hier in der Regel gnadenlos versagen (z.B. im SAT Concurrency Checker) und Ergebnisse liefern, die in der Nähe von VB 6 und RealBasic sind.

Aber das ist auch alles lösbar, wie gesagt z.B. mit geeigneten Referenzbibliotheken aus c.

Meine Entwicklungs-VM für die DEC läuft nun wieder, ihr habt mich nun etwas motiviert ;) Vielleicht packe ich auch auf die Google Code Seite einen PayPal Button. Ich weiß nicht, ob sich sowas in der Delphi Szene lohnen würde. Helfen auf jeden Fall, dann kann ich auch mal Tage der DEC widmen, an denen ich sonst anderweitig Geld verdienen müsste.

Jetzt zur Daily Info:

Ich fange jetzt ganz unten neu an. TDD, also Unit Tests für die neue DEC Utils. PurePascal Port für die Bit/Byte Swaps und XOR.

Ich konnte heute bei SwapBits() die Geschwindigkeit um den Faktor 35 verbessern, obwohl in PurePascal und nicht ASM. Dadurch läuft dieser Teil schonmal auf x32 und x64. Referenz war die heute übliche, bekannte Info von Bit Twiddling Hacks, in diesem Fall eine Lookup-Table.

Mein (unverbindliches) persönliches Ziel wäre PurePascal mit ASM wo nötig und möglich, jeweils für x32 und x64, für Delphi und C++ Builder ab Version 7/2007 bis XE2 sowie FPC/Lazerus (in FPC ohne CryptoLib und Unittests, da ich Delphi nutze).

Nun denn, schauen wir mal, wie weit ich dieses mal komme :)

Viele Grüße
Assertor

[Codehunter]

Die Diskussion mit dem Multithreading hatte ich anderweitig auch schon mal. Native API-Programmierung ging wohl so halbwegs was Performance betrifft, die VCL-Klassen-Implementierung (TThread) stinkt wohl gnadenlos ab.

Vielleicht sollten sich die Leute die seinerzeit Bibliotheken wie z.B. FastMM4, DEC, Indy, Graphics32, VirtualTree etc. gebaut haben, mal zusammensetzen und schauen ob man eine gute performante Multithreading-Klassenbibliothek gebaut bekommen, die für die "einfacher gestrickten" Entwickler (zu denen ich mich auch zähle) auch bedienbar bleibt. MT ist an sich schon ein schwieriges Thema. Synchronisierung, Variablenlokalisierung etc. Da bekommt man anfangs schon Hirnverwurschtelung ;-) Die Entwicklung bei den Prozessoren in den letzten Jahren ging jedenfalls in diese Richtung und Delphi hats - simpel gesprochen - verschlafen.

Ich halte mich jedenfalls nicht für ausreichend qualifiziert, solche Basisbibliotheken oder eben auch DEC zu entwickeln, deshalb halte ich mich mit Forderungen auch sehr zurück. Was ich aber sehe ist dass Embarcadero Delphi in eine Richtung versucht zu entwickeln, für die es nicht gut geeignet ist, dabei häufig Richtungswechsel vollzieht und die Pflege der Basisbibliotheken ein wenig vernachlässigt. Inzwischen haben wir ein gefühltes Dutzend mitgelieferter, zueinander inkompatibler Frameworks.

So, Schluss mit dem kleinen Offtopic :-)

[Zacherl]

Lebt das Projekt noch? Habe jetzt mal kurz das DEC 5.2 auf XE4 angetestet und bekomme jede Menge Compilerwarnungen. Wollte nur wissen, ob es sich lohnt das mal alles zu fixen, oder ob man in nächster Zeit mit DEC 6 rechnen kann.