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]

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?

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

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