Datei stückchenweise mit TFileStream einlesen

[Luckie]

Und genau das sind meine zwei andern Probleme: Es müßte gehen und ich verstehe nicht, warum es nicht geht.

[Christian Seehase]

Moin Luckie,

bekommst Du wirklich bei SrcStream.Read den Fehler?

Wie sieht die Routine denn bei Dir aus.
Am Besten incl. Datendeklaration, und Dateigrösse (genau)

[Luckie]

Jupp, ich bekomme einen. Deklarationen wie gehabt (siehe oben). UInd ausgesehen hat sie wie von Kamil gepostet. Dateigröße: 49.955.924 Bytes. GetMem habe ich auch aufgerufen.

Keinen Plan. Habe es aber schon wieder rückgängig gemacht.

Wenn ich die if-Konstruktion nehme und statt 1024 2048 oder 4096 einsetze, bekomme ich eine AccessViolation zum Schluß.

[negaH]

Delphi-Quellcode:

var 
  Len: integer; 
  Buffer: array[0..1023] of Byte;
  ... 
begin 
... 
  while SrcStream.Position < SrcStream.Size do 
  begin 
    Len := SrcStream.Size - SrcStream.Position;
    if Len > SizeOf(Buffer) then Len := SizeOf(Buffer);
    SrcStream.Read(Buffer, Len); 
    EncodeBuffer(Buffer, Buffer, Len); 
    DestStream.WriteBuffer(Buffer, Len); 
  end; 
...

Wichtig! EncodeBuffer() sollte nach Möglichkeit inplaced arbeiten.

oder

Delphi-Quellcode:

var 
  Len: integer; 
  Buffer: array[0..1023] of Byte;
  ... 
begin 
... 
  repeat
    Len := SrcStream.Read(Buffer, SizeOf(Buffer)); // .Read statt .ReadBuffer um Exceptions zu vermeiden
    EncodeBuffer(Buffer, Buffer, Len); 
    DestStream.WriteBuffer(Buffer, Len); 
  until Len = 0;
...
end;

Dies vermeidet die Seek-Aufrufe in den Dateistream durch das OS um .Position und .Size zu berechnen. Dadurch wird also der Dateistream nur sequentiell gelesen und dies ist erheblich schneller !! Probier es aus mit großen Files.

Gruß Hagen

[Luckie]

Geil. Werde ich gleich ausprobieren. Besten Dank.

PS: Steht das im DEC irgendwo, dass EncodeBuffer inplaced arbeiten sollte? Oder ist das allgemeines Kryptologiewissen?

[Luckie]

So jetzt haben wir den Salat, jetzt bekomme ich unterschiedliche Hash-Werte nach dem Entschlüsseln und die entschlüsselte Datei ist dann natürlich nicht zu gebrauchen.

[Luckie]

Entschlüsseln:

Delphi-Quellcode:

          // ignore the file header
          SrcStream.Seek(sizeof(TFileHeader), soFromBeginning);
          // assign the Cipherclass
          CipherClass := Cipher;
          // prepare for decoding
          with CipherClass.Create(PW, nil) do
          begin
            Mode := cmCFB;
            InitKey(PW, nil);
            // as long as we have not reached the end of the source stream
            repeat
              Len := SrcStream.Read(Buffer, SizeOf(Buffer));
              EncodeBuffer(Buffer, Buffer, Len);
              DestStream.WriteBuffer(Buffer, Len);
            until Len = 0;
          end;

Verschlüsseln:

Delphi-Quellcode:

          // write the head into the stream
          DestStream.Write(FileHeader, sizeof(TFileHeader));
          //  prpare vor encoding
          with CipherClass.Create(PW, nil) do
          begin
            Mode := cmCFB;
            InitKey(PW, nil);
            // as long as Len has something to read
            repeat
              Len := SrcStream.Read(Buffer, SizeOf(Buffer));
              EncodeBuffer(Buffer, Buffer, Len);
              DestStream.WriteBuffer(Buffer, Len);
            until Len = 0;
          end;

Was habe ich übersehen?

[negaH]

Zitat:

Steht das im DEC irgendwo, dass EncodeBuffer inplaced arbeiten sollte? Oder ist das allgemeines Kryptologiewissen?

Das steht nicht im DEC, du weisst DEC ist NUR eine Sammlung von effizient programmierten Algorithmen.

Wird inplaced gearbeitet so werden die Daten im Buffer implizit mit deren verschlüsseltem Produkt überschrieben. Da .EncodeBuffer() nicht wissen kann ob der Anwender seine Daten geschützt haben will darf .EncodeBuffer() auch nicht den Sourcebuffer von sich aus mit Müll füllen. Dies müsste dann schon deine Funktion machen damit eben keine sicherheitsrelevanten Daten im Speicher verbleiben. Übrigens: dies ist auch der Grund warum ich den Buffer NICHT dynamisch alloziere sondern im Stack ablege. Bei dynamischen Speicher müsstest du wiederum dafür Sorge tragen das er wiped wird. Im Stack wird mit enorm hoher Wahrscheinlichkeit der Stackspeicher durch nachfolgende Funktionen nochmals überschrieben. Geht man davon aus das es heute Techniken gibt die aus benutzten Speicherzellen denoch deren Inhalt vor 100 Schreibänderungen ermitteln können, so wird klar das der Stack zB. einer der Speicherbereiche ist der die meisten Schreibänderungen hat.
Die Lebenszeit der sichertsrelevanten Daten bei inplaced Codierungen ist die kürzt mögliche.
Das Tracen des Stackes ist eine der schwierigsten Operationen eines guten Debuggers.
All diese Überlegungen kann ein Programmierer ohne viel Aufwand umsetzen um seine Kryptofunktionen sicherer zu machen.

Zitat:

So jetzt haben wir den Salat, jetzt bekomme ich unterschiedliche Hash-Werte nach dem Entschlüsseln und die entschlüsselte Datei ist dann natürlich nicht zu gebrauchen.

Ich habe deinen Source noch nicht genauer analysiert. Es ist aber wichtig das der Stream-Dateizeiger korrekt repositioniert wird. Also, nach Hash.CalcStream(Stream) muß Stream.Position := 0 gesetzt werden. Dies ist ein häufig gemachter Anfängerfehler den ich hier nur erwähne weil auch Profi's wie du ihn von Zeit zu Zeit mal machen


Gruß hagen

[negaH]

Zitat:

Was habe ich übersehen?

Zitat:

Verschlüsseln ..... EncodeBuffer()

Zitat:

Entschlüsseln ..... EncodeBuffer()

Hm, irgendwas stimmt da aber nicht ?

Gruß Hagen