Unnamed-Projekt > BigInt, MD5, RipeMD320, SHA, Streams usw.

[himitsu]

Also, wie Versprochen hier mal die ersten Teile meines kleinen Projekes.

es wird mal 'ne Art nonVCL-Framework und benötigt keine Fremdkomponenten/-Units und es werden auch nur die nötigsten Delphi-Units benötigt (per Standard nur System, SysInit und SysConst)

* das ganze Projekt ist auf Minimalismus ausgelegt,
also es wird niemals so groß wie z.B. die JEDIs, aber es soll das "Nötigste" enthalten
außerdem wird auf minimalsten Speicherverbrauch/Overhead geachtet
* es ist aktuell in einen Debugmodus versetzt und auch die Inlinefunktionen sind deaktivert
* alte/neue Demo-/Testprojekte liegen im Unterverzeichnis "Demo"
und in der Project.dpr befinden sich aktuelle Test-/Democodes zur TBigInt
* speziell in der FMath.pas sind noch unfertige Funktionen drin ... einfach mal nach "///" ausschau halten, außerdem wird bei Verwendung der entsprechende Funktionen eine Exception ausgelößt.

!!! Achtung: Vorraussetzung ist mindestens:
- BDS 2006, Delphi 2006, Turbo Delphi (incl. Updates)
- Windows 2000 Professional oder Neuer


"wichtige" aktuell enthaltene Elemente:

• FVersionsCheck.inc
  Delphi-Versiontests
  Optionen (alternativ über Delphiprojektoptionen)
  > Userdefinitionen im Abschnitt "Private" (ab Zeile 705) und Beschreibungen siehe nachfolgenden Abschnitt
• FType.pas
  (Basis)Typendefinitionen
• FBinary.pas
  ByteSwap, BitSwap, RoL, RoR, OpenBit(MSB), CloseBit(LSB), CountBits, OneBit(MSB+LSB)
  Swap(Speicher tauschen), FindData(binärdaten suchen)
• FMath.pas
  TBigInt > 512 bit integer = -2^511 .. 2^511 - 1 = ±6.703e153
  'nen paar Zufallsfunktionen
• FStream.pas
  IStream > Windows IStream-Interface
  TnFileStream
  TnMemoryStream
  TnMemoryMappedStream
  TnIStream > IStream-Kapselung
  TnStream > TnFileStream + TnMemoryStream + TnMemoryMappedStream
