DEC: fehlerhafte Hashwerte unter C++

[Muetze1]

Hallo negaH und alle anderen!

Wir nutzen die DEC Library nun schon vielfältig und oft, da sie einfach ein sehr gutes Werk ist, welches in vielen Bereichen verwendet werden kann. Bei uns ist ein gemischtes System in Benutzung, also C++ und Delphi gemischt. Von daher werden für Delphi Quellen auch entsprechende statische Librarys generiert. Dies dient u.a. der Erzeugung der .hpp Dateien als auch der LIB für den Linker. Wir haben mit vielen Delphi Bibliotheken kein Problem mit und hatten somit auch keine Bedenken bei der DEC. Die Lib ist nun schon eingebunden und bei meinem letzten Arbeitsauftrag bin ich damit auf die Nase gefallen. Hier hatte ich nun zum ersten Mal die DEC unter C++ genutzt, aber über einen Zwischenschritt von Delphi Code. Es ist eine fertige Bibliothek welche die DEC nur nutzt, u.a. zur Hash Generierung. Diese Library unter C++ genutzt bringt keine verwertbaren Ergebnisse. Nach mehrfachen debuggen etc. konnte ich den Fehler in der DEC nachweisen, welche mir unter C++ Programmen immer einen anderen Hash generierte von den gleichen Daten. Da das C++ Programm nur eine Bibliothek von mir nutzt, welche die DEC nutzt, war es einfach diese Bibliothek von mir mal in einem Delphi Programm aufzurufen und siehe da: Hashes stimmten immer.

Zusammengefasst folgendes Verhalten:

DEC Library direkt in Delphi Programm: richtiger Hash, mit jedem Prozessstart der gleiche
DEC Library direkt in C++ Programm: zufälliger Hash, während der Laufzeit konstant, mit jedem Prozessstart ein anderer
DEC Library indirekt* in einem C++ Programm: zufälliger Hash, während der Laufzeit konstant, mit jedem Prozessstart ein anderer

* indirekt bedeutet hierbei, das C++ Programm ruft eine Delphi Unit auf, welche die DEC aufruft.

Ich habe mal ein entsprechendes Projektsystem gebaut und angehangen um den Fehler zu verdeutlichen.

DEC.lib - die C++ Lib mit der DEC
Bug01a - Delphi Programm
Bug01b - C++ Programm mit direkten Aufruf
Bug01c - C++ Programm mit indirekten Aufruf

Genutzt wird hierbei RAD Studio 2007 mit allen Fixes und Updates.

Hier nochmal eine kurze Log mit den Aufrufen der Compilate:

Code:

Bug01a, erster Aufruf:

First attempt
hashing value 'test' with SHA384
hash value: 768412320F7B0AA5812FCE428DC4706B3CAE50E02A64CAA16A782249BFE8EFC4B7EF1CCB126255D196047DFEDF17A0A9

Second attempt
hashing value 'test' with SHA384
hash value: 768412320F7B0AA5812FCE428DC4706B3CAE50E02A64CAA16A782249BFE8EFC4B7EF1CCB126255D196047DFEDF17A0A9

Bug01a, zweiter Aufruf:

First attempt
hashing value 'test' with SHA384
hash value: 768412320F7B0AA5812FCE428DC4706B3CAE50E02A64CAA16A782249BFE8EFC4B7EF1CCB126255D196047DFEDF17A0A9

Second attempt
hashing value 'test' with SHA384
hash value: 768412320F7B0AA5812FCE428DC4706B3CAE50E02A64CAA16A782249BFE8EFC4B7EF1CCB126255D196047DFEDF17A0A9

Bug01b, erster Aufruf:

First attempt
hashing value 'test' with SHA384
hash value: 852DC1C54D632C2DE8D15BE4CFEABB730C1E18A47C6E28C8FFC96D93FB6EF4F6B947ECA11F2FD8B65A3BB62FDB71AD07

Second attempt
hashing value 'test' with SHA384
hash value: 852DC1C54D632C2DE8D15BE4CFEABB730C1E18A47C6E28C8FFC96D93FB6EF4F6B947ECA11F2FD8B65A3BB62FDB71AD07

Bug01b, zweiter Aufruf:

First attempt
hashing value 'test' with SHA384
hash value: 32EDC34544F5A47F121E3F2AE925D9EE5DEF3D5FD40ABE860F423B6C9926DDEAFCB4AE882BE394C791893066020BAE53

