RC4 Textlänge

[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.

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