• FHash.pas
  Windows MD5- und SHA-API
  ThMD5 > Kapselung der WinAPI
  ThSHA > Kapselung der WinAPI
  ThxCRC32Table > CRC32-Rechentabelle
  ThxCRC32 > CRC32-"Klasse"
  ThxMD5 > MD5-"Klasse" (16 Byte)
  ThxRMD320 > Ripe MD320-"Klasse" ('ne Art 40 Byte-MD5)
• FResXPMan.pas
  XP-Manifest
• FResXPManAdmin.pas
  XP-Manifest mit Anforderung von Adminrechten

viele "Klassen" bauen auf Records auf ... können also wie jede "billige" Variable verwende werden
(also ohne Initialisation/Finalisation) und kommen vorallem ohne jeglichen Ovehead seitens der Objektverwaltung aus.
z.B.

Delphi-Quellcode:

Var Hash: ThMD5;
  S: String;

Begin
  Hash.Init;
  Hash.Update('123');
  Hash.Final;
  S := Hash.asHexString;

  Hash.Calc('123');
  S := Hash.asHexString;

  Hash.CalcFile('C:\Text.dat');
  S := Hash.asHexString;

  // oder gleich direkt
  S := Hash.CalcFile('C:\Text.dat').asHexString;
End;

RAM-Verbrauch von z.B. ThxCRC32 und TnFileStream liegen bei genau 4 Byte ... halt genau die Recordgröße (exclusive des Verbrauchs enthaltener Windowskomponenten)

Speziell auf sowas wie TBigInt und das zukünftige TBigFloat hat der Aufbau als Record große positive Auswirkungen, denn

• Speichermanagement optimal gelöst (meißt liegt die Variable direkt im Stack, oder auf'm Heap)
  also vom Typ selbst gehen keine Anfagen an den Memorymanager und Dergleichen
• die Variableninhalte liegen direkt in anderen Stuckturen (z.B. Records und Arrays) eingebettet
  > es gibt keine externen Daten über Pointer und so.
  = perfekt für Speicherung und Datenübertragung
  (z.B. von normalen Strings kennt man es ja, daß dessen Daten woanders liegen, als die Stringvariable)

[neu]
aktueller Funktionsumfang von TBigInt:

automatische/implizite Konvertierung
von: Integer, Int64, String
nach: Integer, Int64, Float(Extended), String

explizite Konvertierung
von und nach: Int64, Integer, UInt64, LongWord/Cardinal, Currency, Extended, String

Vergleiche ( = <> < <= >= > )
mit: TBigInt, Int64, Integer, Currency, Extended, String

Operatoren ( + - * div mod and or xor )
mit: TBigInt, Int64, Integer, String

Operatoren2 ( inc dec + - not shl shr )

Record(Klassen)-Proceduren:
Load/Save: TBigInt, Int64, Integer, UInt64, LongWord/Cardinal, String, TnStream(TnFileStream,TnMemoryStream,TnMemoryMappe dSream)
MinBigInt/MaxBigInt (Konstanten)
Compare, Add, Subtract, Multiply, Divide, Modulus, DivMod
Power, LdExp(2), LtExp(10), LxExp, ExpMod, Log2 Log10, LogN, Radic, Sqr, Sqrt,
Fibonacci, RoundTo
bAnd, bOr, bXor, bNot
Inc, Dec, Abs, NegAbs, Negative
bShl, bShr, Rol, Ror, aShl, aShr
Sign, isZero, isPositive, isNegative, isOdd, isEven,
OpenBit(MSB), CloseBit[LSB], CountBits, OneBit[MSB+LSB]

[u]Record(Klassen)-Properties:[u]
asString, asStringT(with thousands separator), asHexString

> meißt sollte Byte und Word auch mit durch Integer abgearbeitet werden können
[/neu]

[new]
die TBigInt gibt es inzwischen auch einzeln (unabhängig von diesem Projekt)
siehe Beitrag #13
[/new]




und dann noch ein Problem:
erstmal ist mir noch kein Name dafür eingefallen ... falls also wer eine Idee hat ...

Geschichte:
dieses Projekt ist 'ne Neuauflage meines nie veröffentlichten UCCs,
ist allerdings nicht mehr vorrangig auf Unicode ausgelegt
und soll dafür eine nette Win-API-Kapslung inlc. einiger nonVCL-Objekte, welche hoffentlich den Zugriff erleichtern, werden.
Und dazu kommt noch 'ne kleine Funktions/Objektsamung hinzu (z.B. TBigInt und Co.)


Lizenz: da fast alles von mir selber ist, liegt das Copyright wohl auch bei mir
außer wo es explizit im QuellCode, bei den entsprechenden Funktionen, dabei steht

die Grundlagen zur FBinary.BitSwap (speziell von BitSwap(i: LongWord): LongWord; ) hatte ich mal hier aus dem Forum, weiß aber nicht mehr von wem ... wäre schön, wenn sich dazu die Person wieder anfinden würde, damit ich diese erwähnen kann)


[add 22.01.2009]
die Hashfunktionen wurden etwas überarbeitet
siehe Beitrag #18
- Delphi 2009 Kompatibilität
- als Einzeldatei verwendbar
(Achtung: in diesem Post wurde die Delphi 2009-Änderungen noch nicht geupdatet)
[/add]

[himitsu]

So, 's wurde noch was zur TBigInt hinzugefügt:
Log2
Log10
LogN
Sqrt
Radic (Wurzelziehen/Radizieren mit belibiger Potenz)
Fibonacci
(Test- und Democodes aktuell in Project1.dpr)

Außerdem hab ich die Typenumwandlung (Implicit/Explicit) etwas überarbeitet

und es gibt jetzt eine explizite Typenumwandlung von Extended nach TBigInt.
(mit dem normaltem "Trunc" brauchte man ja bei Zahlen größer Int64 garnicht erst anfangen :roll: )

Delphi-Quellcode:

I := TBigInt(E);

wobei nur die ersten 18/19 Stellen des Ganzzahlaneiles übernommen und der Rest mit 0 gefüllt wird.

folgendes Testschleifchen befindet sich noch in der Project1.dpr

Delphi-Quellcode:

E := 0.123;
For i5 := -3 to 100 do Begin
  I := TBigInt(E);
  S := I.asString;
  If (E > 0) or (S <> '') Then ;

  E := E * 10;
End;

Zitat:

Ergebnis: (Extended = TBigInt)
0.123 = 0
1.23 = 1
12.3 = 12
123 = 123
1230 = 1230
12300 = 12300
...
1.23e11 = 123000000000
...
1.23e50 = 12300000000000000000000000000000000000000000000000 0
...


-----------------

123456789012345678901234567890000000 = 1.2345678901e35 = 123456789012345679000000000000000000

Dann hab ich (da sich wer über das LongInt-geeiere "beschwert" hat) da auch mal was umgestellt und dieses Problem in eine kleiner Ecke verschoben.
Nur nett, daß ich gestern dieses in 'ner halben Stunde fertig hatte und heute nochmal 2 Stunden den dadurch enstandenn Rechenfehler suchen durfte ... was so ein Vorzeichen alles bewirkt :wall:

Und man kann jetzt auch endlich Vergleiche mit Extended durchführen ( < > <= >= = ......) ... ging vorher mangels passender Typenumwandlung nicht.


Neue Version + kleine Ergänzung (siehe [neu]) im ersten Post.

[gammatester]

Ich denke, Dein CRC32 ist nicht Standard wg 'State := not ByteSwap(State)' bzw. dem ASM code in ThxCRC32.Final. Ich kann es aber nicht testen, da ich nicht verstehe, wie ich ThxCRC32 fehlerfrei benutzen soll:

Die ThxCRC32.CalcFile öffnet das File, kommt aber nicht in die While ReadFile Schleife. OK, ich habe nur D10 Kommandozeilen-Compiler unter Win98 (kann also nicht debuggen, und unter D6 läuft's nicht). Aber selbst das folgende Testprogramm liefert immer 0.

Delphi-Quellcode:

{$apptype console}
program cc;
uses
  sysutils,fhash;
const
  abc: array[0..2] of char = 'abc';
var
  hash: LongWord;
  crc: ThxCRC32;
begin
  CRC.InitT;
  Hash := CRC.Calc(pointer(@abc), 3);
  writeln(IntToHex(hash,8));
end.

Gruß Gammatester

[himitsu]

da ist wohl beim letzten Umstellen was untergegangen :oops:

es wird einfach nur der erechnete Hash nicht gespeichert :wall:

Delphi-Quellcode:

// in (Unit FHash)
Procedure ThxCRC32.Update(Input: Pointer; inLen: LongWord);

// nach
LOOP    @@Loop  // DEC &inLen;  JNZ @@Loop

// das einfügen
MOV     EDX, [ESP + 4]
MOV     [EDX], &Self

Die Ausgabe lautet nun c2412435.


Allerdings frag ich mich grad, warum .asHexString eine andere Reinfolge hat. :shock:


Also im alten Project (als Klasse) lief es noch und ich hatte den selben Hash raus wie Hagen's DEC :gruebel:
jetzt müßte ich nur noch wissen welche Werte korreckt sind ... hab hier grad keine Vergleichsmöglichkeit.

Delphi-Quellcode:

const
  abc: array[0..2] of char = 'abc';
var
  hash: LongWord;
  crc: ThxCRC32;

Begin
  CRC.InitT;

  hash := CRC.Calc(@abc, 3);
  WriteLn(IntToHex(hash, 8));
  WriteLn(CRC.asHexString);

  CRC.CalcFile(ParamStr(0), hash);
  WriteLn(IntToHex(hash, 8));

  ReadLn;

Zitat:

c2412435
5342142c
4b89e4f1

errechnet mit Standard-Polynom $EDB88320



Und was ThxCRC32.CalcFile bei dir hat, kann ich so nicht nachvollziehen ... hier läuft es jedenfalls und beim Debuggen bin ich auch in die Schleife reingekommen.


[add]
so, in den anderen Hashs ist auch der Wurm drin.

Delphi-Quellcode:

const
  abc: array[0..2] of char = 'abc';
var
  hash: FHash.MD5_DIGEST;
  md5_1: ThMD5;
  md5_2: ThxMD5;

Begin
  hash := md5_1.Calc(@abc, 3);
  WriteLn(md5_1.asHexString);

  hash := md5_2.Calc(@abc, 3);
  WriteLn(md5_2.asHexString);

  md5_1.CalcFile(ParamStr(0), hash);
  WriteLn(md5_1.asHexString);

  md5_2.CalcFile(ParamStr(0), hash);
  WriteLn(md5_2.asHexString);

  ReadLn;

Zitat:

900150983cd24fb0d6963f7d28e17f72
c5b151b6fe900681fedcba9876543210
ce3f7e686afa6a12b5e343c840d30afa
3fa5b06d57eeb9bf0000000000000000

Hier stimmt definitiv auch etwas nicht ... also ist aktuell von den Thx-Funktionen abzuraten.
Die ThMD5 und ThSHA sollten aber funktionieren.

[gammatester]

Also wie vermutet: Als 32-Bit-Integer kommt 352441c2 raus, da sind sich die meisten Programme einig. c2412435 kommt raus, wenn man die vier Bytes als Hexstring ausgibt. Was Dein asHex macht, weiß ich nicht.

Dein Programm liefert selbst unter Win2000 folgende Ausgabe

00000000
00000000
FFFFFFFF

Also wird das Problem wohl beim D10-Kdozeilencompiler liegen.

Dein Demoprogramme im Archiv kann ich nicht testen, da (bei mir) jede Menge Units fehlen, zB:
Project1.dpr(4) Fatal: F1026 File not found: 'FWinUI.dcu'

Im übrigen sind Testprgramme für alle/die meisten Funktionen für Regressiontest 'ne ganz brauchbare Sache :)

Gruß Gammatester

[himitsu]

stimmt, die FWinUI.pas und FWinUIClass.pas hatte ich noch weggelassen ... wär wohl besser dann beim Hochladen diese auch aus den Uses zu entfernen :nerd:

Zitat:

c2412435 kommt raus, wenn man die vier Bytes als Hexstring ausgibt. Was Dein asHex macht, weiß ich nicht.

stimmt auch, hab grad mal die alten UCC-Testdateien durchgekramt und da lief es ja noch ._.

Zitat:

Im übrigen sind Testprgramme für alle/die meisten Funktionen für Regressiontest 'ne ganz brauchbare Sache :)

ich schau mal, was sich machen läßt :angel2:

[himitsu]

ich hab mal schnell in Google gesucht und mir von da http://www2.cs.ucy.ac.cy/courses/EPL...test_tests.txt die Teststrings gemopst :angel2:


ThxCRC32 geht demnach wieder :firejump:
und der Rest folgt bestimmt auch bald.

hab mir das Ganze erstmal als kleines externes Testprojekt angelegt:

Delphi-Quellcode:

Program UnitTest;

{$APPTYPE CONSOLE}

Uses F_unknown, FType, FSecurity, FMemory, FBinary, FMath, FSystem,
  FFile, FStream, FHash;

{$INCLUDE FVersionsCheck.inc}

Var TestError: Boolean = False;

Procedure FHash_ThxCRC32Table;
  Const Test: ThxCRC32Table = (Data: ($00000000, $77073096, $ee0e612c, $990951ba, $076dc419, $706aF48F, $e963a535,
     $9e6495a3, $0edb8832, $79dcb8a4, $e0d5e91e, $97d2d988, $09b64c2b, $7eb17cbd, $e7b82d07, $90bF1d91, $1db71064,
     $6ab020F2, $F3b97148, $84be41de, $1adad47d, $6ddde4eb, $F4d4b551, $83d385c7, $136c9856, $646ba8c0, $Fd62F97a,
     $8a65c9ec, $14015c4F, $63066cd9, $Fa0F3d63, $8d080dF5, $3b6e20c8, $4c69105e, $d56041e4, $a2677172, $3c03e4d1,
     $4b04d447, $d20d85Fd, $a50ab56b, $35b5a8Fa, $42b2986c, $dbbbc9d6, $acbcF940, $32d86ce3, $45dF5c75, $dcd60dcF,
     $abd13d59, $26d930ac, $51de003a, $c8d75180, $bFd06116, $21b4F4b5, $56b3c423, $cFba9599, $b8bda50F, $2802b89e,
     $5F058808, $c60cd9b2, $b10be924, $2F6F7c87, $58684c11, $c1611dab, $b6662d3d, $76dc4190, $01db7106, $98d220bc,
     $eFd5102a, $71b18589, $06b6b51F, $9FbFe4a5, $e8b8d433, $7807c9a2, $0F00F934, $9609a88e, $e10e9818, $7F6a0dbb,
     $086d3d2d, $91646c97, $e6635c01, $6b6b51F4, $1c6c6162, $856530d8, $F262004e, $6c0695ed, $1b01a57b, $8208F4c1,
     $F50Fc457, $65b0d9c6, $12b7e950, $8bbeb8ea, $Fcb9887c, $62dd1ddF, $15da2d49, $8cd37cF3, $Fbd44c65, $4db26158,
     $3ab551ce, $a3bc0074, $d4bb30e2, $4adFa541, $3dd895d7, $a4d1c46d, $d3d6F4Fb, $4369e96a, $346ed9Fc, $ad678846,
     $da60b8d0, $44042d73, $33031de5, $aa0a4c5F, $dd0d7cc9, $5005713c, $270241aa, $be0b1010, $c90c2086, $5768b525,
     $206F85b3, $b966d409, $ce61e49F, $5edeF90e, $29d9c998, $b0d09822, $c7d7a8b4, $59b33d17, $2eb40d81, $b7bd5c3b,
     $c0ba6cad, $edb88320, $9abFb3b6, $03b6e20c, $74b1d29a, $ead54739, $9dd277aF, $04db2615, $73dc1683, $e3630b12,
     $94643b84, $0d6d6a3e, $7a6a5aa8, $e40ecF0b, $9309FF9d, $0a00ae27, $7d079eb1, $F00F9344, $8708a3d2, $1e01F268,
     $6906c2Fe, $F762575d, $806567cb, $196c3671, $6e6b06e7, $Fed41b76, $89d32be0, $10da7a5a, $67dd4acc, $F9b9dF6F,
     $8ebeeFF9, $17b7be43, $60b08ed5, $d6d6a3e8, $a1d1937e, $38d8c2c4, $4FdFF252, $d1bb67F1, $a6bc5767, $3Fb506dd,
     $48b2364b, $d80d2bda, $aF0a1b4c, $36034aF6, $41047a60, $dF60eFc3, $a867dF55, $316e8eeF, $4669be79, $cb61b38c,
     $bc66831a, $256Fd2a0, $5268e236, $cc0c7795, $bb0b4703, $220216b9, $5505262F, $c5ba3bbe, $b2bd0b28, $2bb45a92,
     $5cb36a04, $c2d7FFa7, $b5d0cF31, $2cd99e8b, $5bdeae1d, $9b64c2b0, $ec63F226, $756aa39c, $026d930a, $9c0906a9,
     $eb0e363F, $72076785, $05005713, $95bF4a82, $e2b87a14, $7bb12bae, $0cb61b38, $92d28e9b, $e5d5be0d, $7cdceFb7,
     $0bdbdF21, $86d3d2d4, $F1d4e242, $68ddb3F8, $1Fda836e, $81be16cd, $F6b9265b, $6Fb077e1, $18b74777, $88085ae6,
     $FF0F6a70, $66063bca, $11010b5c, $8F659eFF, $F862ae69, $616bFFd3, $166ccF45, $a00ae278, $d70dd2ee, $4e048354,
     $3903b3c2, $a7672661, $d06016F7, $4969474d, $3e6e77db, $aed16a4a, $d9d65adc, $40dF0b66, $37d83bF0, $a9bcae53,
     $debb9ec5, $47b2cF7F, $30b5FFe9, $bdbdF21c, $cabac28a, $53b39330, $24b4a3a6, $bad03605, $cdd70693, $54de5729,
     $23d967bF, $b3667a2e, $c4614ab8, $5d681b02, $2a6F2b94, $b40bbe37, $c30c8ea1, $5a05dF1b, $2d02eF8d));

  Var CRC32Tab: ThxCRC32Table;
    i: Integer;

  Label Exit;

  Begin
    WriteLn;
    WriteLn('********** FHash.ThxCRC32Table **********');
    WriteLn;
    CRC32Tab.CreateTable($EDB88320);
    For i := 0 to High(CRC32Tab.Data) do
      If CRC32Tab.Data[i] <> Test.Data[i] Then Begin
        TestError := True;
        WriteLn(WordToHex(CRC32Tab.Data[High(CRC32Tab.Data)]), '  [failed]  **********');
        Goto Exit;
      End;
    WriteLn(WordToHex(CRC32Tab.Data[High(CRC32Tab.Data)]), '  [passed]');
    Exit:
    WriteLn(WordToHex($2d02eF8d), '  CRC32Tab.Data[255]');
    WriteLn;
    WriteLn;
  End;

Procedure FHash_ThxCRC32;
  Const Test: Array[0..15] of String = (
    '00000000', '',
    '43beb7e8', 'a',
    'c2412435', 'abc',
    '7f9d1520', 'message digest',
    'bd50274c', 'abcdefghijklmnopqrstuvwxyz',
    'd2e6c21f', 'ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789',
    '724aa97c', '12345678901234567890123456789012345678901234567890123456789012345678901234567890',
    '2639f4cb', '123456789');

  Var CRC32: ThxCRC32;
    i: Integer;
    S, S2: String;

  Begin
    WriteLn;
    WriteLn('********** FHash.ThxCRC32 **********');
    WriteLn;
    CRC32.InitT;
    For i := 0 to High(Test) div 2 do Begin
      S := Test[i * 2 + 1];
      CRC32.Calc(PChar(S), Length(S));
      S2 := CRC32.asHexString;
      If S2 <> Test[i * 2] Then Begin
        WriteLn(S2, '  [failed]  **********');
        TestError := True;
      End Else WriteLn(S2, '  [passed]');
      WriteLn(Test[i * 2], '  ', Copy('"' + Test[i * 2 + 1] + '"', 1, 69));
      WriteLn;
    End;
  End;

Begin
//ThMD5
//ThSHA
  FHash_ThxCRC32Table;
  FHash_ThxCRC32;
//ThxMD5
//ThxRMD320
  WriteLn;
  WriteLn;
  WriteLn('******************************');
  WriteLn;
  If TestError Then WriteLn('one or more tests [failed]') Else WriteLn('all tests [passed]');
  ReadLn;
End.

Code:

********** FHash.ThxCRC32Table **********

2d02ef8d  [passed]
2d02ef8d  CRC32Tab.Data[255]



********** FHash.ThxCRC32 **********

00000000  [passed]
00000000  ""

43beb7e8  [passed]
43beb7e8  "a"

c2412435  [passed]
c2412435  "abc"

7f9d1520  [passed]
7f9d1520  "message digest"

bd50274c  [passed]
bd50274c  "abcdefghijklmnopqrstuvwxyz"

d2e6c21f  [passed]
d2e6c21f  "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789"

724aa97c  [passed]
724aa97c  "12345678901234567890123456789012345678901234567890123456789012345678

2639f4cb  [passed]
2639f4cb  "123456789"



******************************

all tests [passed]

neuer Anhang samt Textprojekt ist oben im ersten Post zu finden

[gammatester]

Den Link kannte ich noch gar nicht. Interessant ist, daß offensichtlich verschiedene Ausgabeformate darin vorkommen: CRC32 ist als LSB-First-Hexstring (wie Deine Ausgabe) und Adler-32 als Longint im IntToHex-Format.

Ansonsten geht's ja gut vorwärts bei Deinen Units :) Dies als positives Feedback, da ich offensichtlich bis jetzt der einzige bin, der die 7z-Archive runtergeladen hat.

Als weitere Anregung: Ich habe in meinen CRC/Hash-Units für jeden Algorithmus eine Selftest-Funktion eingebaut, damit können Benutzer (und ich nach Änderungen) schnell testen, ob die Implementation noch stimmt.

Viele Grüße
Gammatester

[gammatester]

Habe gerade selbst noch ein wenig gesucht und denke, daß Deine verlinkten Testwerte die Ausgabe von Wei Dai's Crypto++ Validierungs-Suite ist (jedenfalls kommen die Überschriften in den verschiedenen Testprogrammen vor).

Und siehe da, wenn man sich adler32.cpp/h und crc.cpp/h anschaut, findet man auch die Erklärung für die unterschiedliche Ausgabeformat für die 32-Bit-Werte.

Gruß Gammatester

[sx2008]

Warum sind denn so viele Deklarationen aus Unit Windows enthalten?
Schließlich vergrössert die Unit Windows eine Anwendung nicht (und wenn doch, dann nur unwesentlich).

[himitsu]

@gammatester: ich könnte es notfalls auch als ZIP hochladen, aber 7zip ist doch inzwischen kein ungewöhnliches Format mehr?

Wei Dai's Crypto++ Seite schau ich mir gleich mal an.

und was den Link betrifft: hatte einfach in Google gesucht und das war einfach eine der ersten Seiten, wo ich genug und hübsche Prüfmuster fand. :angel2:

deine weitere Anregung betreffend, hatte damals eigentlich nicht vor noch was an dieser Implementation zu verändern (ist zwar nicht die Schnellste, aber mir gefiehl sie so ganz gut) und sie lief auch eigentlich.
nja, direkt in die Projektdateien mach ich die Prüffunktionen wohl nicht rein, aber ich werd' mein kleines Prüfprogrämmhen weiter ausbauen (vielleicht mal mit 'ner übersichtlichen GUI).
Im Endefekt wird ja kaum mal was geändert, wenn es einmal läuft ... wird also vermutlich nicht häufig genutzt.

Zitat:

Zitat von sx2008

Warum sind denn so viele Deklarationen aus Unit Windows enthalten?
Schließlich vergrössert die Unit Windows eine Anwendung nicht (und wenn doch, dann nur unwesentlich).

Da ich Erstens alles zusammen haben wollte,

Zweitens einige Änderungen gegenüber den Delphi-Deklarationen drin hab ... es ist mehr am MSDN ausgerichtet und außerdem hat Delphi einige Fehler drin (vorallem beim Unicode)

und Drittens hab ich (versuch es zumindestens) die aktuellsten Definitionen zu nutzen.
in Delphi ist noch nichtmal alles vom XP drin ... ich bin da nur auf'm Stand des WinSDK v6.1 (Windows Vista / Windows Server 2008)

oder was glaubst du warum noch andere WinAPIs für Delphi anbieten?
(z.B. die ganzen JEDI-APIs ... ich sortiere es nur etwas anderes und passe es noch etwas ans Projekt an)

Aber vorallem hab ich versucht alles loszuwerden, was 'nen Initialization-/Finalizationabschnitt enthält ... ich weiß, Windows.pas ist noch recht harmlos, aber wenn man einmal nicht konsequent ist ......... :angel:




so, das kleine Testprojekt läuft erstmal.
jetzt muß ich nur noch die Fehler in ThxMD5 und ThxRMD320 finden :?

tja und dann sollte ich mir noch ein paar Prüfmuster für BigInt und Co. einfallen lassen :stupid:

[himitsu]

Sooooo, der Fehler in den Hashfunktionen hat sich angefunden ... mußte mal ein Backup zurückspielen und da fehlten noch die damals aktuellen Änderungen (die Adressen zu den neuen Varialenpositionen waren nicht mehr angepaßt)

tja und beim Filehash hatte sich ein witziger Fehler eingeschlichen ... "Final" wurde dopelt ausgeführt :shock:


neue Dateien und kleine Ergänzung ( [neu] ) siehe ersten Post

und hier im Anhang nicht wundern ... die 5 Fehlermeldungen sind korrekt, schließlich fehlt die Testdatei für jeweils den ersten Filehashtest. (oben im Pojekt ist aber alles drin)

[himitsu]

Aufgrund des Themas
Exponentieren und dann Modulo: große Zahlen - speziell die Beiträge #30 bis #33
hab ich mal die BigInt-"Klasse" extrahiert.

Systemvoraussetzung ebenfalls mindestens Delphi/BDS 2006 incl. der nötigen Updates.

Wertebereich:
von -6.703.903.964.971.298.549.787.012.499.102.923.063. 739.682.910.296.196.688.861.780.
721.860.882.015.036.773.488.400.937.149.083.451.71 3.845.015.929.093.243.025.426.876.941.405.973.284. 973.216.824.503.042.048
bis +6.703.903.964.971.298.549.787.012.499.102.923.063 .739.682.910.296.196.688.861.780.
721.860.882.015.036.773.488.400.937.149.083.451.71 3.845.015.929.093.243.025.426.876.941.405.973.284. 973.216.824.503.042.047
+/- 6.703e153
-2^511 .. 2^511 - 1

512 Bit im Zweierkomplement = 152(153) Dezimalstellen
Int64 = 18(19) Dezimalstellen


die Klasse ist fast identisch mit dem Original
- Funktion .OneBit fehlt (braucht aber vermutlich eh keiner)
- TnStream durch TStream ersetzt
- interne Funktionen auf Private gesetzt
- keine ASM-Optimierungen (gibt aber eh kaum welche)
- und es wird natürlich nur diese eine Unit benötigt


Vieles wie beim "normalen" Integer auch nutzbar:

< <= = <> >= >
+ - div mod
and or xor not shl shr
Inc Dec

und als Funktionen in der Klasse und einiges nochmals als Einzelfunktion in der Unit (siehe nach der Klassendefinition) unter Anderem dieses:
DivMod Power LdExp LtExp LxExp ExpMod Log2 Log10 LogN Radic Sqr Sqrt Fibonacci RoundTo RoL RoR



da dieses einen "normalen" Record darstellt, ist auch keine Initialisierung/Finalisierung nötig, wie z.B. bei Objekten.
und man kann diesen Record auch wie einen verwenden ... z.B. Speichern und Laden:

Delphi-Quellcode:

Var BI: TBigInt;
  F: File...;
  S: TStream;
  P: Pointer;

BlockWrite(f, BI, SizeOf(BI));
S.Write(BI, SizeOf(BI));
MoveMemory(P, @BI, SizeOf(BI));

ich hoff mal es läuft alles soweit.
ansonsten wird es hiervon nicht all zu oft ein Update geben können.
(ist halt etwas Aufwand jede Änderung im großen Projekt auch gleich hier einzubauen)

[edit=Daniel G]Wertebereich zum Vermeiden des horizontalen Scrollens mal umgebrochen. Tut ja nicht not, sowas...[/edit]

[vsilverlord]

Gibt es eine Möglichkeit, die Unit auch unter Delphi 7 enterprise zu nutzen? :|

[himitsu]

so wie sie jetzt ist, leider nicht (mein altes D7 fühlt sich auch schon etwas vernachlässigt :( )

Es wird halt von erst in Delphi 2006 eingeführten Compilerfeatures gebrauch gemacht.


ich könnte höchstens die Grundfunktionalität in externe Funktionen/Prozeduren umwandeln, dann könnte der Integer weiterhin ein Record bleiben,
nur läßt sich dieser record dann nicht mehr, wie ein "normaler" Integer, direkt in Formeln verwenden (also nur noch per Prozeduren zu berechnen)

oder als Objekt, aber dann wären wieder die schönen Recordeigenschaften weg
und ebenfalls wäre dieses nicht mehr direkt in Formeln zu verwenden.


vielleicht werd' ich den Nachfolger "TScaleInt" mal in eine alternative Klasse umwandeln,
dann ließe diese sich (zwar etwas eingeschränkt) auch in älteren Delphiversionen einsetzen.


@vsilverlord: du kannst dir aber auch ganz einfach mal Turbo Delphi (aka "abgespecktes Delphi 2006") ansehn ... dieses kennt auch die neuen Features :angel:



PS: TScaleInt und TBigFloat sind noch nicht fertig
TScaleInt = scalierbarer Integer
- mit allen eigenschaften eines Integers (also auch mit denen des TBigInt)
- dynamische Speicherverwaltung ... größe wächst mit dem Inhalt (wenn es sein muß, bis der RAM platzt)
(maximalgrößen wählbar)
- alle Dezimalstellen sind signifikant
- scalliert wird auf binärebene ... also im Dualsystem (es gibt aber Funktionen um die eingestellten Dualstellen in Dezimalstellen umzurechnen, oder zurück)
- es entspricht also in etwa dem Typ Currency


TBigFloat stellt einen vergrößerten Single/Double/Extended dar und hat demnach auch deren Eigenschaften

[vsilverlord]

ok danke für die Antwort. Eigentlich möchte ich mein Delphi 7 behalten, aber ich hab jetzt schon so lange an dem Projekt gearbeitet, dass es nicht daran scheitern soll, nur weil ich zu faul bin mir ein anderes Delphi zu holen. Vielleicht lade ich es nur für dieses eine Projekt runter :?
:pale:

[himitsu]

Zum Glück ist ja TurboDelphi nicht sooo teuer :stupid:


und die Sache mit TScaleInt kann noch etwas dauern ... häng noch etwas an der Recordvariante fest (und erst wenn es ferig ist, dann leite ich frühestens 'ne Klasse davon ab)

[himitsu]

hatte zwar noch keine Zeit BigInt und Co. fertigzustellen,

aber die Hashfunktionen würden etwas überarbeitet
siehe Beitrag #16 in CRC32 für einzelne Wörter!
- Delphi 2009 Kompatibilität
- als Einzeldatei verwendbar
(Achtung: im ersten Post wurde die Delphi 2009-Änderungen noch nicht geupdatet)

[schwa226]

Hi,

ich habe nun hier die "FHash_single" probiert:

Delphi-Quellcode:

procedure TForm1.Button1Click(Sender: TObject);
var
  MD5 : ThMD5;
  s : String;
begin

  MD5.Calc('123');

  S := MD5.asHexString;
end;

Bei einem Online-Calc kommt das raus: 202cb962ac59075b964b07152d234b70
Bei D2010: 5fa285e1bebe0a6623e33afc04a1fbd5

Was mache ich falsch?

[jfheins]

Dein Delphi-String ist Unicode, der Online-Calc benutzt vermutlich ASCII ;)

[himitsu]

Delphi-Quellcode:

Type ThxMD5 = packed Record
  Function Calc(Const Input: AnsiString): ThxMD5; Overload;
  Function Calc(Const Input: WideString): ThxMD5; Overload;

Jupp, standardmäßig sind der Typ String und auch die Stringkonstanten ab Delphi 2009 als UnicodeString definiert,
welches natürlich Aufgrund der anderen binären Entsprechnung auch ein anderes Ergebnis liefert.

Delphi-Quellcode:

A := '123';  // A = AnsiString
S := MD5.Calc(A).asHexString;

S := MD5.Calc(AnsiString('123')).asHexString;

Einfach so den UnicodeString dann intern auf Ansi zu mappen, nur damit es bei so einfachen Dingen keine Probleme gibt, ist leider keine Lösung, da dann ja eventuell Unicodeinformationen verloren gehen und der Hash eines UnicodeStrings dann falsch wäre.

[Mithrandir]

Ich war mal so frei, hier den Wertebereich "umzubrechen". Horizontal scrollen zu müssen ist nicht wirklich schön. ;)

[KFAF]

Ich weiß, der Thread ist tot. Aber falls jemand hierher kommen sollte:

Man kann die Record-Klasse für BigInteger unter Delphi XE3 (wahrscheinlich auch schon ab XE) nur nach geringfügigen Modifikationen nutzen.

1. Operatornamen haben sich geändert :

Code:

ShiftLeft -> LeftShift
ShiftRight -> RightShift
BitwiseNot -> LogicalNot

2. Obwohl jetzt Unicode den Ton angibt, funktionieren die String-basierten Funktionen alle. Einzig die Funktion "_ToString" muss modifiziert werden - das Inkrement kann nichts zuweisen, da die Byte-Umwandlung nur Zeiger aus AnsiChars machen kann.

[himitsu]

Code:

ShiftLeft -> LeftShift
ShiftRight -> RightShift

Wer ist denn auf diese komische Idee gekommen, das einfach umzubennen? :shock:

Code:

BitwiseNot -> LogicalNot

Wobei ich hier noch nie vewrstanden hab, warum es in Delphi binäre und logische Operatoren gibt, da man das in Delphi nicht angeben kann.
(hier wird ja via Typ unterschieden, also bei boolischen Typen wird "normalerweise" logisch gearbeitet und sonst binär)

Also im Prinzip ist es nun falsch, da es sich nicht um einen boolischen Typ handelt.

[Bbommel]

Hallo zusammen,

ich muss hier auch noch mal gerade dieses tote Pferdchen reiten. :)

