Suche AES Verschlüsselungskomponente

[dtrace]

Hallo zusammen,
ich suche dringends eine AES Verschlüsselungskomponente oder Unit für Zeichenkettenverschlüselung.
Ich benutze das BDS 2006 und die Units von Hagen Reddmann kann ich bei mir nicht einbinden!...


vielen Dank

[ringli]

Wieso kannst du das DEC bei dir nicht einbinden? Ok, es ist keine Komponente die du mit der Maus auf dein Formular ziehen kannst, aber dann musst du es eben zur Laufzeit erzeugen.

Guck mal hier, da hat Hagen mir seinerzeit bei dem Umstieg vom DEC 3 auf 5 weitergeholfen. :)

[mkinzler]

DEC, TPLockBox, ...

[dtrace]

wie binde ich das denn ein...muss ich nur auf das Verzeichnis verweisen? Ichhabe versucht ein Package zu erstellen und dann zu installieren...hmmm

[Luckie]

Ist die Readme denn so schwer zu verstehen? Entpacken, Pfad in Suchpfad aufnehmen und Units einbinden. Fertig.

[dtrace]

wenn eine readme dabei gewesen wär, dann nicht...aber leider keine vorhanden

[negaH]

http://www.michael-puff.de/Developer...agen_Reddmann/

Gruß Hagen

[dtrace]

sorry...aber ich kriege das immer nich nicht zum laufen. Ich benutze das BDS 2006. Kann mir mal bitte jemand eine Anleitung geben, wie ich eine einfache Stringverschlüsselung mit AES hinbekomme und wie ich diese Units implementiere. Ich habe im Searchpath des Projektes auf DEC/D7 verwiesen.

[negaH]

DEC\Part_I\

Delphi-Quellcode:

uses DECUtils, DECFmt, DECCipher;

with TCipher_Rijndael.Create do
try
  Init('Passwort');
  ResultAsHEXString := EncodeBinary('Dein Geheimnis', TFormat_HEX);
finally
  Free;
end;

als sehr einfaches Beispiel. Ansonsten einfach mal die DEMO anschauen -> DEC\Part_I\DECTest

Gruß Hagen

[InfixIterator]

genau das habe ich auch gesucht Danke!

Ich habe auch noch eine Frage:
Welches AES wird da verwendet? AES 128 oder AES 256?
(Bin etwas verwirrt, weil einige sagen Rijndael sei zwar ähnlich mit AES, aber ist nicht identisch. Andere wiederum sagen AES==Rijndael).

Kann ich irgendwie festlegen, dass ich immer nur mit AES 128 verschlüsseln will?
Mein Programm soll nämlich zusammen mit einem anderen arbeiten, das AES 128 verwendet und sollte deswegen immer das Standard AES 128 verwenden.

Danke im voraus

[mkinzler]

Rijndael ist das Verfahren, auf welches der Advanced Encryption Standard setzt.

[Bernhard Geyer]

Zitat:

Zitat von InfixIterator

Mein Programm soll nämlich zusammen mit einem anderen arbeiten, das AES 128 verwendet und sollte deswegen immer das Standard AES 128 verwenden.

Hier heist es Testen. Am besten gegen Testvektoren. Oft ist z.B. ein Problem das man unter Delphi als String die normalen Ansi-Strings nimmt, unter .NET oder Java aber gerne auch die auf 16-Bit Character basierenten Widestrings.

[LoCrux]

SCHAU MAL HIER.

[InfixIterator]

Vielen Dank, dass sieht genau nach dem aus, was ich suche :)

Hier kann ich bei Rijndael die Blockgröße auf 128 Bit ändern, damit es AES ist ^^
Nur sehr eigenartig ist, dass wenn ich die MaxKeySize auch auf 128 ändern will (für AES 128 ist ja die Schlüssellänge 128 lang)
springt es immer wieder auf 256 -.-

