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