Second attempt
hashing value 'test' with SHA384
hash value: 32EDC34544F5A47F121E3F2AE925D9EE5DEF3D5FD40ABE860F423B6C9926DDEAFCB4AE882BE394C791893066020BAE53

Bug01c, erster Aufruf:

First attempt
hashing value 'test' with SHA384
hash value: FEEEB9B21A027909711598969183D2750A013B9BEAB5E16C73F395A721AF3FD0DF3339E849DB3E818476B8F58E70A33C

Second attempt
hashing value 'test' with SHA384
hash value: FEEEB9B21A027909711598969183D2750A013B9BEAB5E16C73F395A721AF3FD0DF3339E849DB3E818476B8F58E70A33C

Bug01c, zweiter Aufruf:

First attempt
hashing value 'test' with SHA384
hash value: 84A9B12CD17583412EEC5997DB11604B6696BE426C7F46CCD1CDCCAC33A5230885E4D57E24CD365D12BEDE98BE3C350F

Second attempt
hashing value 'test' with SHA384
hash value: 84A9B12CD17583412EEC5997DB11604B6696BE426C7F46CCD1CDCCAC33A5230885E4D57E24CD365D12BEDE98BE3C350F

Diese ist auch im Archive als output.log enthalten.

Hinweise:
- ich habe schon probiert O+/O-, was bei dir intern ja die Nutzung von ASM/Pascal umschaltet: keine Änderung
- die eingefügten $Z4 sind Pflicht, da RAD2007 Studio bei Delphi Quellen in einer C++ Programm/Library die Delphi Optionen teilweise nicht weitergibt, u.a. die Enum-Grösse, was dann zu falschen DCUs führt.

Grüße,
Thomas aka Muetze1 @ mikrocontroller.net aka Muetze1 @ delphipraxis.net ;-)

[Assertor]

Hi Thomas,

danke für den sehr gründlichen Bugreport. Ich habe es gerade mit der DEC 5.2 und D2009 nachvollziehen können. Bei MD5 als Hash tritt der Bug übrigens nicht auf!

Ich versuche jetzt mal zu sehen, welche Hash-Funktionen betroffen sind und woran es liegt.

Edit: Jetzt hab ich mal alle Hashfunktionen durchprobiert.

Ergebnis:

Zitat:

MD2: a/v im C++
MD4: ok
MD5: ok
RipeMD128: ok
RipeMD160: ok
RipeMD256: ok
RipeMD320: ok
SHA: ok
SHA1: ok
SHA256: ok
SHA384: fehlerhaft (C++)
SHA512: fehlerhaft (C++)
Haval128: EIntOverflow (C++)
Haval160: ok
Haval192: ok
Haval224: ok
Haval256: ok
Tiger: Unterschiedlich (aber pro Prozess gleicher Wert in C++)
Panama: ok
Whirlpool: ok
Whirlpool1: ok
Square: Unterschiedlich (aber pro Prozess gleicher Wert in C++)
Snefru128: Unterschiedlich (aber pro Prozess gleicher Wert in C++)
Snefru256: Unterschiedlich (aber pro Prozess gleicher Wert in C++)
Sapphire: ok

Fehlerquote also 7 aus 25.

Da scheinen also einige Hashfunktionen in C++ Probleme zu machen, an den Format-Conversions liegt es jedoch definitiv nicht.

Anmerkung an alle anderen Leser: Dies betrifft nur die Nutzung der DEC mit Borland C++ Builder.

Nachtrag 2:

Wenn ich den asm Code für die fehlerhaften Hashfunktionen auskommentiere, z.B. {.$DEFINE THash_SHA384_asm}, funktioniert der native Delphi Code.

Gruß Assertor

[Muetze1]

Hallo Assertor!

Das ist ja schonmal gut zu wissen, dass man das ganze mit dem nativen Code umschiffen kann. Ich verstehe aber wirklich nicht, wie der vom Delphi Compiler generierte Code - selbst wenn von Delphi Code aufgerufen - andere Ergebnisse bringt, nur weil ein anderer Linker das ganze zusammenpackt. Oder halt die CodeGear Panscher haben mal wieder einen Bug nur einseitig gefixt (sprich: DCU Erstellung klappt, OBJ Erstellung nicht). Ich habe sowas von die Nase voll mit den ganzen Streitereien mit CodeGear. Um deren Fehler nicht mehr zu haben zwingen sie einen immer wieder ständig neues Geld für neue Versionen auszugeben und legen alles erst auf eine Klage bezüglich Gewährleistungsansprüchen bei Software an. Es ist mehr als traurig - und zu guter Letzt wurden noch die Update Preise verdoppelt. Na herrlich...

