AGB  ·  Datenschutz  ·  Impressum  







Anmelden
Nützliche Links
Registrieren

RC4 Textlänge

Ein Thema von Sierra · begonnen am 27. Dez 2006 · letzter Beitrag vom 7. Jan 2007
Antwort Antwort
Seite 4 von 5   « Erste     234 5   
Benutzerbild von St.Pauli
St.Pauli

Registriert seit: 26. Dez 2004
351 Beiträge
 
Delphi 7 Personal
 
#31

Re: RC4 Textlänge

  Alt 5. Jan 2007, 09:59
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!
Gruß St.Pauli
  Mit Zitat antworten Zitat
Sierra

Registriert seit: 3. Sep 2005
99 Beiträge
 
#32

Re: RC4 Textlänge

  Alt 5. Jan 2007, 10:24
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.
  Mit Zitat antworten Zitat
Sierra

Registriert seit: 3. Sep 2005
99 Beiträge
 
#33

Re: RC4 Textlänge

  Alt 5. Jan 2007, 10:25
Nur das Problem war ja noch, dass zwar der Text wunderbar verschlüsselt wird, jedoch nicht mehr entschlüsselt werden kann.
  Mit Zitat antworten Zitat
Benutzerbild von St.Pauli
St.Pauli

Registriert seit: 26. Dez 2004
351 Beiträge
 
Delphi 7 Personal
 
#34

Re: RC4 Textlänge

  Alt 5. Jan 2007, 11:01
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.
Gruß St.Pauli
  Mit Zitat antworten Zitat
Benutzerbild von negaH
negaH

Registriert seit: 25. Jun 2003
Ort: Thüringen
2.950 Beiträge
 
#35

Re: RC4 Textlänge

  Alt 5. Jan 2007, 11:30
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
  Mit Zitat antworten Zitat
Sierra

Registriert seit: 3. Sep 2005
99 Beiträge
 
#36

Re: RC4 Textlänge

  Alt 5. Jan 2007, 16:18
Vielleicht hätte ich das dazu schreiben sollen.
Es soll nicht professionell sein.
Es ist lediglich ein Demonstrationsprogramm.
  Mit Zitat antworten Zitat
Sierra

Registriert seit: 3. Sep 2005
99 Beiträge
 
#37

Re: RC4 Textlänge

  Alt 5. Jan 2007, 16:20
Und jetzt will ich das nur darstellen.
  Mit Zitat antworten Zitat
Benutzerbild von negaH
negaH

Registriert seit: 25. Jun 2003
Ort: Thüringen
2.950 Beiträge
 
#38

Re: RC4 Textlänge

  Alt 5. Jan 2007, 17:48
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
  Mit Zitat antworten Zitat
Sierra

Registriert seit: 3. Sep 2005
99 Beiträge
 
#39

Re: RC4 Textlänge

  Alt 5. Jan 2007, 20:11
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?
  Mit Zitat antworten Zitat
Benutzerbild von negaH
negaH

Registriert seit: 25. Jun 2003
Ort: Thüringen
2.950 Beiträge
 
#40

Re: RC4 Textlänge

  Alt 5. Jan 2007, 21:27
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
  Mit Zitat antworten Zitat
Themen-Optionen Thema durchsuchen
Thema durchsuchen:

Erweiterte Suche
Ansicht

Forumregeln

Es ist dir nicht erlaubt, neue Themen zu verfassen.
Es ist dir nicht erlaubt, auf Beiträge zu antworten.
Es ist dir nicht erlaubt, Anhänge hochzuladen.
Es ist dir nicht erlaubt, deine Beiträge zu bearbeiten.

BB-Code ist an.
Smileys sind an.
[IMG] Code ist an.
HTML-Code ist aus.
Trackbacks are an
Pingbacks are an
Refbacks are aus

Gehe zu:

Impressum · AGB · Datenschutz · Nach oben
Alle Zeitangaben in WEZ +1. Es ist jetzt 00:17 Uhr.
Powered by vBulletin® Copyright ©2000 - 2022, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2021 by Daniel R. Wolf