Ausserdem gibt es anscheinend noch paar kleine fehler:
kontne sie teilweise schon entfernen, aber es gibt noch probleme, da das Programm immer einen Hash wert des Passwortes machen will.
Ich wil aber eigentlich kein Hash Wert haben :>

Habe hier mal die umgeschriebene Bsp. Prozedur:

Delphi-Quellcode:

procedure encrypt(t:TstringList;AESKey:string);
var
  i: integer;
  Cipher: TDCP_rijndael;
  s: string;
begin
  Cipher :=TDCP_rijndael.create(nil);
  //Cipher.InitStr(AESKey);  //geht so nicht, er hat so zu wenig Parameter, meint der Compiler -.-
  Cipher.InitStr(AESKey,nil);    //also abgeändert in das, und nil, damit er kein hash wert macht, was aber nicht geht
  for i:= 0 to t.Count-1 do 
  begin
    s:= t[i]; 
   // Cipher.EncryptCFB(s[1],s[1],Length(s));  // dieser Befehl ist anscheinend Fehlerhaft, habe ihn abgeändert
    Cipher.EncryptCFBblock(s[1],s[1],Length(s));
    t[i]:= B64Encode(s); 
  end;
  Cipher.Reset;       
  Cipher.Burn;
end;

wäre sehr dankbar, wenn mir jemand verraten könnte wo der Fehler ist, bzw wie ich es richtig machen kann ^^

edit:
btw: könnte man in DEC nicht auch irgendwie die Blockgröße von Rijndael auf 128 Bit setzen und auch die Schlüssellänge auf 128 Stellen?
Dann hätte man ja auch mit dem DEC das AES 128...

Danke schonmal im voraus

[Luckie]

Guck mal hier, was die Verschlüsselungstiefe beim DEC angeht:
http://www.delphipraxis.net/internal...&highlight=dec oder hier: http://www.delphipraxis.net/internal...=811789#811789

[negaH]

Zitat:

edit:
btw: könnte man in DEC nicht auch irgendwie die Blockgröße von Rijndael auf 128 Bit setzen und auch die Schlüssellänge auf 128 Stellen?
Dann hätte man ja auch mit dem DEC das AES 128...

Benutze Passwörter die kürzer als <= 128Bit = 16 Bytes sind und schon benutzt AES_Rijndael im DEC intern 128 Bit Verarbeitungsbreite.
Passwörter im Bereich von > 128 Bit bis <= 192 Bit werden mit AES 192 Bit benutzt und Passwörter > 192 bis <= 256 Bits mit AES 256. Eigentlich sehr simpel.

Gruß Hagen

[InfixIterator]

Vielen dank :)
Finde bis jetzt auch das DEC am sympatischsten (und es ist auch das, was am besten funktioniert ^^)

Find ich gut, dass ich mit deinem Programm dann auch AES 128 verwenden kann.
Das mit dem Passwort kann man ja Abfangen, dass man nur <=16 Zeichen eingeben darf
(bzw. man schneidet sich die ersten 16 Zeichen nur raus).


Aber ich hätte da noch eine Frage:
Welche Betriebsart der Blockverschlüsselung wird eigentlich verwendet im DEC? (bzw. kann man es sogar einstellen?)
Ich bin da noch nicht ganz durch gestiegen...
Es gibt ja viele verschiedene Betriebsarten, aber im Endeffekt müsste doch eigentlich immer das selbe raus kommen oder?
Es wäre doch dann Jacke wie Hose ob ich nun ECB, CBC, CFB, CTR oder OFB nehme, oder?
Ich bin da sehr verwirrt, denn ECB & CBC füllen ihre Blocks auf, wenn sie zu wenig Text haben, aber denoch denke ich, sollten alle ein identisches Ergebniss liefern oder irre ich mich da?

Danke schonmal im voraus

[negaH]

Zitat:

Es wäre doch dann Jacke wie Hose ob ich nun ECB, CBC, CFB, CTR oder OFB nehme, oder?
Ich bin da sehr verwirrt, denn ECB & CBC füllen ihre Blocks auf, wenn sie zu wenig Text haben, aber denoch denke ich, sollten alle ein identisches Ergebniss liefern oder irre ich mich da?