Aber egal, darum geht es hier nicht. Vielen Dank schonmal für deine Erkenntnisse. Ich hatte zuvor noch keine Kenntnisse über die neue DEV v5.2, habe sie mir aber gerade mal geladen und were somit auch unseren DEC Stand mal updaten auf 5.2.

Ansonsten wäre vllt. ein Blick auf meinen weiteren Beitrag bezüglich der in der DEC enthaltenen LHSS Komprimierung (DEC: LHSS Komprimierung: Rückgabewerte unbrauchbar).

Nachtrag: wo ich gerade den EIntOverflow sehe: Wir haben bei uns fest definierte Compilereinstellungen welche für alle Projekte verbindlich sind. Unter anderen auch der Overflow und Range Check. Dieser ist immer und überall an und stösst bei der DEC in Bereich der Cipher sowie der LHSS Komprimierung mehrfach auf wenig Gegenliebe. Leider hat ein weiterer Bug im RAD2007 Studio den Effekt, dass Compilereinstellungen für den Delphi Compiler unter häufigen Umständen aus den Projektoptionen nicht dem Delphi Compiler übergeben werden im automatischen Build Prozess mit msbuild. Dadurch werden explizite Editierungen der DEC Quellen nötig (leider wie nun schon für das $Z4, also 4 Byte Enum Size) - welche wir/ich eigentlich vermeiden wollten bzw. möglichst gering halten wollten. Von daher wäre eine globale Abschaltung in der Ver.inc auch keine so gute Lösung, es wäre besser sie bei den Stellen abzuschalten innerhalb der Lib, wo gewollt mit Überläufen gerechnet wird. Somit ist zum einen sichergestellt: Ja, wissen um den Überlauf und der ist gewollt hier und gleichzeitig würde er an anderen Stellen aussteigen, wo dies definitiv nicht gewollt wäre. Das wäre mal eine wirklich gute Erweiterung der DEC, falls du da nochmal eine DEC 5.3 planst ^^.

Vielen Dank!
Grüsse,
Thomas

[Assertor]

Hi,

Zitat von Muetze1:

Das ist ja schonmal gut zu wissen, dass man das ganze mit dem nativen Code umschiffen kann. Ich verstehe aber wirklich nicht, wie der vom Delphi Compiler generierte Code - selbst wenn von Delphi Code aufgerufen - andere Ergebnisse bringt, nur weil ein anderer Linker das ganze zusammenpackt.

Ja, das ist mal wieder ein sehr merkwürdiges Verhalten - aber leider kein gänzlich neues Problem. Den Rest des Quotes lass ich mal unkommentiert und gehe gerne im persönlichen Gespräch drauf ein

Zitat von Muetze1:

Aber egal, darum geht es hier nicht. Vielen Dank schonmal für deine Erkenntnisse. Ich hatte zuvor noch keine Kenntnisse über die neue DEV v5.2, habe sie mir aber gerade mal geladen und were somit auch unseren DEC Stand mal updaten auf 5.2.

Siehst Du, hat auch was gutes

Zitat von Muetze1:

Ansonsten wäre vllt. ein Blick auf meinen weiteren Beitrag bezüglich der in der DEC enthaltenen LHSS Komprimierung (DEC: LHSS Komprimierung: Rückgabewerte unbrauchbar).

Schon getan.

Zitat von Muetze1:

es wäre besser sie bei den Stellen abzuschalten innerhalb der Lib, wo gewollt mit Überläufen gerechnet wird. Somit ist zum einen sichergestellt: Ja, wissen um den Überlauf und der ist gewollt hier und gleichzeitig würde er an anderen Stellen aussteigen, wo dies definitiv nicht gewollt wäre. Das wäre mal eine wirklich gute Erweiterung der DEC, falls du da nochmal eine DEC 5.3 planst ^^.

Das ist wirklich eine gute Anregung, gerade weil viele sich eben nicht so gut mit den Compileroptionen und deren begrenzten Reichweite auskennen. Ich nehm das mal in meine Liste auf. Wenn irgendwann sowieso eine Änderung ansteht, pack ich es mit rein.