Ich nutze die MD5-Funktionalität aus der fhash-Unit seit Jahren, um einen Hash für Passwörter zu generieren (vielen Dank an himitsu dafür noch mal). Nun gibt es bestimmte Gründe, warum auch eine 64-Bit-Version meiner Anwendung sinnvoll sein kann (vor allem der Speicherbedarf in wenigen Ausnahmefällen), was sich auch überwiegend problemlos compilieren ließ. Nur an der fhash-Unit scheitert es, weil dort magischer Kram mit Assembler angestellt wird, der so unter 64-Bit nicht mehr geht.

Anweisungen wie

Code:

      ADD     EAX, [ECX * 4 + @@DataX]

führen dann zum Fehler "E2577 Für Assembler-Anweisung ist ein absolutes 32-Bit-Adressen-Fixup erforderlich. Dies ist für 64 Bit ungültig".

Bei Assembler bin ich leider völlig raus. :-( Daher habe ich leider keine Ahnung, wie und ob man überhaupt diese Stellen fixen kann. Hat das schon mal irgendwer gemacht?

Das Problem für mich ist: prinzipiell könnte ich auch auf die Unit IdHashMessageDigest von den Indys und die Klasse TIdHashMessageDigest5 umsteigen, welche unter 32- und 64-Bit problemlos funktionieren. Leider liefert TIdHashMessageDigest5 ein anderes Ergebnis als fhash. Ein bisschen ausprobieren ergab, dass das wahrscheinlich durch die unterschiedlichen String-Typen (ANSI vs. Unicode) kommt (bei Interesse gerne mehr dazu), aber letztlich hilft mir das ja nicht weiter. Nun ist mir ja eigentlich egal, ob der Hash-Wert nun "richtig" oder "falsch" ist, Hauptsache, es ist in meiner Anwendung immer gleich - daher bin ich ein Stück weit an die fhash mit ihrem "falschen" Ergebnis gebunden.

Es wäre auch eine mögliche Alternative, den Kunden, die mein Programm mit einer Benutzerverwaltung mit Passwörtern benutzen (was nur ein kleiner Teil der Anwender insgesamt ist) zu erklären, dass sie ihre Passwörter neu anlegen müssen. Aber dazu müsste ich natürlich wissen, ob sich das lohnt...

Hat also zufällig schon mal jemand den Assembler für 64-Bit fit gemacht oder kennt eine "Faustformel" wie ich das selber machen könnte?

Bis denn
Bommel

[Sir Rufo]

Einfach http://docwiki.embarcadero.com/Libraries/de/System.Hash verwenden :stupid:

[Bbommel]

Huch. Von diesem ganzen neuen Kram muss einem aber auch mal einer was sagen ;) - vielen Dank!