1.) warum gibt es verschiedene Modis wenn sie Jacke wie Hose sind ?
2.) Du meinst damit das Padding, ein leidiges Thema da es dafür fast keine Standards gibt, erst so langsam werden welche entwickelt.

DEC "padded" immer wenn es geht und durchgeführt werden muß. Sobald du also eine Nachricht verschlüsselst die nicht exakt ein Mehrfaches der Blockgröße ist wird ein "Padding" versucht. Ist ein Modus ausgewählt in dem man nicht "padden" kann, wie cmECB gibts ne Fehlermeldung. Wird versucht nach einem "Padding" einen weiteren Datenblock zu verschlüsseln gibts ebenfalls eine Fehlermeldung, da auch dies nich geht. Möchte man also zb. 2 Datenblöcke so verschlüsseln als wären sie 1 Datenblock dan muß der erste Datenblock ein Mehrfaches der Blockgröße in der Länge betragen. DEC's Objekte enthalten einen internen Status, zb. ist der Cipher initialisiert, hat er ein Passwort bekommen, wurde der letzte Datenblock gepaddet ?
Allerdings wird beim "Padding" im DEC keine Nachrichtenexpansion durchgeführt, sprich zusätzliche Dummmybyte angehangen, sondern der Ciphermodi in 8 Bit Modi gewechselt. Padding mit Nachrichtenexpansion kann unsicher sein, da es dem Angreifer Möglichkeiten bietet.

Bei den Modis kann man erstmal in 3 Arten unterscheiden

cmECB -> Electronic Code Book, sollte nur benutzt werden bei Zufallsdaten oder als Basis anderer Ciphermodis.
cmCBC8 usw. -> arbeiten auf 1 Bytes Feedbackregistergröße, dh. ein 16 Bytes Blockcipher muß 16mal einen Block verschlüsseln
cmCBCx usw. -> arbeiten auf x Bytes Blockgröße, dh. ein 16 Bytes Blockcipher verschlüsselt den Block nur einmalig

Die cm???8 Modis benutzt man bei kurzen und sehr sicher zu haltenen Nachrichten. Sie haben den Vorteil das sie ohne Padding auskommen und 1 Datenbyte quasi Blockgröße mal verschlüsseln.
Die cm???x Modis benutzt man wenn man Speed braucht.

cmCBC/cmCTS usw. benutzen kein Cipher Text Stealing sondern eine Änderung des Ciphermodis als Padding. In beiden Fällen wird also die nachricht nicht um zusätzliche Bytes expandiert, sondern Length(Output) = Length(Input). Frühere DEC Versionen benutzten auch Cipher Text Stealing, aber dieses Verfahren ist unsicher besonders bei Nachrchten < Blockgröße. Deshab benutzt DEC jetzt ein Wechsel des Ciphermodis für den letzten Datenblock < Blockgröße vom cmCBCx zb. in den cmCBC8 Modi, also von Blockgröße auf Bytesgröße. Die letzten X Datenbytes werden also bei einem 16 Bytes Cipher auch 16 mal verschlüsselt, jedes im Versastz von 1 Byte.
Du musst dir das so vorstellen: cm???8 Modis verschlüsseln das 16 Bytes Feedback Register eines 16 Bytes breiten Ciphers == Blockgröße 16 bytes. Dann verküpfen sie zb. das 1. Byte diese Feedbackregisters mit den 1. Byte der Daten. Danach wird das Feedbackregister erneut verschlüsselt und das 2. datenbyte mit den Feedback Register verschlüsselt. Das Feedback Register arbeitet wie ein langes Shiftregister, wird also reihum um 1 Bytes pro Schritt rotiert. Das 2. Datenbyte wird also defakto mit dem 2. Byte des Feedbackregisters verknüpft allerdings wird das Feedbackregster aber durch den Cipher immer rotiert verschlüsselt. Zusätzlich, je nach Modi, werden die Daten aber auch noch nach oder vor oder beides mit den unverschlüsselten oder verschlüsselten Daten verknüpft. Verknüpfungsfunktion ist XOR.
Diese Vorgehensweise als "Padding" fügt keine virtuellen und bekannten/festen Datenbytes der Nachricht hinzu oder stielt diese Daten aus dem Vorgängerblock der eventuell bei sehr kurzen Machrichten garnicht vorhanden ist -> als Padding und Cipher Text Stealing. Sie ist damit sicherer als die anderen beiden Verfahren und hat denoch den Vorteil das die Nachrichtengröße sich nicht verändert. Eventuell kann es aber an dieser Stelle zu Inkompatibilitätenn zu anderen Implementierungen kommen. Die neueren Verfahren und Standards gehen aber immmer mehr zu diesem Verfahren über.