Ich habe eben nochmal alle Hashes in C++ getestet: Diese funktionieren zu 100%, wenn der asm-Code deaktiviert wird. Die Overflow-Checks müssen dazu dann natürlich aus sein. Es liegt also wirklich am asm Code aus der DECHash.pas bzw. DECHash.inc - wo genau in den 3520 bzw. 28614 Zeilen ist mir im Moment auch nicht erklärbar.

Für alle anderen Leser: Als Bugfix also bei DEC 5.1 bzw. 5.2 & C++ Builder in der Datei DECHash.pas folgendes ändern:

Delphi-Quellcode:

type
  {all Hash Classes}
  THash_MD2             = class;  {.$DEFINE THash_MD2_asm} // q&d fix c++
  THash_MD4             = class;  {$DEFINE THash_MD4_asm}
  THash_MD5             = class;  {$DEFINE THash_MD5_asm}
  THash_RipeMD128       = class;  {$DEFINE THash_RipeMD128_asm}
  THash_RipeMD160       = class;  {$DEFINE THash_RipeMD160_asm}
  THash_RipeMD256       = class;  {$DEFINE THash_RipeMD256_asm}
  THash_RipeMD320       = class;  {$DEFINE THash_RipeMD320_asm}
  THash_SHA             = class;  {$DEFINE THash_SHA_asm}
  THash_SHA1            = class;
  THash_SHA256          = class;  {$DEFINE THash_SHA256_asm}
  THash_SHA384          = class;  {.$DEFINE THash_SHA384_asm} // q&d fix c++
  THash_SHA512          = class;
  THash_Haval128        = class;  {$DEFINE THashBaseHaval_asm}
  THash_Haval160        = class;  // Haval 160, 3 Rounds
  THash_Haval192        = class;  // Haval 192, 4 Rounds
  THash_Haval224        = class;  // Haval 224, 4 Rounds
  THash_Haval256        = class;  // Haval 256, 5 Rounds
  THash_Tiger           = class;  {.$DEFINE THash_Tiger_asm} // q&d fix c++
  THash_Panama          = class;  {$DEFINE THash_Panama_asm}
  THash_Whirlpool       = class;  {$DEFINE THashBaseWhirlpool_asm}
  THash_Whirlpool1      = class;
  THash_Square          = class;  {.$DEFINE THash_Square_asm} // q&d fix c++
  THash_Snefru128       = class;  {.$DEFINE THash_Snefru128_asm} // q&d fix c++
  THash_Snefru256       = class;  {.$DEFINE THash_Snefru256_asm} // q&d fix c++
  THash_Sapphire        = class;  {$DEFINE THash_Sapphire_asm}

Gruß Assertor

[Muetze1]

Hallo Assertor!

Vielen Dank nochmals für das nachvollziehen und die Fehlerfindung.

Grüße,
Thomas

[Assertor]

Hi,

Zitat von Muetze1:

Vielen Dank nochmals für das nachvollziehen und die Fehlerfindung.

Bitte gerne, keine Ursache! Ich danke Dir für das Berichten des Problems, denn nur so kann man die Qualität der Arbeit erhalten und verbessern.

Gruß Assertor

[Muetze1]

Moin Assertor!

Ich bin nun dabei die DEC v5.2 einzumischen in unser Repository und musste dabei feststellen, dass der von Torry ladbare DEC v5.2 Stand nicht mehr C++Builder kompatibel ist.

Bei den Ciphern wurde die class function Context als virtual abstract gekennzeichnet, im Gegensatz zu Hagen's vorheriger Version mit virtual und einem raise EAbstractError in der Implementation. Da C++ keine virtual static kennt erstellt der HPP Generator hierbei eine ungültige Quelle.

Bitte für die 5.3 Version neben den direkten RangeChecks dies so umstellen. Ich übernehme die DEC 5.2 damit erstmal angepasst.

Grüsse,
Thomas

/EDIT: Ich kann mich leicht entsinnen, dass dies schon eine Änderung in Absprache mit Hagen war, welche nicht aus seiner Lib war. Somit: bitte übernehmen, es kann schon eine Anpassung gewesen sein.

/EDIT2: Gleiches für TDECFormat, alle protected Methoden...

/EDIT3: Nochmals für TDECHash DigestSize & BlockSize

/EDIT4: Code Insight versagt bei dem unnamed Type in der DECHash FTransform. Könnte man dazu nicht einen Typ anlegen?

