Decrypten von Daten in TStringList fehlerhaft

[Kytrix]

Hallo ich verschlüssele einen String den ich dann in eine TStringList schreibe welche wiederum als datei gespeichert wird. Wennn ich nun aus dieser datei wieder entschlüsseln möchte so bekomme ich nicht das richtige ergebnis.

An der ver-/entschlüsselung kann es nicht liegen, denn:

Delphi-Quellcode:

  Test:='hallo';
  temp.Add(Encrypt(Test,w));  //temp=Tstringlist;
  test:= Encrypt(Test,w);
  temp.Add(Decrypt(test,w)) ;

klappt.

kann es sein das zusätzliche zeichen aus der datei in die Stringlist geschrieben/gelesen werden die die ver-/entschlüsselung "verfälschen"?

Delphi-Quellcode:

procedure TfMain.BtOpenEncryptedClick(Sender: TObject);//decrypt from file
Var w:Word;
begin
  w:=  16518;

  OpenDialog1.Execute;
  Info.LoadFromFile(OpenDialog1.FileName);

  EdShowInfo.Text:=Decrypt(Info.Text,w);
end;

procedure TfMain.SaveEncrypted(Sender: TObject);//save encrypted to file
Var InformationText: TStringList;
  w:Word;
  Test:String;
begin
  w:=  16518;
  InformationText:=TstringList.Create();
  Test:=Encrypt('TEST',w);
  InformationText.Add(Test);
  InformationText.SaveToFile(ExtractFilePath(ParamStr(0))+'reg_info.dat');
  MessageDlg('The registration information file "info.dat" was successfully created in:'+sLineBreak+sLineBreak+
              '"'+ExtractFilePath(ParamStr(0))+'"',mtInformation,[mbOK],0);
end;

function Encrypt (const s: string; Key: Word) : string; 
var
  i : byte;
  c1,c2: Integer;
begin
  c1:=823748325;
  c2:=1343424;
  Result:=s;
  SetLength(Result, length(s));
  for i := 1 to (length (s)) do
  begin
    Result[i] := Char (byte (s[i]) xor (Key shr 8));
    Key := (byte (Result[i]) + Key) * c1 + c2
  end
end;

function TfMain.Decrypt (const s: string; Key: Word) : string;
var
  i : byte;
  c1,c2: Integer;
begin
  c1:=823748325;
  c2:=1343424;
  begin
    SetLength(Result, length(s));
    Result:=s;
    for i := 1 to (length (s)) do
    begin
      Result[i] := Char (byte (s[i]) xor (Key shr 8));
      Key := (byte (s[i]) + Key) * c1 + c2
    end
  end;
end;

procedure TfMain.FormCreate(Sender: TObject);
begin
  Info:=TStringList.Create;
end;

[Uwe Raabe]

Eine StringList speichert ihre Daten zeilenweise in einer Text-Datei. Beim Lesen werden diese Zeilen wieder zu einzelnen Stringlist-Einträgen. Kannst du sicherstellen, daß deine verschlüsselten Strings keine Zeilenende-Zeichen beinhalten?

[Kytrix]

Es handelt sich bei dem "Text" der verschlüsselt wird und dann verschlüsselt abgespeichert wird um einen einzigen String abgesehen davon und um auf die eigentliche frage zu antworten: nein kann ich nicht bzw. wie soll ich das sicherstellen ?

schonmal ein danke im voraus =)

[sx2008]

Beim Verschlüsseln mit XOR entstehen aus einem Text binäre Daten, die man nicht verlustlos in einer StringList speichern kann.
Möglichkeit 1:
Auf StringList als Zwischenspeicher verzichten und stattdessen den String direkt speichern und laden.

