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

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 von Zacherl:

Sau gut dass du das DEC weiterentwickelst

Danke

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

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

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