[Delphi]AES encryptie compatible met .NET RijndaelManaged

[Verwijderd]

Bestaat die implementatie? Ik heb me de afgelopen dagen sufgegoogled, freeware/shareware AES implementaties getest, trial versies en ActiveX controls geinstalleerd en getest, maar ik heb nog geen enkele library of component gevonden dat hetzelfde encrypted resultaat gaf als RijndaelManaged uit System.Security.Cryptography.

Achtergrond: in de US en Canada beginnen de creditcard maatschappijen PCI Compliance af te dwingen, en 1 van de eisen is dat creditcard gegevens strong encrypted bewaard moeten worden. Tot nu toe deden we dat in 3DES, maar dat is blijkbaar niet meer genoeg: AES/Rijndael wordt geeist.

Maar we hebben zowel Delphi programma's als .NET programma's die met dezelfde database moeten babbelen, dus dan is 't wel handig dat ze allemaal dezelfde encryptie aankunnen.

Bij de meeste Delphi implementaties mis ik wat hoognodige mogelijkheden (geen salt of IV (initialization vector) kunnen zetten), of loop ik tegen bugs aan (Turbo Power LockBox verwerkt het laatste block niet goed).
Is iemand hier ook al 's tegenaan gelopen? En een oplossing gevonden? (mag geld kosten, als we dit niet oplossen kost 't ons ook geld...)

[Sjaaky]

Je kan een dll in .net schrijven waar je dmv activex vanuit delphi mee praat. Dus 1 dll die voor Delphi en .Net kan encrypten en decrypten.

[Verwijderd]

Dat weet ik, maar ik kan niet van duizenden klanten opeens eisen dat het .NET framework 2.0 geinstalleerd dient te zijn.
Dan nog liever andersom: via interop vanuit .NET een Delphi COM-object benaderen, maar da's ook weer jammer, want .NET heeft een hele nette cryptography lib...

[LordLarry]

Gebruikt .Net niet gewoon de win32 windows crypt api?

[Sjaaky]

Ok, dan is het een ander verhaal. Wat je wel kan doen.. Ik weet niet of .net zijn encryptie uitbesteed aan native componenten, maar als dat niet zo is zou je de sourcecode kunnen bekijken met bijvoorbeeld Lutz Roeder .net reflector. En dat dan porten naar Delphi.
Als .net zijn encryptie wel door win32 laat doen, is het natuurlijk ook geen probleem, want dan kun je die dll's direct vanuit Delphi aanroepen.

[Verwijderd]

.NET zal waarschijnlijk wel gebruik maken van de Windows crypto API (weet ik niet zeker), maar de cryptography lib is vele malen gemakkelijker te benaderen dan de crypto API. Bij m'n zoektocht kwam ik in een newsgroup de opmerking tegen dat de ontwerper van de crypto API z'n opdracht niet goed begrepen had, en in plaats daarvan een zo cryptisch mogelijke API had gemaakt...

Reflector gebruiken en dan porten zou een optie kunnen zijn, maar daar gaat nogal wat tijd in zitten. En aangezien 't begin augustus operationeel, getest en gecertificeerd dient te zijn (en die certificatie is niet mals!) zoek ik liever nog even naar een Delphi oplossing die compatible is met RijndaelManaged.

[Verwijderd]

Heb je deze kit al geprobeerd (native vcl code):
TurboPower Lockbox

[edit]
ah, lees het net in je SP

[ Voor 16% gewijzigd door Verwijderd op 23-06-2007 12:37 ]

[Verwijderd]

LockBox was 1 van de eerste opties die ik geprobeerd heb, aangezien ik veel en meestal goede ervaring heb met TurboPower suites (AsyncPro, Orpheus, OfficePartner).

In LockBox kun je overigens ook niet zelf een salt en IV opgeven, maar dat was gemakkelijk toe te voegen en zal ik t.z.t. wel vrijgeven aan de OS community (moet nog een property editor voor de IV maken, want die MOET 16 bytes/chars lang zijn).
Maar die bug in het laatste block waardoor het encrypted resultaat te lang wordt is lastiger, en ik heb niet genoeg kennis van AES om dat even snel op te kunnen lossen...

[LordLarry]

Eldos SecureBlackbox (http://www.eldos.com/sbb/) kan het ook vast.

[Verwijderd]

Eldos was ik ook al tegengekomen, maar hun blackboxes doen alles (PKI, SSL, SSH, PGP, MIME, XML etc.) maar voor zover ik kon zien geen simpele string (of stream) encryptie. En laat ik 't nou net daarvoor nodig hebben...

[brokenp]

Heb je de mensen van TurboPower LockBox benadert met je probleem van het laatste block? Anders zou je ook kunnen overwegen om iemand in te huren die wel verstand heeft van AES en even deze code reviewt/aanpast?

[Verwijderd]

Het bedrijf TurboPower bestaat al jaren niet meer, en ze hebben bij het beeindigen alle component suite software open source gemaakt (lovenswaardig!). Aan de LockBox suite wordt zo te zien al niet meer ontwikkeld sinds 2003...
Iemand inhuren die heel misschien de bug kan vinden en oplossen is niet echt handig als je een deadline hebt. Bovendien, AES staat voor 'Advanced Encryption Standard', dus dan zou je toch moeten kunnen verwachten dat de verschillende implementaties interoperabel zijn?

[Soultaker]

Het is een standaard block cipher, maar je kunt eindeloos variëren met containers, salts, streaming mode, etcetera. Het lijkt me dat je dus eerst eens goed uit moet zoeken wat RijndaelManaged precies doet (is daar bijvoorbeeld broncode van?) als je zeker weet dat dat doet wat je wil, en daarna dat proberen te emuleren. I.m.o. moet je nu eerst in detail uitzoeken wat je precies wil.

Waarschijnlijk kun je dan wel een bestaande library gebruiken, maar als je wat meer moeite doet en performance niet van kritiek belang is, kun je ook zelf het algoritme implementeren (het is min of meer vrij beschikbaar, dacht ik; er zijn in ieder geval genoeg BSD-licensed implementaties die je zonder problemen kunt porten). Ik zou wel de voorkeur geven aan het gebruik van een bestaande library; scheelt een heleboel gedoe.

[ Voor 4% gewijzigd door Soultaker op 23-06-2007 20:22 ]

[Verwijderd]

RijndaelManaged is onderdeel van System.Security.Cryptography van het .NET framework, dus aan source kom je alleen via IL disassembly of Reflector. Niet echt handig dus. Ik bedenk me net dat Mono waarschijnlijk ook de Cryptography assembly geimplementeerd heeft, dus misschien kan ik iets meer met hun (open) source...
RijndaelManaged biedt je zo ongeveer alle vrijheid in je keuzes (SHA1 of MD5 als hash algorithme voor je passphrase, vrij te kiezen salt en IV, etc.), maar ik heb er geen probleem mee om die mogelijkheden te beperken. Als 't maar interoperabel wordt met willekeurig welke Delphi implementatie.

Ik ga sowieso voor een bestaande library, want in een maand kun je niet vanaf scratch een AES implementatie schrijven, testen, debuggen en gecertificeerd krijgen.