RC4 Textlänge

[Sierra]

Hi!
Ich habe mal die wunderbare RC4 Unit aus der Code-Library ausprobiert und bin auch voll und ganz zufrieden.
Es gibt nur ein Problem, nämlich wird bei einem längeren text zwar alles verschlüsselt, aber beim Entschlüsseln fehlen Textteile (hat das eventuell was mit Absätzen zu tun?).
Woran könnte das liegen?

Vielen Dank.

[negaH]

Nachdem man einen lesbaren Text verschlüsselt hat stehen im Resulat binäre Daten. Also auch das Zeichen #0 bzw. Byte = 0. Dieses Zeichen ist bei Strings aber der Null-Terminator, der einen lesbaren String beendet. Wenn du also das Resulat vom RC4 ständig neue Strings zuweist so schneidet die String-RTL diesen String ab. Suche mal nach der RCx Unit, dort wird der Resulat String in das HEX Format umgewandelt, damit kann das nicht mehr passieren.

Gruß Hagen

[Sierra]

Vielen Dank!
Ich habe zwar die Unit gefunden, die du meinst, aber welcher Teil ist jetzt unbedingt notwendig, um die hexadezimale Umwandlung zu vollziehen?

Vielen Dank.

[Sierra]

Ehrlich gesagt habe ich auch nicht die Lust, ein paar Stunden lang durch den Algorithmus zu steppen, um herauszufinden, wo das hingehört. :wink:
Deshalb wäre ich ganz dankbar, wenn mir jemand helfen könnte.

Vielen Dank.

[Sierra]

Hat denn niemand eine Antwort?

[Sierra]

Hi!
Es wäre echt nett, wenn mir jemand bei diesem Problem auf die Sprünge helfen könnte, da es sehr wichtig für mich ist.

Vielen Dank.

[gammatester]

Zitat:

Zitat von Sierra

Es wäre echt nett, wenn mir jemand bei diesem Problem auf die Sprünge helfen könnte, da es sehr wichtig für mich ist.

Wenn "es sehr wichtig" für Dich ist, kann ich Deine andere Aussage nicht ganz verstehen und andere Leute wohl auch nicht: "Ehrlich gesagt habe ich auch nicht die Lust, ein paar Stunden lang durch den Algorithmus zu steppen, um herauszufinden, wo das hingehört."

Fakt ist, wie negaH schreibt, daß in der Regel im verschlüsselten Text #0-Zeichen vorkommen:

Zitat:

Also auch das Zeichen #0 bzw. Byte = 0. Dieses Zeichen ist bei Strings aber der Null-Terminator, der einen lesbaren String beendet. Wenn du also das Resultat vom RC4 ständig neue Strings zuweist so schneidet die String-RTL diesen String ab.

Die zweite Aussage ist allerdings schlichtweg falsch. #0 ist ein völlig legales Zeichen in Strings und wird von der RTL auch so behandelt. Nur beim pchar-Typ ist es das Endezeichen. Einige VCL-Routine sind buggy mit #0 in Strings (weil sie über pchar gehen).

Wir wäre es, wenn Du die ganze Sache (fast) vom Anfang beginnst: Das einfachste ist doch, ohne zusätzliche Hex-Umwandlung den verschlüsselten Memoryblock in eine (binäre) Datei zuschreiben.

Wolfgang

[Sierra]

Das ich keine Lust habe durch den Algorithmus zu steppen liegt allein an dessen Länge.
Denn man muss sich vorstellen, dass, bis man einen #0 Wert gefunden hat, schon einige Zeichen bearbeitet werden müssen.
Und das nun von 0 bis 255 und wieder zurück.
Da sitzt man ganz schön lange dran.
Jetzt aber zu deinem anderen Tipp.
Wie genau funktioniert das?
Kannst du mir genauere Angaben machen?

Vielen Dank.

[gammatester]

Zitat:

Zitat von Sierra

Das ich keine Lust habe durch den Algorithmus zu steppen liegt allein an dessen Länge. Denn man muss sich vorstellen, dass, bis man einen #0 Wert gefunden hat, schon einige Zeichen bearbeitet werden müssen. Und das nun von 0 bis 255 und wieder zurück. Da sitzt man ganz schön lange dran.