Leider hilft mir das insofern nicht weiter, weil es auch den gleichen MD5-Hash liefert wie die Indy-Funktion (und im übrigen auch ein Online-MD5-Tool) - also wohl den richtigen Hash.

Wahrscheinlich ist es am besten, einmal in den sauren Apfel zu beißen und die Kunden, die das nutzen, einmal zu bitten, ihre Passwörter neu zu vergeben. Ist ja eigentlich quatsch, aus Kompatibilitätsgründen eine Funktion mitzuschleppen, die ein eigentlich falsches Ergebnis liefern soll.

[Sir Rufo]

So ein Hash wird immer von einer Handvoll Bytes errechnet. Wenn du da einen string reingibst, dann wird der in eine Bytefolge zerlegt und davon der Hash ermittelt.

Du könntest also versuchen über

Delphi-Quellcode:

TEncoding.GetBytes

die Bytefolge für den string mit ANSI-Encoding zu holen und davon den Hash zu errechnen.

[himitsu]

Im Notfall dem gespeicherten Hash ein Prefix/Kennung mitgeben, womit gehasht wurde, da kannst du dann mehrere Verfahren parallel laufen lassen und auch "alte" Hashs unterstützen.

Bei MD5/SHA1 bin ich zum Schluß dazu übergegangen die API der crypt32.dll zu kapseln/nutzen.