Möglichkeit 2:
Des verschlüsselten String mit Base64 oder Base16 kodieren, damit keine undruckbaren Zeichen (inbesondere das Zeichen #0) in die Stringliste kommen.
Beim Entschlüsseln braucht man dann natürlich die Umkehrfunktion.

Base16 ist nichts anderes als die bekannte hexadezimale Codierung, bei dem 1 Byte mit 256 Zuständen in zwei Zeichen (0-F) umgewandelt wird.
http://www.delphipraxis.net/39740-he...aerstring.html

[himitsu]

Was macht denn Encrypt?

Wenn bei der Verschlüsselung aus "einfachen" Zeichen "Steuerzeichen" entstehen, dann handelt es sich quasi um "binäre" Daten und diese darfst du nicht in Komponenten laden, welche auf entsprechende Steuerzeichen reagieren.

Bei der TStringList sind das vorallem #0, #10 und #13.
- alles nach einer #0 wird ignoriert
- und Zeichen #10 und #13 werden eventuell umgewandelt, bzw. die TStringList paßt Zeilenumbrüche an den des Systems an

[Uwe Raabe]

Zitat:

Zitat von himitsu (Beitrag 1179848)

Was macht denn Encrypt?

Steht doch im Code...

Zitat:

Zitat von himitsu (Beitrag 1179848)

Wenn bei der Verschlüsselung aus "einfachen" Zeichen "Steuerzeichen" entstehen, dann handelt es sich quasi um "binäre" Daten und diese darfst du nicht in Komponenten laden, welche auf entsprechende Steuerzeichen reagieren.

Bei der TStringList sind das vorallem #0, #10 und #13.
- alles nach einer #0 wird ignoriert
- und Zeichen #10 und #13 werden eventuell umgewandelt, bzw. die TStringList paßt Zeilenumbrüche an den des Systems an

Das ist genau das worauf ich hinaus wollte. Wenn du nicht sicherstellen kannst, daß keine Steuerzeichen innerhalb des Strings auftauchen, kannst du keine StringList (zumindest nicht zum Schreiben in und Lesen aus einer Datei) benutzen.

[Kytrix]

Delphi-Quellcode:

function HexStringToStr(s : string):string;
begin
  if s = '' then
    Result := ''
  else
  begin
    if Odd(length(s)) then
      s := '0'+s;
    SetLength(Result, Length(s) div 2);
    HexToBin(Pchar(s), PChar(Result), Length(Result));
  end;
end;

procedure TfMain.BtOpenClick(Sender: TObject);
Var w:Word;
    Crypt: String;
begin
  w:=16518;

  OpenDialog1.Execute;
  RegInfo.LoadFromFile(OpenDialog1.FileName);
  Crypt:=RegInfo.Text;
  EdShowInfo.Text:=Decrypt(HexStringToStr(Crypt),w);// load decryptet from Base16
end;

und

Delphi-Quellcode:

function StrToHexString(const s : string):string;
begin
  if s = '' then
    Result := ''
  else
  begin
    SetLength(Result, Length(s)*2);
    BinToHex(PChar(s), PChar(Result), Length(s));
  end;
end;

procedure TfMain.SaveEncrypted(Sender: TObject);
Var InformationText: TStringList;
  w:Word;
  Crypt:String;
begin
  fMain.Visible:=false;
  w:=  16518;
  InformationText:=TstringList.Create();
  Crypt:=StrToHexString(Encrypt(CreateRegInfo,w)); // Save encrypted as Base16
  InformationText.Add(Crypt);
  InformationText.SaveToFile(ExtractFilePath(ParamStr(0))+'reg_info.dat');

end;

jetzt bekomme ich einen halb richtig entschlüsselten string :D

edit: irgendwo ist noch der wurm drinne ^^

danke für die antworten

[Kytrix]

es wird immer die hälfte der länge des verschlüsselten und strings richtig entschllüsselt

[p80286]

Da würde ich ein neueres Delphi mit UniCode-Char vermuten.
Natürlich wäre es für die Fehlersuche auch hilfreich,zu sehen mit welchen Daten Du arbeitest.

Gruß
K-H

[Bummi]

Warum liest/schreibst (ver/enrschlüsselst) Du die Daten nicht in einen (File)Stream, dann hättest Du den ganzen (Unicode)Stringärger "von der Backe"?

[Kytrix]

Ich nutze XE2 wie behebe ich den jetzt das problem ? ich weiß nicht wo ich ansetzen soll

[Sir Rufo]

Stell dir vor, du bist ein Zauberer, der Äpfel (Strings) in ein rohes heiles Ei verwandeln (encrypten) und auch wieder zurück in einen Apfel verwandeln (decrypten) kann.
Deine Assistentin kann mit verbundenen Augen Äpfel fangen.
Du verwandelst jetzt einen Apfel in ein Ei und wirfst es der Assistentin zu.
Die erwartet aber einen Apfel und was kann passieren?
Jo, das Ei könnte kaputt gehen, und die Rückverwandlung klappt nicht mehr.

Genau das passiert mit deinem verschlüsslten String. Nach der Verschlüsselung ist das kein String mehr und darf infolge dessen auch nicht mehr als solcher behandelt werden (was du aber machst) ;)

[jfheins]

Zitat:

Zitat von Kytrix (Beitrag 1179901)

Ich nutze XE2 wie behebe ich den jetzt das problem ? ich weiß nicht wo ich ansetzen soll

Ich praktiziere jetzt mal "Hilfe zur Selbsthilfe" :wink:
Wie in Beitrag #10 gesagt, empfiehlt sich ein Filestream. Damit kannst du "Binärdaten" (also auch nicht druckbare Zeichen und so) problemlos verarbeiten.
Gundzüge sehen ungefähr so aus:

Delphi-Quellcode:

str := Encrypt(...);
fs := TFilestream.Create(...);
try
  fs.WriteBuffer(Length(str));
  fs.WriteBuffer(str[1]);