Aber nur wenn man nicht weiß, was man eigentlich tut. Verschlüssel doch einfach einen Block von lauter #0. Dann sollten alle entschlüsselten Bytes doch wieder #0 sein, oder an Deiner Implementation ist was grundsätzlich falsch.

Zitat:

Jetzt aber zu deinem anderen Tipp. Wie genau funktioniert das? Kannst du mir genauere Angaben machen?

Du weißt, was eine Datei ist oder nicht? Wenn nicht, vergiß am besten die ganze Sache. Ansonsten hier eine Skizze:

Verschlüsseln (setzt Deine realen Proceduren ein)

rc4_int(key, keylen);
rc4_encrypt(plaintext, ciphertext, len);
assign(f,'name.rc4');
rewrite(f,1);
blockwrite(f,ciphertext,len);
close(f);

Entschlüsseln:

rc4_int(key, keylen);
assign(f,'name.rc4');
reset(f,1);
blockread(f,ciphertext,len);
close(f);
rc4_decrypt(ciphertext, plaintext, len);

[Sierra]

Du meintest bestimmt "AssignFile" und "CloseFile", oder?
Wenn ja, dann funktioniert es leider so nicht.
Auch hier werden die #0 Bytes berücksichtigt und kürzen somit leider immer noch den Text.

[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

Delphi-Quellcode:

zText1:=hatMplain.Text;

praktisch

Delphi-Quellcode:

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:

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

[Sierra]

Leider funktioniert auch das nicht.

[Klaus01]

Was heißt denn bei Dir funktioniert nicht?

Grüße
Klaus

[Sierra]

Also wenn ich das so mache, wie du vorgeschlagen hast, bekomme ich da nur Unverständliches raus.

[Klaus01]

Was erwartest Du denn wenn ein Text verschlüsselt ist?
Du solltest eine Ansammlung von Zeichen im Bereich von 0..9 und A..F sehen können.

Grüße
Klaus

[Sierra]

So weit ist das auch kein Problem.
Nur nach der Entschlüsselung kommt da nicht das raus, was vor der Verschlüsselung da stand.

[Sierra]

Gibt es denn keine Möglichkeit, die #0 zu entfernen und trotzdem den normalen verschlüsselten Text anzuzeigen?

[Klaus01]

Delphi-Quellcode:

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

Tausch mal bitte die obige Funktion aus.
War mein Fehler.

Grüße
Klaus

[Klaus01]

Zitat:

Zitat von Sierra

Gibt es denn keine Möglichkeit, die #0 zu entfernen und trotzdem den normalen verschlüsselten Text anzuzeigen?

Bei der Verschlüsselung tauchen nicht nur #0 auf sondern noch jede Menge mehr Zeichen die nicht darstellbar sind.
Deshalb werden auch Verschlüsselte Texte in Hex dargestellt.
Gespeichert werden sie hingegen jedoch binär.
Diese ganze hin und her Konvertierung brauchst Du nur weil Du die zu entschlüsselnden Daten
wieder aus einem Textfeld nimmst.

Grüße
Klaus

[Sierra]

Auch die neue Funktion funktioniert nicht ganz.
Was ich aber eigentlich möchte ist, dass nach der Verschlüsselung eher sowas

Delphi-Quellcode:

LofeL isum do}o25€Lt#”xed, conqG#tetpV2 uT9pisvy{wÒT�i4.dZOeW aT0wlit ei„e"Baq'ni~

als sowas

Delphi-Quellcode:

9277FB24CE17344AF97373473301FE02B53A0CCA84EC8AFA205F611244F931EDCDAF016219EADCB7611BC1A24095517AE25AFF0DDE0EF7B4656FCF6ACE146B70F3D4E33D262190837C500DEFBF6F61BEAD13017CD24599ECC697F73DDC313540CE741BEB2103B80D3BF010

herauskommt.