cmCTS/cmCFS sind Modis die ich entwickelt habe. Sie entsprechen dabei cmCBC/cmOFB allerdings mit doppelter Verknüpfung des interen Feedback registers VOR und NACH der Verschlüsselung eines Datenblockes. Sie sind damit der Fähigkeit der Selbst-Synchronisierung bei fehlerhaften Datenübertragungen beraubt. Das heist, es sind Alles oder Nichts Entschlüsselungsmodis, oder eben Modis die die Datenintegrität der datenübertragung sicherstellen. Wird mit ihnen eine CMAC -> Cipher.CalcMAC als Prüfsumme berechnet so kann man sicher sein das bei falscher Prüfsumme beim Entschlüsseln die Daten fehlerhaft oder manipuliert übertragen wurden.

Den Modi wählst du mit Cipher.Mode := cm???; aus, aber bitte noch bevor du mit .Init() den Cipher initialisierst !!
cmCBCx/cmECBx/cmCFB8/cmOFB8 sind Standard. cmCTS?,cmCFS? sind prohibitär von mir entwickelt und doppelt-Feedback-Modis, also Alles oder Nichts Verschlüsselungen und damit sicherer.

Gruß Hagen

[gammatester]

Zitat:

Zitat von negaH

Frühere DEC Versionen benutzten auch Cipher Text Stealing, aber dieses Verfahren ist unsicher besonders bei Nachrchten < Blockgröße.

Ciphertext Stealing ist Deiner Meinung nach unsicher? So unsicher, daß es zur Standardisierung vorgeschlagen ist:
http://csrc.nist.gov/groups/ST/toolk...20proposal.pdf

Im übrigen ist das übliche CTS nicht für Texte kürzer als Blocklänge definiert und auch nicht sinnvoll.

Gruß Gammatester

[negaH]

Ja er ist unsicher.

Zitat:

Im übrigen ist das übliche CTS nicht für Texte kürzer als Blocklänge definiert und auch nicht sinnvoll.

Wie du selber so schön bemerkt hast.

Ein Laie weiß soetwas nicht und verwendet den Cipher wie er ihn im Source bekommt. Er verschlüsselt also im CTS eine zu kurze Nachricht, < Blockgröße, und das ist unsicher. Ein Modus der vom Blockmodus in den 8 Bit Modus für den letzten Block wechselt muß sicherer sein. Die 8 Bit Feedback Modis wie CBC8, OFB8, CFB8 sind seit Jahren anerkannt und standardisiert. Wenn man für den letzten oder eben ersten unvollständigen Block in einen solchen Modus wechselt, dann ist das immer sicher, egal ob die Nachricht < Blockgröße ist.

Sicher, bezog sich also nicht nur auf die Mathematik, Kryptographie sondern eben besonders bezog es sich auf die Verfahrenssicherheit, die Sicherheit die ein Laie mit einer Implementierung einer Cryptolib tatsächlich erreichen kann. Je mehr Rahmenbedinungen bei der Anwednung von Kryptographie beachtet und gewusst werden müssen desto höher ist die Wahrscheinlichkeit für die Fehlbenutzung der Algorithmen. Und Kryptographie möchte Sicherheit garantieren und dazu gehört eben auch das es Anwednungssicher ist.