[Bbommel]

Hier die Auflösung, vor allem, falls später noch mal jemand drüber stolpert. Das Verhalten der alten fhash-Unit kann man nachstellen, indem man an die neue Funktion aus der system.hash nicht direkt den String übergibt, sondern ihn sozusagen als Byte-Folge mitgibt. Hier ein Beispielprogramm, in welchem der Aufruf der "alten" FHash-Funktion und der bei Delphi jetzt mitgelieferten das selbe Ergebnis liefern:

Delphi-Quellcode:

uses
  System.SysUtils,
  FHash_single,
  System.Hash;

var md5: ThxMD5;
    md5system: THashMD5;
    md5_Fhash: string;
    md5_system: string;
    inStr: String;

begin
  try
    { TODO -oUser -cConsole Main : Code hier einfügen }
    inStr:=ParamStr(1);
    md5.Init;
    md5.Update(inStr);
    md5.Final;
    md5_Fhash:=md5.asHexString;

    md5system.Reset;
    md5system.Update(inStr[1],Length(inStr)*2);
    md5_system:=md5system.HashAsString;

    writeln('md5 Fhash_single: '+md5_Fhash);
    writeln('md5 System      : '+md5_system);
    writeln;
  except
    on E: Exception do
      Writeln(E.ClassName, ': ', E.Message);
  end;