Das sieht eher nach verschlüsseltem Text aus.
Gibt es keine Möglkichkeit, die #0 einfach zu entfernen, ohne diese ganze Konvertierung?
Irgendjemand muss doch mit diesem Algorithmus arbeiten.
Und das geschilderte Problem entsteht sogar schon bei kurzen Texten.
Deshalb kann ich mir nicht vorstellen, dass niemand weiß, wie man das umgehen kann.

[Klaus01]

Nur noch ein kleiner Hinweis, dann halte ich mich hier heraus:

Texte werden nicht verschlüsselt um sie darzustellen, sondern um sie vor Einsicht zu schützen wenn sie
weitergegeben/übertragen werden.

Wenn Du es so haben willst wie Du es geschrieben hast, dann bau Dir den Filter selber.
Kann ja nicht so schwer sein, einen String zu durchsuchen und das/die Zeichen #0 zu finden.
Nur, sei Dir gewisss, daß Du den gefilterten Text nicht wieder entschlüsseln kannst,
denn es fehlen ja dann einige Zeichen.

Grüße
Klaus

[St.Pauli]

Kann Klaus01 nur voll und ganz Zustimmen. Es ist der Sinn das deinen Plaintext auf alle möglichen Bytewerte verteilet wird. Wenn du nun ein Byte aus dem Chiffretext entfernst wirst du mit diesem und dem Rest nichts mehr anfangen können.

Und im Übrigen: Wenn du meinst das ein hexadezimaler String dir nicht "professionell" genung aussieht ist es nicht unser Problem!

[Sierra]

Das sollte eigentlich auch weder eine Kritik noch ein Angriff sein.
Ich habe einfach nur die Frage gestellt, ob das möglich ist.
Und da es anscheinend nicht geht, was mir auch logisch erscheint, dann muss ich es eben anders probieren.

[Sierra]

Nur das Problem war ja noch, dass zwar der Text wunderbar verschlüsselt wird, jedoch nicht mehr entschlüsselt werden kann.

[St.Pauli]

Dann gibt es 3 Möglichkeiten wie du weitermachst:

1. Du verwendest weiterhin RC4 und stellst den String hexadezimal dar.
2. Du verwendest weiterhin RC4 und statt den Text über Controls einzulesen speicherst und lädst du ihn aus Dateien.
3. Du verwendest zum Beispiel ROT13, was zwar keine Sicherheit bietet, aber die Zeichen im Bereich des Alphabets lässt.

[negaH]

Mal ne Frage:

Warum willst du den Ciphertext in einem Memo anzeigen ?

Ich frage weil ich mich frage ;)

Was daran ist professionell ?

Besonders weil du eben nicht in der Lage bist zu kapieren das der CipherText KEIN Text ist sondern ein Stücken binäre Daten bei denen ALLE 256 möglichen Zeichen WICHTIG sind. Man kann hier nichts entfernen ohne das der Inhalt komplett zerstört wird. Das ist ja Sinn einer Verschlüsselung, die Daten zu schützen. Auch vor Veränderungen.

Lade dir mein DEC dort sind auch noch andere Text-Konverierungen enthalten. Ua. Internet MIME64 das du aus EMails kennen dürftest, also sehr professionell wenn es Browser, EMail verwenden und im Internet als professioneller Standard gilt. Oder die nimmst TFOrmat_ESCAPE. Dieses Format lässt alle als Text darstellbaren Stellen unverändert und escape'd alle anderen nicht darstellbaren ASCII Zeichen -> #10,#13,#0 usw. Auch dieses Format ist professionell.

Denn bedenke eines: Wenn TMemo auf Sonderzeichen im binärem CipherText aktiv reagiert, sie also entfernt, den "Text" abschneidet, etc. pp. dann ist es wohl für diech auch nachvollziehbar das das TMemo am Ende NICEMALS exakt das anzeigt was im CipherText drinnensteht. Kurz: du wirst niemals das 1 zu 1 im Memo sehen was im CipherText drinnesteht. Wozu dann noch sowas im Memo anzeigen wollen ? Welchen professionellen Sinn soll das haben ?

