RC4 Textlänge

[St.Pauli]

Wie gammatester schon sagte werden Strings in Delphi nicht von einem bestimmten Byte-Wert terminiert. Delphi orientiert sich lediglich an der Länge des Strings. Wenn du also einzig und allein Strings verschlüsselst und diese dann abspeicherst, sollte dir nichts passieren.

Delphi/Pascal ist jedoch mit seinen Strings ein Ausnahmefall. Windows arbeitet mit nullterminierten Strings. Wenn du nun deinen String zum Beispiel in einem Label darstellen willst, ruft die VCL Windows-Funktionen auf und konvertiert deinen String in einen nullterminierten String. Diese Konvertierung führt dazu, dass das erste #0 als ein Indikator für das Ende des Strings gewertet wird. Der Rest wird abgeschnitten. Der String 'Null' + #0 + 'terminiert' in einem Label wird also lediglich als 'Null' dargestellt werden.

[negaH]

Zitat:

Die zweite Aussage ist allerdings schlichtweg falsch.

Ist sie leider nicht, höchstens misdeutend.

Nach vielen hunderten Supportmails zu meinem DEC weis ich eines mit gewisseheit:

Der Fragesteller hat mit RC4 Strings verschlüsselt und verwendet sie dann zb. in einem TMemo oder TStringList per Zuweisung von .Text oder ähnlichen VCL/RTL Funktionen. Und innerhalb dieser Funktionen entstehen Konvertieiungen -> Abschneiden weil #0 Terminator, oder entfernen von Carrige Return und/oder Line Feed. Ursachen sind unterschiedlich, weil die RTL Windows API Funktionen auf PChar Basis aufrufen, in TStringlist selber den String zerlegen und somit Zeichen entfernen usw.

Wenn ich also von der RTL und LongStrings geredet habe so ist das nur eine unzureichende "Kurzfassung" und sollte natürlich die VCL auch umfassen. Denn wie schon gesagt wurde: wenn man die LongStrings "pur" verwendet dann gehen keine Daten verloren noch werden sie autom. manipuliert. Benutzt man aber zb. TMemo/TStrings/TStringList und solch Stuff entstehen solche Nebeneffekte.

Die Frage abd den Fragesteller ist nun: Zeige deinen vollständigen Code, und was machst du mit den Strings !?

Gruß hagen

[Sierra]

Vielen Dank Hagen!
Also ich benutze, wie du schon treffend vermutet hast, ein Memo.

Zitat:

Ursachen sind unterschiedlich.

Und genau deswegen ist es nicht so leicht, herauszufinden, wie man dieses Problem umgeht.
Also ich nutze die ganz normale RC 4 Unit.
Diese wird dann so weiterverarbeitet.

Delphi-Quellcode:

procedure TForm1.hatVerschluesselnClick(Sender: TObject);
begin
  zText1:=hatMplain.Text;
  setLength(zText2,length(zText1));
  hatRC4.RC4Init(hatRC4, hatEschluessel.Text);
  hatRC4.RC4Code(hatRC4, zText1[1], zText2[1], Length(zText1));
  hatMcipher.Text:=zText2;
end;

Delphi-Quellcode:

procedure TForm1.hatEntschluesselnClick(Sender: TObject);
begin
  zText1:=hatMcipher.Text;
  setLength(zText2,length(zText1));
  hatRC4.RC4Init(hatRC4, hatEschluessel.Text);
  hatRC4.RC4Code(hatRC4, zText1[1], zText2[1], Length(zText1));                                     
  hatMplain.Text:=zText2;
end;

[St.Pauli]

Die letzte Zeile in deinen Quelltexten ist das von uns angesprochenen Probleme.* Hier wird (ohne das du es merkst) das String-Format konvertiert. Mach es so wie von negaH angesprochen und füge nicht den ASCII-Wert direkt sondern dessen hexaldezimale Darstellung in das Memo ein.

Hier von mir mal 0815 hingeschrieben:

Delphi-Quellcode:

function StringAsHex(Value : string) : string;
var
  i : integer;
begin
  SetLength(Result, Length(Value));
  for i := 1 to Length(Value) do
  begin
    Result[i] := IntToHex(Ord(Value[i]), 2);
  end;
end;

*Natürlich ist dann auch die erste Zeile falsch, da du dir dort das schon abgeschnittene Erebnis wiederholst.

[Sierra]

Du meinst doch dann statt

zText1:=hatMplain.Text; praktisch

zText1:=StrToHex(hatMplain.Text); oder?

Jedenfalls funktioniert das so leider auch nicht.
Die HEX-Umwandlung scheint ja eine gute Idee zu sein, aber irgendwie funktioniert das leider nicht alles so wie es soll.

[Klaus01]

nein, den Ciphertext solltest Du in Hex umwandeln, denn da kommen
Zeichen wie #0 vor.

Grüße
Klaus

[Sierra]

Das klappt leider auch nicht.
Oder muss man das auch wieder zurückumwandeln?

[Sierra]

Muss man die Umwandlung vor oder nach dem Verschlüsseln durchführen?

[Klaus01]

Hallo,

ich habe im StringAsHex mal etwas geändert.
Weil ein TextZeichen = 1 Byte und daraus werden 2 HexZeichen.

Delphi-Quellcode:

function StringAsHex(Value : string) : string; 
var 
  i : integer; 
begin 
  result:='';
  for i := 1 to Length(Value) do 
  begin 
    Result := result + IntToHex(Ord(Value[i]), 2); 
  end; 
end;

Vor dem Entschlüsseln mußt Du dann die HexWerte wieder in ihre Ursprungswerte wandeln.

Delphi-Quellcode:

  FUNCTION HexToByte(s:shortstring):Byte;
  Const
     hex : string = '0123456789abcdef';
  VAR
    num:byte;
  BEGIN

     s:= lowercase(s);
     num:=(pos(s[1],hex)-1)*16+(pos(s[2],hex)-1);

     Result:=byte(num);
  END;

Delphi-Quellcode:

function HexToString(HexString:String):String;
var
  i: Integer;
begin
  for i:= 1 to lenght(HexString) div 2 do
  begin
    result:=result + chr(HexToByte(HexString[i]+HexString[i+1]));
  end;
end;

Delphi-Quellcode:

procedure TForm1.hatVerschluesselnClick(Sender: TObject); 
begin 
  zText1:=hatMplain.Text; 
  setLength(zText2,length(zText1)); 
  hatRC4.RC4Init(hatRC4, hatEschluessel.Text); 
  hatRC4.RC4Code(hatRC4, zText1[1], zText2[1], Length(zText1)); 
  hatMcipher.Text:=StringAsHex(zText2); 
end;

Delphi-Quellcode:

procedure TForm1.hatEntschluesselnClick(Sender: TObject); 
begin 
  zText1:=HexToString(hatMcipher.Text); 
  setLength(zText2,length(zText1)); 
  hatRC4.RC4Init(hatRC4, hatEschluessel.Text); 
  hatRC4.RC4Code(hatRC4, zText1[1], zText2[1], Length(zText1));                                      
  hatMplain.Text:=zText2; 
end;

Hoffe es sind nicht allzuviele Fehler drin.

Grüße
Klaus

[Klaus01]

Zitat von Sierra:

Muss man die Umwandlung vor oder nach dem Verschlüsseln durchführen?

Die Umwandlung muß durchgeführt werden bevor der Ciphertext in das Memo geschrieben wird.
Wird die Umwandlung vor dem Verschlüsseln durchgeführt, werden nur die HexZeichen verschlüsselt
und der Ciphertext hat dann wieder lauter solche Zeichen wie #0 etc.

Grüße
Klaus