end.

Während die Funktion aus Fhash (hier: fhash_single) immer mit zwei Bytes pro Buchstabe arbeitet, so scheint es mir bei dem richtigen Hash so zu sein, dass zumindest die abschließenden 0-Bytes abgeschnitten werden. Wenn man nun also die neue Funktion zwingt, auch immer zwei Bytes zu nehmen, dann funktioniert es.

Danke für eure Anregungen!

Bis denn
Bommel

[himitsu]

Das ist aber kein Fehlverhalten der Hashfunktion.

Ich selber wandle Strings inzwischen grundsätzlich immer nach UTF-8 und hashe diesen String dann, somit ist überall das Ergebnis gleich.
Ob man nun ANSI (Eine der vielen CodePages), UTF-8 oder Unicode (UTF-16) hasht, vom Ergebnis muß das andere Werte liefern, sonst ist die Hashfunktion ja kaputt, wenn sie bei unterschiedlichen Byte-Folgen gleiche Ergebnisse liefert. :stupid:

In deinem Fall, also als Unicode (UTF-16) und dann hashen, egal mit welcher Funktion, und alles kann so bleiben :angle:
oder ein anderer "Daten"-Format und dann ist es auch egal welche Hashfunktion du nutzt.

[Bbommel]

Jo, ich hatte in meinem ersten Post "richtig" und "falsch" bewusst noch in Anführungszeichen gesetzt, weil mir schon klar war, dass es nicht wirklich richtig oder falsch ist, sondern darum geht, wie welche Bytes umgewandelt bzw. interpretiert werden. Das mit den Anführungszeichen war mir nachher nur zu lästig. ;)