/EDIT5: Die Compilerkonfigurationsstatements welche nun neu eingefügt sind, wie z.B. RangeCheck error abschalten etc, sind z.T. wirkungslos, da sie vor der Inklude ver.inc angegeben wurden. Die Inklude hingegen setzt eine ganze Reihe von Compilerschaltern um. Dies widerstrebt allen Konfigurationsmöglichkeiten im Projekt. Wir definieren sowas definitiv im Projekt und von daher: könnte man nicht zumindest aus der ver.inc diese Definitionsreihe rauswerfen?

/EDIT6: Zu Edit5: die Zeile ist schon auskommentiert und funktionslos. Mein Fehler - verwirrt aber...

/EDIT7: In der CPU.pas wird der Typ Comp benutzt, welcher nur in Delphi verfügbar ist. Im C++Builder gibt es dafür keine Entsprechung. Könnte ein anderer Typ dafür verwendet werden?

Zitat von RAD2007:

[DCC Warning] CPU.pas(115): W1025 Unsupported language feature: 'Comp'

/EDIT8: Und hier nochmal die DECHash.pas mit den Definitionen. Ich habe das ganze nun an den BCB Compiler Define gebunden.

Delphi-Quellcode:

type
{all Hash Classes}
  THash_MD2             = class;  {$IFNDEF BCB}{$DEFINE THash_MD2_asm}{$ENDIF}
  THash_MD4             = class;  {$DEFINE THash_MD4_asm}
  THash_MD5             = class;  {$DEFINE THash_MD5_asm}
  THash_RipeMD128       = class;  {$DEFINE THash_RipeMD128_asm}
  THash_RipeMD160       = class;  {$DEFINE THash_RipeMD160_asm}
  THash_RipeMD256       = class;  {$DEFINE THash_RipeMD256_asm}
  THash_RipeMD320       = class;  {$DEFINE THash_RipeMD320_asm}
  THash_SHA             = class;  {$DEFINE THash_SHA_asm}
  THash_SHA1            = class;
  THash_SHA256          = class;  {$DEFINE THash_SHA256_asm}
  THash_SHA384          = class;  {$IFNDEF BCB}{$DEFINE THash_SHA384_asm}{$ENDIF}
  THash_SHA512          = class;
  THash_Haval128        = class;  {$DEFINE THashBaseHaval_asm}
  THash_Haval160        = class;  // Haval 160, 3 Rounds
  THash_Haval192        = class;  // Haval 192, 4 Rounds
  THash_Haval224        = class;  // Haval 224, 4 Rounds
  THash_Haval256        = class;  // Haval 256, 5 Rounds
  THash_Tiger           = class;  {$IFNDEF BCB}{$DEFINE THash_Tiger_asm}{$ENDIF}
  THash_Panama          = class;  {$DEFINE THash_Panama_asm}
  THash_Whirlpool       = class;  {$DEFINE THashBaseWhirlpool_asm}
  THash_Whirlpool1      = class;
  THash_Square          = class;  {$IFNDEF BCB}{$DEFINE THash_Square_asm}{$ENDIF}
  THash_Snefru128       = class;  {$IFNDEF BCB}{$DEFINE THash_Snefru128_asm}{$ENDIF}
  THash_Snefru256       = class;  {$IFNDEF BCB}{$DEFINE THash_Snefru256_asm}{$ENDIF}
  THash_Sapphire        = class;  {$DEFINE THash_Sapphire_asm}

[Assertor]

Hi Muetze,

erstmal Danke für die ganzen Hinweise zur DEC!

Vieles ist ja schnell umgesetzt, besonders das mit den Includes und Projektoptionen ist natürlich ärgerlich aber schnell gelöst. Dies war direkt aus der DEC 5.1 übernommen, es handelte sich bei der 5.2 ja nur um einen D2009 Port, jedoch kein Code-Audit oder Rewrite.

Ich werde mir das ganze einmal gründlich ansehen und entsprechend in die DEC 5.3 einfliessen lassen. Problematischer sind da schon die EIntOverflows die ich stellenweise erhielt, da muß ich Rücksprache mit Hagen halten.

Gruß Assertor

[Luckie]

Schreibt Hagen mal eine PN damit er auf das Problem aufmerksam wird, da er hier nicht unbedingt regelmäßig vorbeiguckt.

[Muetze1]

Zitat von Luckie:

Schreibt Hagen mal eine PN damit er auf das Problem aufmerksam wird, da er hier nicht unbedingt regelmäßig vorbeiguckt.

Assertor pflegt die DEC doch offiziell weiter, soweit ich das verstanden habe...