3DES mit DEC (Delphi Encryption Compendium)

[Dano]

Zitat von himitsu:

So, blos daß wir jetzt nichts falsch verstehn:
Also das Ver-/Entschlüsseln innerhalb des DEC geht
und nur das Ver-/Entschlüsseln zwischen DEC und diesem Crypttool will nicht so richtig?

ist richtig

und ich gehe davon aus das außer padding beide nach RFC arbeiten sollten, habe auch beim debuggen nix bemerkt in DEC das da ein fehler sein könnte

bin eher ratlos, bin zwar fertig mit der arbeit, aber würde das doch gerne noch plausiebel auflösen, falls ich mal wieder auf DEC und 3DES zurückgreifen muß

mfg Dano

[BUG]

Du sollst CBC nehmen nimmst aber cmCBCx als Modus.

Vielleicht gibt es damit Probleme

[Dano]

ich habe nur folgende möglichkeiten

Zitat:

cmCTSx = double CBC, with CFS8 padding of truncated final block
cmCBCx = Cipher Block Chainung, with CFB8 padding of truncated final block
cmCFB8 = 8bit Cipher Feedback mode
cmCFBx = CFB on Blocksize of Cipher
cmOFB8 = 8bit Output Feedback mode
cmOFBx = OFB on Blocksize bytes
cmCFS8 = 8Bit CFS, double CFB
cmCFSx = CFS on Blocksize bytes
cmECBx = Electronic Code Book

und wie gesagt, das mit dem padding wenn der letzte block nicht voll ist habe ich auch gelöst

aber der algorythmus macht 8byte müll, dann 248byte alles super, und dann wieder periodischen unsinn

kann sein das es an meinem programm liegt, aber ich habe nix auffälliges gemacht mit zeiger verbiegen oder sonstiges

mfg Dano

[Dano]

ok, asche über mein haupt *duck*... hab ein fehler gefunden, der input-buffer war nur 256byte... und das einlesen der datei war damit corrupt


aber die ersten 8 byte sind immernoch unlogisch

mfg Dano

[himitsu]

Eventuell wird an der Stelle die Länge oder ein Hash mit eincodiert?

[Dano]

habs gefunden^^

es gibt einen "Initialization vector"

und der wird irgendwie randomm gefüllt wenn ich den nicht mit angebe
habe den jetzt extra auf #0#0#0#0#0#0#0#0 gesetzt und jetzt ist auch der erste block lesbar

Delphi-Quellcode:

implementation

uses DECUtil, DECCipher,  DECFmt;

{$R *.dfm}

// CrypTool padding bei CBC mit der anzahl der padding's...
// also z.b. #4#4#4#4 wenn 4 aufgefüllt werden
// Bei CBC wird bei Blockgröße auf/um 8 erweitert...
// input=15byte, output=16... padding #1
// input=16, output=24... padding #8#8#8#8#8#8#8#8
// IV mit 8mal 0 initialisieren, sonst ist erster block müll  #0#0#0#0#0#0#0#0
procedure TForm1.Button1Click(Sender: TObject);
var
  DefCipherClass: TCipher_2DES;
  Temp: String;