Ich kam darauf, das eine Ergebnis als "richtig" zu bezeichnen, weil halt die Funktion von Indy, System.hash und PHP (bei einem Online-Tool ausprobiert) dieses Ergebnis lieferte ohne, dass man bewusst irgendwelche Umwandlungen einstellen musste. Am Anfang hatte ich auch einfach nur den Buchstaben "a" als Eingabe für die Funktionen genommen.

Nun habe ich ja für meine existierenden Daten eine Lösung gefunden und für die Zukunft finde ich das Umwandeln in UTF8 eine gute Idee - dann sollte es plattform- und sprachübergreifend ja den gleichen Hash geben.

[himitsu]

PHP und z.B. FreePascal/Lazarus arbeiten an den meisten Stellen mit UTF-8 und müssen bei Systemaufrufen konvertieren. Delphi seit 2009 vorallem mit UTF-16, womit bei WinAPIs oft weiterhin ein PChar-Cast reicht.
Nja, und ich, unerfahren, wie ich war, hatte damals, bei der 2009-Anpassung, die ANSI-Versionen so gelassen, wie sie waren, damit sie gleiche Ergebnisse liefern,
aber die WideString-Versionen als Unicode gehasht, so wie sie rein kommen.

[BUG]

Zitat:

Zitat von Bbommel (Beitrag 1330795)

