Dateiverschlüsselung mit DEC (5.2)

[Schwedenbitter]

Hallo,

in einer Client-Server-Umgebung möchte ich, dass der Server dem Client eine Datei zur Verfügung stellt. Diese soll verschlüsselt werden. Dem Client werden dann nur der Name/Pfad der verschlüsselten Datei auf einem Fileserver und das Passwort übermittelt. Nun möchte ich aus Sicherheitsgründen auf dem Client die Datei nicht zwischenspeichern, sondern als TMemoryStream weiter verarbeiten.
Ich verwende dazu die DEC und einen stark abgewandelten Code aus der Demo (vergleichbar hiermit).

Das Verschlüsseln klappt. Wenn ich mit dem Server wieder entschlüssele, gibt es kein Problem. Wenn ich aber mit dem Client das Entschlüsseln versuche, bekomme ich eine Exception mit der Fehlermeldung "Class 89504E47 is not registered". Es hat auch nichts gebracht

Delphi-Quellcode:

Initialization
  IdentityBase:=$89504E47;

einzufügen.

Ich gehe der Kommentierung nach davon aus, dass es daran liegt, dass nur ein und dasselbe Programm ver- bzw. entschlüsseln darf. Ich begreife nicht, wie ich den Code abändern kann/muss, damit es klappt. Zudem möchte ich (auch) gern sicherstellen, dass nur der passende Client dechiffriert.

Ich habe die von mir verwendete Unit mal beigefügt. Diese wird sowohl vom Server als auch vom Client verwendet. Es betrifft dort die Funktionen EncryptFile() und DecryptFile().

Danke für die Hinweise, Alex

[cookie22]

registrierst du die algorithmen? z.b. so:

Delphi-Quellcode:

procedure RegisterClasses;
begin
  TFormat_Copy.register;
  TFormat_HEX.register;
  TFormat_MIME64.register;
  TFormat_MIME32.register;

  THash_SHA512.register;
  THash_Whirlpool.register;

  TCipher_Twofish.register;
  TCipher_Rijndael.register;

  SetDefaultCipherClass(TCipher_Rijndael);
  SetDefaultHashClass(THash_SHA512);
  IdentityBase := $84282255;
end;

das mußt du auch auf dem client machen, dann sollte das klappen.

[Schwedenbitter]

Danke für die schnelle Antwort!

Zitat:

Zitat von cookie22 (Beitrag 1028978)

registrierst du die algorithmen? ...

Ich dachte schon. In einem anderen Beispielcode hatte ich das mal so gesehen. Dort wurde es über globale Variablen gemacht, denen gleich Standardwerte mitgegeben wurden:

Delphi-Quellcode:

Var
   AKDFIndex    : LongWord        = 1;
   ACipherMode  : TCipherMode     = cmCBCx;
   AHashClass   : TDECHashClass   = THash_Whirlpool;
   ACipherClass : TDECCipherClass = TCipher_Rijndael;
   ATextFormat  : TDECFormatClass = TFormat_Mime64;

Oder sind das verschiedene Dinge?

Ich werde Deinen Vorschlag mal ausprobieren. <- klappt leider nicht

[edit]Ich habe auch den - übersehenen - Teil aus dem Codebeispiel jeweils als erste Zeilen so in die Funktionen geschrieben

Delphi-Quellcode:

   SetDefaultCipherClass(TCipher_Rijndael);
   SetDefaultHashClass(THash_SHA1);
   IdentityBase := $84485225;
   RegisterDECClasses([TCipher_Rijndael, THash_SHA1]);

Das klappt leider auch nicht[/edit]
Gruß, Alex

[cookie22]

Zitat:

Zitat von Schwedenbitter (Beitrag 1028981)

Danke für die schnelle Antwort!

Zitat:

Zitat von cookie22 (Beitrag 1028978)

registrierst du die algorithmen? ...

Ich dachte schon. In einem anderen Beispielcode hatte ich das mal so gesehen. Dort wurde es über globale Variablen gemacht, denen gleich Standardwerte mitgegeben wurden:

Delphi-Quellcode:

Var
   AKDFIndex    : LongWord        = 1;
   ACipherMode  : TCipherMode     = cmCBCx;
   AHashClass   : TDECHashClass   = THash_Whirlpool;
   ACipherClass : TDECCipherClass = TCipher_Rijndael;
   ATextFormat  : TDECFormatClass = TFormat_Mime64;

Oder sind das verschiedene Dinge?

Ich werde Deinen Vorschlag mal ausprobieren.

