Der DEC x32 ASM in x64/PurePascal Konvertierungsthread

[jaenicke]

Wie sieht es denn eigentlich mit dem Projekt aus? 64-Bit wären schon interessant dabei.

[gammatester]

Ich halte die Konvertierung auf 64-Bit-Assembler für eine Sackgasse. Delphi-64 ist auch ohne ASM für bestimmt 99% aller Cryptoanwendungen schnell genug, überhaupt sind 64-Bit für die meisten DEC-Algos irrelevant. Interressant ist es zB für SHA512 und abgeleitete, siehe zB die Cycles/Byte-Werte für meine Implementationen in der Tabelle.

Im übrigen reicht eine Konvertierung kaum aus; was DEC mM am meisten fehlt sind neue Entwicklungen: CTR, EAX, GCM, CMAC - Modi für die Blockchiffren, neue Stromchiffren wie Salsa/Chacha oder Sosemanuk, die neuen Hashfunktionen SHA512/tt, vom kommenden SHA3/Keccak ganz zu schweigen.

[hugie]

Da es scheinbar kein Feedback gibt, möchte ich doch kurz auf die Alternative DCPcrypt hinweisen.
Läuft angeblich auch mit XE2 und x64.
Werde es heute mal testweise als Ersatz für die DEC einsetzen.

Vg,
Hugie

[bernerbaer]

Zitat von hugie:

Da es scheinbar kein Feedback gibt, möchte ich doch kurz auf die Alternative DCPcrypt hinweisen.
Läuft angeblich auch mit XE2 und x64.
...

DCPcrypt läuft definitiv auf x64, ich setze es erfolgreich bei XE3 ein.

[gammatester]

DCPcrypt hat eigentlich noch mehr Nachteile als DEC, alles was in meinen letzen Absatz steht, trifft auch auf DCPcrypt zu. Beide werden inhaltlich nicht weiterentwickelt und sind ca 10 Jahre alt.

Bei Klickklack-Technikern allerdings scheint DCPcrypt wegen Installation/Packages beliebt zu sein, diese 'Features' fehlen (sprich: werden nicht benötigt) bei DEC oder meinen Kryptoroutinen (die modular und 64-Bitkompatibel sind, aber Verständnis/Handarbeit benötigen).

[hugie]

Da wäre es langsam interessant, eine existierende OpenSource lib die weit verbreitet ist, via wrapper für delphi zur verfügung zu stellen.
Z.B. libgcrypt o.ä. Ist lgpl, sollte also auch in proprietärer Software einsetzbar sein.
Viele c/c++ OS Projekte sind up-to-date, häufig eingesetzt, gut geprüft etc.

Soweit ich weiß ist es doch relativ unkompliziert eine .dll oder .so via wrapper aus delphi heraus anzusprechen.
Damit würde man sich das regelmäßige neuentwickeln sparen, man müsste "nur" die api immer aktuell halten.
Ok, es ist kein PurePascal, aber sicherlich doch eine alternative Lösung zu unseren Problemen hier.

Gibt es da vielleicht schon was?

Lg

[jaenicke]

Ich habe in der Zwischenzeit die meisten Anpassungen selbst durchgeführt, zumindest für die Teile, die ich benötige.

Eine zusätzliche DLL wäre zwar kein echtes Problem, möchte ich aber eigentlich nicht.

[Schorschi5566]

Hallo zusammen,

darf man fragen ob das Projekt Dec 6.0 noch weiter verfolgt wird?

Wäre schon toll und war doch schon bald fertig, oder?

Ich habe mir auch mal die Kryptoroutinen von gammatester angesehen aber hätte da schon so meine Probleme um die von mir verwendeten DEC-Funktionen umzusetzen.

Sowas zum Beispiel:

Delphi-Quellcode:

function EncryptString(const Password: RawByteString; const Value: RawByteString): RawByteString;
var
  Salt, SessionKey: Binary;
begin
  Salt := RandomBinary(16);
  with TCipher_Rijndael.Create do
    try
      SessionKey := THash_SHA1.KDFx(Password, Salt, Context.KeySize,
        TFormat_Copy);
      mode := cmCFS8; 
      Init(SessionKey);
      Result := TFormat_MIME64.Encode(Salt + EncodeBinary(Value, TFormat_Copy));
    finally
      Free;
      ProtectBinary(Salt);
      ProtectBinary(SessionKey);
    end;
end;

Weiß jemand was die Entsprechung mit den gammatester-Kryptoroutinen wäre? Geht das damit?


Grüße,
Uwe