finally
  fs.free();
end;

Konkrete Codebeispiele kannst du sicher über eine Suchmaschine finden.

[Uwe Raabe]

Zitat:

Zitat von Sir Rufo (Beitrag 1179903)

Stell dir vor, du bist ein Zauberer, der Äpfel (Strings) in ein rohes heiles Ei verwandeln (encrypten) und auch wieder zurück in einen Apfel verwandeln (decrypten) kann.
Deine Assistentin kann mit verbundenen Augen Äpfel fangen.
Du verwandelst jetzt einen Apfel in ein Ei und wirfst es der Assistentin zu.
Die erwartet aber einen Apfel und was kann passieren?
Jo, das Ei könnte kaputt gehen, und die Rückverwandlung klappt nicht mehr.

Vermutlich entsteht Apfelmus.

Sehr schöne Analogie :thumb:

[p80286]

Das Apfelmus passt inhaltlich ja besser, trotzdem :thumb::thumb::thumb:

Gruß
K-H

[Sir Rufo]

Zitat:

Zitat von jfheins (Beitrag 1179908)

Delphi-Quellcode:

str := Encrypt(...);

Irgendwie sieht das wieder falsch aus, denn man könnte bei der Variable str vermuten, dass diese als string deklariert ist, und das ist nach dem Encrypten eben nicht mehr zutreffend.

[jfheins]

Zitat:

Zitat von Sir Rufo (Beitrag 1179913)

Irgendwie sieht das wieder falsch aus, denn man könnte bei der Variable str vermuten, dass diese als string deklariert ist, und das ist nach dem Encrypten eben nicht mehr zutreffend.

Soll ja auch nur ungefähr sein :mrgreen:
Andererseits eigenen sich in Delphi Strings zur Aufnahme binärer Daten und seine Funktion gibt ja bereits eine String zurück. Müsste also schon gehen... oder?

[Uwe Raabe]

Zitat:

Zitat von Sir Rufo (Beitrag 1179913)

Zitat:

Zitat von jfheins (Beitrag 1179908)

Delphi-Quellcode:

str := Encrypt(...);

Irgendwie sieht das wieder falsch aus, denn man könnte bei der Variable str vermuten, dass diese als string deklariert ist, und das ist nach dem Encrypten eben nicht mehr zutreffend.

Ein Delphi-String ist durchaus in der Lage, nicht-druckbare Zeichen, wie CR, LF oder #0 korrekt zu speichern. Macht man daraus aber durch Zuweisung oder Cast einen PChar, dann wird beim ersten #0 abgeschnitten.

[p80286]

Da hast Du natürlich recht, aber
seitdem das Windows-API an sehr vielen Stellen, auch unbeabsichtig mitspielt, ist diese Benutzung mit Vorsicht zu genießen.
es gibt hier im Forum viele Posts, die darauf schließen lassen, daß ein String ein irgendwie magischer Datenspeicher ist, der alle in ihm enthaltene Daten auf magische Weise sinnvoll darstellen kann;
Und irgendwie ist dies nicht auszurotten.
Selbst für gestandene Delphianer ist dies ein Thema, was nicht ohne Tücken ist. ((Unicode)-Char)
(und da muß dann ein x0000 als Begrenzer herhalten.)

Gruß
K-H

[Uwe Raabe]

Zitat:

Zitat von p80286 (Beitrag 1179918)

Da hast Du natürlich recht, aber
seitdem das Windows-API an sehr vielen Stellen, auch unbeabsichtig mitspielt, ist diese Benutzung mit Vorsicht zu genießen.

Ich wollte damit auch nicht die Verwendung rechtfertigen, sondern nur aufzeigen, warum es in manchen Situationen scheinbar funktioniert. Ein String als Datentyp für einen Binärwert ist natürlich Unsinn, aber gegen einen harten Cast auf PChar, damit der API-Aufruf kompiliert, ist auch der korrekte Typ machtlos.

[Kytrix]

habe das hier gefunden http://www.swissdelphicenter.ch/de/showcode.php?id=1629

nutze es und es funktioniert auch zumindest soweit man die ergbnise optisch auf dem bildschirm vergleicht.
mit dem auge betrachtet ist das original der zuerst verschlüsselt und dann entschlüsselten kopie identisch.

jedoch nutze ich eine xml datei für eine TClientDataset... und das gibt mir ein "missmatch in datapacket" aus wenn ich die entschlüsselte verschlüsselte kopie der original xml einlesen will mit

Dataset.LoadFromFile(...)

:?:

[Kytrix]

ok sry habs selbst gefunden musste das data set mit

dataset.SaveToFile(ExtractFilePath(ParamStr(0))+'D B2.xml',dfbinary);

als Binary speichern

danke trotzdem =) !