Gruß, Alex

ja sind unterschiedliche dinge.

das wichtige is das registrieren.

Delphi-Quellcode:

THash_Whirlpool.register;

das kannst du im oncreate event machen, oder sonst wo bevor du mit dem verschlüsseln anfängst. das mußt du im server sowie auch im client machen.

[Schwedenbitter]

Zitat:

Zitat von cookie22 (Beitrag 1028988)

das kannst du im oncreate event machen, oder sonst wo bevor du mit dem verschlüsseln anfängst.

Da ich den Code in einer eigenen Unit untergerbacht habe, die wegen 4 Funktionen nicht objektorientiert ist, habe ich kein OnCreate(). Aber ich habe es in der Initialization probiert, was m.E. dasselbe bewirken sollte. Aber es klappt trotzdem nicht.

Zitat:

Zitat von cookie22 (Beitrag 1028988)

das mußt du im server sowie auch im client machen.

Das ist mir klar. Aus diesem Grunde wird die Unit sowohl beim Server als auch beim Client eingebunden und verwendet.

[cookie22]

kannst du mit dem server entschlüsseln?

[Schwedenbitter]

Zitat:

Zitat von cookie22 (Beitrag 1028999)

kannst du mit dem server entschlüsseln?

Ja. Das habe ich zu Testzwecken gleich als erstes gemacht:

Delphi-Quellcode:

   S:=CreateKey;
   S2:=NameCryptFile(EdPollDir.Text, 'enc');
   Try
      EncryptFile(Strings[0] + '_sign.png',// zugehörige Unterschrift
         S2, S);
      DecryptFile(S2, 'C:\Test_Server.png', S);
      ...
   Except
      // Fehlerbehandlung, falls Verschlüsseln nicht klappt
   End;

Ich habe dann im Stamm von C: die Datei, die sich problemlos öffnen lässt und mit dem Original übereinstimmt. Ich verwende einunddieselben Functionen im Client und im Server und bin entsprechend ratlos...

Gruß, Alex

[cookie22]