Wahrscheinlich ist es am besten, einmal in den sauren Apfel zu beißen und die Kunden, die das nutzen, einmal zu bitten, ihre Passwörter neu zu vergeben. Ist ja eigentlich quatsch, aus Kompatibilitätsgründen eine Funktion mitzuschleppen, die ein eigentlich falsches Ergebnis liefern soll.

Dann hier der obligatorische Hinweis: Reine Hashingfunktionen sind zum Schutz von Passworten nicht zu gebrauchen!

Besser sind Schlüsselableitungsfunktionen wie: PBKDF2, bcrypt oder scrypt.
Bei den ersten Beiden kannst du durch das Erhöhen der Rundenanzahl auch nachträglich die Schwierigkeit erhöhen, ohne den Klartext zu kennen. Scrypt ist wegen dem hohem Speicherverbrauch schlecht in Hardware zu implementieren (was es womöglich sicherer macht).

Zitat:

Zitat von himitsu (Beitrag 1330798)

Im Notfall dem gespeicherten Hash ein Prefix/Kennung mitgeben, womit gehasht wurde, da kannst du dann mehrere Verfahren parallel laufen lassen und auch "alte" Hashs unterstützen.

Damit könnte man womöglich auch im Betrieb das Verfahren wechseln. Beim erfolgreichen Anmelden ist der Klartext ja bekannt.