begin
  DefCipherClass:=TCipher_2DES.Create;
  DefCipherClass.Mode:=cmCBCx;

  Temp:='AAAAAAAAAAAAAAAA';
  DefCipherClass.Init(Temp,#0#0#0#0#0#0#0#0);  // passwort und IV  setzen
  Memo1.Lines.Add(IntToStr(Length(Temp))+':'+Temp);
  Memo1.Lines.Add(TFormat_HEX.Encode(Temp));

  // unsere nachricht + padding damit wir auf blockgröße 8 kommen
  Temp:='123456789012345'+#1;
  Memo1.Lines.Add(IntToStr(Length(Temp))+':'+Temp);
  Memo1.Lines.Add(TFormat_HEX.Encode(Temp));

  Temp:=DefCipherClass.EncodeBinary(Temp);      // verschlüsseln
  Memo1.Lines.Add(IntToStr(Length(Temp))+':'+Temp);
  Memo1.Lines.Add(TFormat_HEX.Encode(Temp));

  DefCipherClass.Done;                         // aufräumen

  Temp:=DefCipherClass.DecodeBinary(Temp);     // entschlüsseln
  Memo1.Lines.Add(IntToStr(Length(Temp))+':'+Temp);
  Memo1.Lines.Add(TFormat_HEX.Encode(Temp));

  // jetzt müßte noch das padding entfernt werden

  DefCipherClass.Free;
end;

bin jetzt selber überrascht wie einfach das mit DEC ging^^
war am anfang schnell überfordert weil in den beispielen soooo viel drin stand und ich nur schwer das für mich benötigte rausfiltern konnt
aber wenn man einmal den durchblick hat, ist das DEC einfach nur genial

und wenn man noch die ganzen Memo1.Lines.Add weglässt ist es ein 10 zeilen code um mit 3DES zu verschlüsseln und gleich wieder zu entschlüsseln

Delphi-Quellcode:

procedure TForm1.Button1Click(Sender: TObject);
var
  DefCipherClass: TCipher_2DES;
  Temp: String;
begin
  DefCipherClass:=TCipher_2DES.Create;
  DefCipherClass.Mode:=cmCBCx;
  DefCipherClass.Init('AAAAAAAAAAAAAAAA',#0#0#0#0#0#0#0#0);  // passwort und IV  setzen

  Temp:='123456789012345'+#1;                   // text+ padding
  Temp:=DefCipherClass.EncodeBinary(Temp);      // verschlüsseln
  DefCipherClass.Done;                          // aufräumen
  Temp:=DefCipherClass.DecodeBinary(Temp);      // entschlüsseln
  // jetzt müßte noch das padding entfernt werden
  DefCipherClass.Free;
end;

das ist jetzt zu 100% kompatibel zu CrypTool

danke euch für die hilfe
mfg Dano

[r2c2]

Ich hab mich mit DEC und DES jetzt nicht größer auseinander gesetzt, aber es ist AFAIK wichtig, dass ein Initialization Vector (pseudo-)zufällig ist. Genau das war IIRC eines der Probleme von WEP. WEP verwendet intern RC4, das prinzipiell OK ist, aber der IV war in den meisten Implementierungen vorhersehbar (in inkrementierter Counter). Und auf einmal hatte man einen wunderbare Known-Plaintext-Angriff...

BTW: try..finally solltest du einbauen...

mfg

Christian

[Dano]

mit try...finaly hast du ja recht,
aber das ist jetzt auch kein programm das ich anderen gebe, und selbst bei mir sind es oft nur paar versuche die es läuft das ich sogar das free fast immer weglasse^^ speicher gibt ja in hülle und fülle
also für einen versuchsaufbau ist das ok, und jeder fehler der auftritt behandel ich selber im debugger

bei ner schleife mit 10000 kommt das free natürlich mit rein, wenn ein fehler auftritt ist es belanglos für mich ob ein finaly block existiert... strg+f2 und fehler suchen
ist kein ablauf der die fehler fremder benutzer auffangen muß/soll

das mit dem IV ist natürlich schon wichig um den ersten block zu schützen, aber in der sache mußte ich mich an das system anpassen welches die referenz darstelt... also IV=00000000

mfg Dano

[r2c2]

Ich würde dir trotzdem raten, try..finally zu verwenden. Und wenn es nur ist, um das zur Gewohnheit zu machen, damit dus dann, wenns wichtig ist, nicht vergisst. Das tut nicht weh, aber es hilft.

Das ist wie mit dem Autofahren. Da gibts auch Leute, die sich sagen "Da ist doch eh keiner hinter mir, da muss ich nicht blinken, wenn ich abbiege." Und das sind dann auch die, die das Blinken mal vergessen, wenns wichtig wäre. Die paar Kalorien, die man aufwenden muss, um den Blinker anzumachen, kann man schonmal investieren. Das sind noch nichtmal Erdnüsse...


mfg

Christian

[cookie22]

Wenn man Speicher anfordert, hat man den auch wieder freizugeben. Also muss hier zwingend ein "try..finally Block" hin.