sehr merkwürdig sollte eigentlich klappen. fällt mir auch nix zu ein. :(

[Schwedenbitter]

Zitat:

Zitat von cookie22 (Beitrag 1029054)

sehr merkwürdig sollte eigentlich klappen.

Und es wird noch merkwürdiger:

Ich lasse mir nun das Passwort, die Datei etc. anzeigen (ShowMessage()), die alle übereinstimmen. Auch habe ich mit separatem Code das Verschlüsseln und Entschlüsseln mit separaten Programmen* trainiert :lol:. Das klappt und noch besser wird es, wenn der Server verschlüsselt und ich mit meinem separaten Entschlüsselungs-Programm (Siehe *) die Datei erfolgreich und ohne jede Fehlermeldung entschlüsseln kann.
Das kann ich nun überhaupt nicht mehr nachvollziehen :gruebel: Daran dass es ein anderes Programm ist, kann es also nicht liegen.

Bevor ich es vergesse:
* in meinen separaten Testprogrammen stehen hier übrigens nur 3 Zeilen und auch das Entfernen der Kommentare bringt nichts:

Delphi-Quellcode:

Initialization
   Randomize;
// THash_SHA1.Register; // es läuft auch ohne ?!?
// TCipher_Rijndael.Register; // es läuft auch ohne ?!?
   SetDefaultHashClass(THash_SHA1);
   SetDefaultCipherClass(TCipher_Rijndael);

Der Fehler MUSS also in meinem Client-Programm liegen. Da ich meine Unit Encryption in allen Programmen unverändert benutze, KANN er hier nicht liegen. Kann mir mal bitte jemand einen Hinweis geben, wie/wo ich anfangen kann zu suchen? Ich möchte ungern meinen gesamten Client hier reinstellen. Das sind mehrere tausend Programmzeilen. Das kann ich keinem zumuten.

[scherz] Von mir aus auch damit: :glaskugel:[/scherz]

der völlig ratlose Alex

[Schwedenbitter]

:duck: Ganz dummer Fehler:

Delphi-Quellcode:

Type
   TSignJob      = Packed Record
      FileName      : String;
      Password      : String;
      CryptFile      : String;
   End;

Ist an sich selbsterklärend. Wenn man aber im Träumen dem Decrypter statt dem .CryptFile die unverschlüsselte Datei (.FileName) übergibt, braucht man sich über Fehler nicht zu wundern.
Jetzt klappt es!

Wünschenswert wäre es nur, wenn die Fehlermeldungen nicht so kryptisch, sondern besser zu verstehen wären. Wäre dieser Wunsch etwas für hier?

Gruß, Alex

[cookie22]

wär auch komisch gewesen, wenn das nicht klappt. :-D

[Assertor]

Hi Alex,

Zitat:

Zitat von Schwedenbitter (Beitrag 1029591)

Delphi-Quellcode:

Initialization
   Randomize;

Das bewirkt in der DEC nichts, ist ja die Delphi Funktion. Was Du suchst, heißt RandomSeed:
http://www.delphipraxis.net/429884-post.html

Die Fehlermeldungen werden in der DEC 5.3 schon etwas besser, mal gucken, ob ich diesen spezialgelagerten Sonderfall irgendwie noch etwas hübscher machen kann.

Gruß,
Assertor

[negaH]

Zitat:

Zitat von Assertor (Beitrag 1029610)

Die Fehlermeldungen werden in der DEC 5.3 schon etwas besser, mal gucken, ob ich diesen spezialgelagerten Sonderfall irgendwie noch etwas hübscher machen kann.

Was willst du da verbessern können ?

Das System bekommt eine 4 Bytes ID, ausgelesen aus einer falsch kodierten Datei. Das System findet unter dieser ID keine registerierte Klasse. Die Funktion die diese Klasse ermittelt bekommt als Parameter nur diese ID und kann somit auf Grund fehlender Informationen auch nur einen Fehler bringen der sagt: Hallo ? Unter dieser ID wurde keine Klasse registriert.

Der Punkt ist also: Derjenige der diese DEC Funktionen in higher-level Funktionen benutzt hat sicher zu stellen das auch eine aussagekräftigere Fehlermeldung erfolgt wenn seine Funktion auf falschen Daten arbeitet. In meinen Augen gibt es also kein Defizit im DEC sondern nur in der Art&Weise wie der Programmier das DEC benutzt hat.

Mal einfach gefragt: wie soll DECClassByIdentity(ID: Cardnal); denn hellsehen können das der Programmierer diese Funktion aus einem Kontext heraus benutzt in dem er in seiner Funktion eine ungültige Datei übergeben kann ?

Du kannst da versuche was du willst, aus Sicht der Funktion DECClassByIdentity() steht dir nur die ID und die Liste aller registrierten DEC Klassen als Information zur Verfügung. Und wenn es keine Klasse mit dieser ID gibt dann kann der Fehler nur lauten: Es gibt keine registrierte Klasse mit dieser ID.

Spätestens nach dieser Fehlermeldung ist klar:
1.) entweder wurde die Klasse nicht registriert
2.) oder die ID ist falsch

Übrigens: die IdentityBase, wenn man sie verändert, sollte immer vor allen Aufrufen von TDECClass.Register manipuiliert werden. Das Identity-System im DEC kann ID-Duplikate nicht ausschließen per se. Deshalb wird beim .Register einer Klasse auch überprüft ob es eine andere Klasse gibt die die gleiche ID besitzt. Sollte das der Fall sein muß Identitybase auf einen anderen Wert gesetzt werden. Die Vorgehensweise ist also so:

1.) Identitybase auf eigenen Wert setzen
2.) alle zu benutzenden und zukünftig zu benutzenden DEC Klassen registrieren.
3.) kommt es zu einem Fehler, von wegen nicht eindeutige ID, dann neue IdentityBase wählen und bei Punkt 2.) weiter machen.

Gruß Hagen

PS: sorry das ich erst jetzt auf diesen Thread gestoßen bin, sonst hätte ich dir schon viel früher helfen können.

[Assertor]

Hallo Hagen,

Zitat:

Zitat von negaH (Beitrag 1029629)

Was willst du da verbessern können ?

Den Text. Um es klarer zu sagen: Mit "hübscher" meinte ich nur die Fehlermeldung. Die Logik des Klassenmanagement ist trivial, die beiden Fehlerfälle ebenso.

Mein Hinweis auf die Änderungen an der Fehlerbehandlung bezogen sich auf den DEC 5.3 Thread, wo ich iirc bereits auf vererbte Exceptiontypen eingehe. Dies läßt differenziertere Behandlung von Fehlerfällen auf nachgelagerten Schichten zu.

Gruß,
Assertor

Zitat:

Zitat von negaH (Beitrag 1029629)

PS: sorry das ich erst jetzt auf diesen Thread gestoßen bin, sonst hätte ich dir schon viel früher helfen können

Ich bin doch auch eben erst drüber gestolpert ;)