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

[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

[BUG]

Zitat von Bbommel:

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

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