Gruß Hagen

[Sierra]

Vielleicht hätte ich das dazu schreiben sollen.
Es soll nicht professionell sein.
Es ist lediglich ein Demonstrationsprogramm.

[Sierra]

Und jetzt will ich das nur darstellen.

[negaH]

Dann solltest du die Darstellung wie in einem HEX Editor machen

links 16 Zeichen in HEX Darstellung und rechts davon 16 Zeichen als ASCII (also direkt) wobei aber nicht darstellbare Zeichen wie #0,#10,#13,TAB,BACKSPACE usw. durch einen Punkt ersetzt werden.

Vielleicht fiundest du sogar im WEB eine fertige HEX-Viewer Komponente die dein TMemo ersetzen würde.

Ansonsten könntest du auch "tricksen". Das Resulat der Verschlüsselung -> der CipherText -> speicherst du in deinem TForm als Feld ab. Das TMemo stellt zwar diesen String falsch dar, aber bei deiner Ent-Schlüsselung benutzt du nicht den Text aus dem TMemo sondern den CipherText aus deinem Feld im TForm.

Gruß Hagen

[Sierra]

Ich liege doch richtig, dass ein String nur durch #0 abgeschnitten wird, oder?
Wenn ja, dann muss der Fehler woanders liegen, denn ich habe jetzt mal (auch wenn es für die Entschlüsselung erstmal keinen Sinn ergeben würde, alle #0 mit . ersetzt.

Delphi-Quellcode:

zText2:=StringReplace(zText2, #0, '.', [rfReplaceAll, rfIgnoreCase]);

Trotzdem wird aber noch der String abgeschnitten.
Woran könnte das liegen?

[negaH]

Zitat:

Woran könnte das liegen?

Guter Ansatz bei deinem Test. Jetzt mache doch mal Nägel mit Köpfen und wage dich an die richtige Stelle des Problemes. Nimm deinen nicht funktioneirenden String, speichere diesen in eine Datei, weise ihn ein TMemo zu, lade aus dem Memo den kaputten String, speichce diesen in eine andere Datei, öffne beide Dateien mit einem HEX Editor (hast doch einen als gut ausgerüsteter Programmierer, oder ? ) und vergleiche mal beide Dateien miteinandner. WIR werden diesen Schritt nicht für DICH machen, und wenn nur einmal und bei ähnlichen Problemen in der Zukunft stehste wiederum da.

Ein TMemo nutzt intern TStrings. TStrings ist eine Liste aus Strings, einfach ausgedrück ein Array of Pointer (Strings). Also kann ein TMemo mehrere Zeilen darstellen und wenn man einen einzigen langen String dem TMemo zuweist werden die Zeichen #10 -> Line Feed und #13 -> Carrige Return im String ausgewertet. Findet TMemo bei SetText diese Zeichen so zerlegt es diesen String in 2 Teile -> ergo ein Zeilenumbruch. Das doofe daran ist das das Zeichen #10 und oder #13 einen Zeiulenumbruch ergeben. Also wenn im String nur #10 vorkommt so wirkt das wie ein Zeilenumbruch. Fragst du mit TMemo.GetText diesen ganzen String wieder ab, so baut TMemo diesen aus den einzelnen Zeilen wieder zusammen. TMemo fügt dann also selber einen Zeilenumbruch ein, und der besteht dann aus #10 und #13. Du hast also nicht mehr den originalen String.

Am besten probierst du es einfach mal aus. OHNE die RCx Units und OHNE irgendwelche Kryptographie. Baue einfach mal Strings der Form S := #10#10#13#0#13#13#10; und weise das TMemo.Lines.Text zu. Dann fragst du TMemo.Lines.Text ab und vergleichst das mit dem Original.

So. Meine vorherigen Postings haben alles erklärt was es zu erklären gab. Auch verschiedne Vorschläge was du machen könntest sind besprochen worden. Ich erwarte jetzt von dir das du mal selber versuchst dich reinzuarbeiten und bin schon auf deine Rückmeldung wie du dein Problem gelösst hast gespannt ;)

Gruß Hagen