DEC:Problem mit Verschlüsseln von FileStream -> MemoryStream

[mirage228]

Hallo,

ich habe heute ein wenig mit DEC rumprobiert. Dabei ist mir aufgefallen, dass das DEC zu bei großen Datenmengen zu hängen scheint. (Verschlüsselung war Rijndael mit cmCTS)

Das direkte Verschlüsseln einer Datei z.B. mit

Delphi-Quellcode:

var
  F: TFileStream;
begin
  CipherManager1.InitKey('test', nil);
  F := TFileStream.Create('C:\Dokumente und Einstellungen\mirage228\Desktop\battlefield_1942_secret_weapons_of_WWII_demo.exe', fmOpenReadWrite); // Richtig grosse datei mit 120 MB
  try
    CipherManager1.EncodeStream(F, F, F.Size);
  finally
    F.Free;
  end;
end;

funktioniert ohne Probleme (dauert auch nicht allzu lange).

Wenn ich aber folgendes Schreibe hängt das Programm mit ca. 90 % CPU-Last und 20-40 MB Speicherverbrauch. Ich habe es mal 5 Minuten laufen lassen und es ging trotzdem nicht weiter.

Delphi-Quellcode:

var
  F: TFileStream;
  M: TMemoryStream;
begin
  CipherManager1.InitKey('test', nil);
  F := TFileStream.Create('C:\Dokumente und Einstellungen\mirage228\Desktop\battlefield_1942_secret_weapons_of_WWII_demo.exe', fmOpenReadWrite);
  M := TMemoryStream.Create();
  try
    CipherManager1.EncodeStream(F, M, F.Size); 
  finally
    M.Free; // in meinem eigentlichen Programm wird der MemoryStream noch weiterverarbeitet.
    F.Free;
  end;
end;

Das merwürdige ist, dass es bei kleineren Datenmengen (1 MB) ziemlich schnell geht.
Wenn ich etwas größere (schon ab 10MB) Dateien nehme, hängt das Programm.

Ich weiss jetzt nicht, ob das ein Bug im DEC ist (dürfte eigentlich nicht sein) oder ich etwas falsch gemacht habe...

Habe Delphi 7 Professional und das DEC Part I.

Ich hoffe, jemand kann mir weiterhelfen.

mfG
mirage228

[SirThornberry]

Notfals könntest du
m.copyfrom(f, f.size)
machen und dann
CipherManager1.DecodeStream(M, M, M.Size);

[mirage228]

Hi,

danke für deine schnelle Antwort.

Auch über diesen "Umweg" klappt es nicht.

Ich habe das ganze mal ca. 12 Minuten laufen lassen, aber es tat sich nichts. Das Program reagierte nicht. :-\

mfG
mirage228

[SirThornberry]

nach
m.copyfrom(f, f.size)
noch
m.position := 0;
setzen - dann sollte es gehen weil es keinen unterschied mehr zwischen dem F und M Stream geben sollte außer halt das eins auf der platte und eins im speicher liegt

In deinen ursprungsbeispiel eventuell noch nach
m := TMemoryStream.create
die Anweisung
m.size := f.size
hinzufügen. Ansonsten wird die größe bei jedem schreiben über das ende neu gesetzt und das kostet übelst performance

[mirage228]

Zitat:

Zitat von SirThornberry

In deinen ursprungsbeispiel eventuell noch nach
m := TMemoryStream.create
die Anweisung
m.size := f.size
hinzufügen. Ansonsten wird die größe bei jedem schreiben über das ende neu gesetzt und das kostet übelst performance

Das hat wirklich übelst Performance gekostet!

Ich habe M.Size F.Size zugewiesen und es geht viel schneller (15 sek. ca!)

Dank dir^^

mfG
mirage228

[SirThornberry]

klappt es jetzt auch mit größeren Dateien oder besteht das Problem noch??

[mirage228]

Hi,

Es klappt jetzt alles. Selbst größere Dateien lassen sich jetzt ruck zuck ver- und entschlüsseln ^^

mfG
mirage228

[negaH]

Das liegt nicht am DEC sondern an der TStream VCL in Zusammenhang mit dem Windows API.
Du erzeugst ja mit fmCreate eine neue Datei. Diese Datei hat erstmal 0 Bytes größe. Nun verschlüsselt DEC über Buffer a 4096 Bytes. D.h. es lädt 4096 Bytes in einen Buffer aus der Source Datei, verschlüsselt diese und schreibt sie in die Zieldatei. ABER!, exakt hier muß die VCL die Datei um 4096 Bytes vergrößern und ruft dazu das Windows-API auf. Diese Dateivergrößerung und auch das Repositionieren des Dateizeigers per .Seek() ist die langwierigste Operation im Windows Filesystem. Meine Versuchen habe zB. ergeben das wenn man eine Datei sequentiell Byte für Byte liest die bis zu 100 mal schneller ist als wenn man zwischendurch noch irgendwelche .Seeks durchführt.

Ich weiß nun nicht 100%'tig ob es nur am Windows API liegt, oder ob ein bescheuerter AntiViren-Scanner wie Norton sich da reinhängt und bei jeder Dateiänderung diese Datei erneut nach Viren scannt. Solche Sympthome habe ich aber in Zusammenhang mit dem Norton AV schon erlebt.

Gruß Hagen

[SirThornberry]

ich benutzte 0 Virenscanner etc und trotzdem verschlingt das vergrößern (und damit das neue setzen der Position) nen haufen zeit. Also kann man davon ausgehen das es an der Api liegt

[negaH]

Wie gesagt, ich wüsste nicht was ich am DEC dahingehend falsch ge'codet haben sollte. Dieses Problem müsste dann auf deinem Rechner mit jedweiger TFileStream Nutzung auftreten. Dies zu testen wäre mal interessant.

Gruß Hagen