Das ein Ciphermodus beim AES vorgeschlagen wird sagt noch längst nichts darüber aus wie gut der Vorschlag ist. Gerade bei den Ciphermodis sind viele vorgeschlagen wurden, sehr viele wurden abgewiesen und nur die wenigsten haben es in die Endausscheidung geschafft.

Davon mal abgesehen werden ganz verschiedene Verfahren für das Cipher Text Stealing benutzt. Das Verfahren aus dem PDF ist nur eines der möglichen die es gibt. Und das einfachste Cipher Text Stealing benutzt einfach den vorherigen Ciphertext + Feedback Register um den letzten Block zu expanieren. Wenn das Feedback Register aber selber der IV war, eben weil es garkeinen vorherigen Ciphertextblock gab, so ist das unsicher. Egal ob für diesen Modus das verschlüsseln von Nachrichten kürzer als die Blockgröße definiert ist oder nicht, ob es sinnvol ist oder nicht, so wissen dies eben die meisten Anwender solcher Librarys überhaupt nicht. Sie benutzen es einfach, weil es geht. Und das ist Unsicherheit.

Ich rede hier kein theoretischen Unfug, sondern spreche aus Erfahrung. In meinen Supportmails für's DEC sind mindestens 5 Mails von Leuten die genau das gemacht haben. Das bewog mich eben auch das Cipher Text Stealing durch ein besseres Verfahren zu ersetzen, eben den Wechsel in einen 8 Bit Feeback Modus für den letzen zu kurzen Datenblock. Übrigens empfehle ich das nicht nur weil ich meine das es sicherer wäre, sondern weil es Experten wie zb. B.Schneier auch empfehlen.

Gruß Hagen

[InfixIterator]

Super vielen Dank, dass du dir die Zeit und die Lust genommen hast, so ausführlich und gut zu antworten :)

[Rudirabbit]

Hallo
Hänge meine Frage mal hier dran.
Ich benutze DEC für AES encryption.

Mein Programm soll mit einem anderem Programm kommunizieren.
Der Author des C Programms hat in einer Doko auch erklärt welche C Libs er benutzt hat.

AES_set_encrypt_key(MD5(pwd, strlen(pwd), NULL), 128, &e_key);

Ich habe das in Delphi so versucht:

Delphi-Quellcode:

Hash:= TDCP_md5.Create(Self);   // md5 wert des passwortes bilden;
Hash.Init;                     // initialize the hash
Hash.UpdateStr(pass);    // generate a hash of pass
Hash.Final(Digest);            // save the hash in Digest
Hash.Free;

DCP_rijndael1:=TDCP_rijndael.Create(nil);
DCP_rijndael1.Init(Digest,Sizeof(Digest)*8,nil);

decrypt:=DCP_rijndael1.DecryptString(input);
DCP_rijndael1.Free;

In decrypt sollte der String jetzt plain sein.
Der Author des C Programmes hat Beispielsrings dabei um die Funktion zu testen,leider scheint TDCP_rijndael was anderes zu machen.

Ein Test mit DCP_rijndael1.DecryptString - DCP_rijndael1.EncryptString funktioniert erwandfrei.
Das C AES_set_encrypt_key bzw AES_set_decrypt_key scheint einen etwas anderen Algo zu verwenden :gruebel:

Habe an den Parametern von DCP_rijndael1 schon rumgespielt, leider ohne Erfolg.
Hat jemand einen Tip :wall:

Gruss Rudi

[Gutelo]

Hallo,

ich moechte auch das DEC Packet verwenden. Allerdings funktioniert der Code in Example.txt nicht. Er sagt dass Context in der Zeile

'with ValidCipher(ACipherClass).Create, Context do'

nicht deklariert wurde.