RcX die Hundertste

[Jo78]

Hallo zusammen,
also ich muss zugeben ich schäme mich schon fast dieses Thema jetzt eröffnen zu müssen :oops:

Ich versuche seit mehreren Tagen eine RcX Verschlüsselung und Entschlüsselung hinzubekommen. Dazu nutze ich folgende Unit (vielen Dank an den Verfasser): http://www.delphipraxis.net/301240-post3.html

Ich möchte aus einer Textdatei mit der Endung.ini verschlüsselten Text in eine Listbox laden (listbox3) und diese dann in die Listbox2 entschlüsseln. In der Textdatei sind Zahlen die mittels | als Seperator getrennt sind.

Mein Problem ist, es funktioniert zwar grundsätzlich, aber nicht zuverlässig. Ich habe das Gefühl nicht sauber zu arbeiten und dadurch bei kleinen Abweichungen sofort keine gültige Verschlüsselung mehr zu haben.

Hier meine Prozedur:

Code:

procedure TForm1.encode;
var
  I: Integer;
  R: TRCxContext;
begin
listbox3.Items.LoadFromFile('sec.ini');
  ListBox3.Items.BeginUpdate;
  try
    RCxInit(R, 'pass1234');
    ListBox2.Items.Clear;
    for I := 0 to ListBox3.Items.Count -1 do
      ListBox2.Items.Add(RCxencode(R, listBox3.Items[I]));
  finally
    ListBox3.Items.EndUpdate;
    RCxDone(R);
  end;
end;

Zum Decoden das gleiche in grün mit RCxdecode.

1) Ist das grundsätzlich in Ordnung? Ich denke mal nicht :(

Zusätzlich habe ich auch das beschriebene Problem: http://www.delphipraxis.net/301240-post3.html

Allerdings kann ich mit der TStream Lösung nichts anfangen, da ich ja eben nicht die verschlüsselte Datei entschlüsselt speichern möchte, sondern nur temporär für das laufende Programm entschlüsseln.


2) Bei der Unit von Hagen wird GetTickCount reklamiert wenn ich nicht Zusatzangaben im uses Bereich mache, ist korrekt?

Ich mache Delphi nur Hobbymäßig und komm normalerweise mit meinen Sachen und über die Suche gut zurecht. Aber das ist für mich wohl noch ein Level zu hoch. Demnach würde ich mich wirklich freuen, wenn ihr mir weiterhelfen könntet.


Vielen Dank,
Gruß
Joachim

[p80286]

Wenn ich nichts übersehen habe, dann arbeitet die von Dir genutzte Unit mit 8BitChar, wenn Dein Delphi mit 16BitChar arbeitet, hast Du erst einmal ein Problem.
Und ein verschlüsselter String kann auch Zeichen enthalten, die nicht Darstelbar sind, da könnte es auch einmal krachen.
Was ist denn wenn Du einen zu verschlüsselden und einen verschlüsselten und einen entschlüsselten String nutzt?

Gruß
K-H

[Jo78]

Hallo,
vielen Dank für deine schnelle Antwort.

Ich darf durch Vitamn B Delphi XE mitnutzen. Ist die Unit dann ohne weiteres nicht kompatibel?

Deinen Vorschlag habe ich bisher noch nicht getestet und wüsste auch nicht wie ich den in der oben genannten Prozedur verwirklichen könnte.

Irgendwie dachte ich es würde zuverlässige Methoden geben das ganze sauber und ausfallsicher zu gestalten...

Vielen Dank,
Gruß
Joachim

[DeddyH]

Wie sieht es aus, wenn Du alle Strings explizit als AnsiStrings deklarierst (sowohl in der RcX-Unit als auch bei den übergebenen Argumenten)?

[Luckie]

Was p80286 sagen wollte: Die Unit wurde für und mit einem Delphi geschrieben, bei dem der Datentyp String noch ein AnsiString war. Bei dem Delphi, was du nutzt ist der Datentyp String aber ein WideString. Und somit passen die Unit und dein Delphi nicht zusammen.

Aber warum wollt ihr alles jetzt wieder auf AnsiString runterbrechen? Jahre lang wurde sich beschwert, dass Delphi kein Unicode unterstützt und jetzt tut es das und anstatt alten Code Unicode fähig zu machen, kommt hier immer der Vorschlag alles doch wieder auf AnsiStrings umzustellen. Das verstehe ich einfach nicht.

[DeddyH]

Vielleicht kam der Vorschlag, um zu ermitteln, ob es wirklich ausschließlich ein Ansi-/Unicode-Problem ist oder evtl. noch andere Dinge da hineinspielen könnten?

[Luckie]

Der zweite Absatz bezog sich jetzt nicht speziell auf dieses Problem. Aber immer wieder wenn eine Ansi/Unicode Inkompatibilität auftaucht0, wird dazu geraten aus den Strings AnsiStrings zu machen, anstatt den Code entsprechend an Unicode anzupaasen. Der einzige, der das nicht macht ist himitsu.

[DeddyH]

Dann pass den Code doch an, ich habe das gerade "mal eben" versucht und bin geguttenbergt2 ("Vorerst gescheitert") :mrgreen:

[p80286]

Zitat:

Zitat von Luckie (Beitrag 1142531)

Der zweite Absatz bezog sich jetzt nicht speziell auf dieses Problem. Aber immer wieder wenn eine Ansi/Unicode Inkompatibilität auftaucht0, wird dazu geraten aus den Strings AnsiStrings zu machen, anstatt den Code entsprechend an Unicode anzupaasen. Der einzige, der das nicht macht ist himitsu.

Nach meinem Dafürhalten, ist dies der richtige Weg, wenn man eine alte Unit outofthebox nutzt.
Für den zukünftigen Einsatz spricht nichts dagegen solche units mit den entsprechenden 16Bittern aufzurüsten.
Ich persönlich bevorzuge in solchen Fällen die Übergabe durch array of Byte, array of word etc.

Gruß
K-H

[himitsu]

Zitat:

Zitat von Luckie (Beitrag 1142531)

Der zweite Absatz bezog sich jetzt nicht speziell auf dieses Problem. Aber immer wieder wenn eine Ansi/Unicode Inkompatibilität auftaucht0, wird dazu geraten aus den Strings AnsiStrings zu machen, anstatt den Code entsprechend an Unicode anzupaasen. Der einzige, der das nicht macht ist himitsu.

Wobei es hier ein klitzekleines Problem gibt.

Da hier ein "String" binär verändert wird und man keinerlei gemeinsamkeiten zwische ANSI und Unicode herstellen kann, muß man sich auf ein Format einigen.

> Char/String war hier also schon immer ein Fehler.

* Entweder man macht alles mit ANSI (AnsiString)

* oder man macht alles mit Unicode (UnicodeString, bzw. WideString in älteren Delphis oder immer das delphifremde WideString)

* oder man lebt damit, daß die Ergebnisse nicht zwischen ANSI- und Unicode-kompilierten EXEn kompatibel sind
(abgesehn davon, daß RCx nunmal nicht "direkt" auf CHARs angewendet werden kann *1, da hinterher keine "korrekten" CHAR-Werte rauskommen, entsprechend dem zugrundeliegenden Encoding)

* oder man geht einen Kompromis ein und nimmt z.B. UTF-8

= in den jeweiligen Zielsystemen kann man die Texte/Variablen/Parameter ja entsprechend konvertieren, wie es einem beliebt.



- ANSI-Speicherung/Verschlüsselung > hier könnte es sein, daß nicht alles vom UNICODe gespeichert werden kann, aber Laden ist immer möglich

- Unicode (UTF-8 = Unicode) > hier kann es Probleme beim Laden geben, wenn es nach ANSI konvertriert wird, aber speichern ist immer möglich





Und nun zu diesem speziellen Problem:
Nicht die CHARs verschlüsseln, sondern die Bytes.

Die Datei also z.B. in einen Stream laden und dann byteweise verschlüsseln.
Ob die Datei nun Unicode oder ANSI ist ist dabei vollkommen egal ... Byte ist Byte. :angle:




1) Dass "früher" RCx direkt auf AnsiChar losgelassen wurde, war ein Fehler und entstand dadurch, daß "zufällig" SizeOf(AnsiChar) = SizeOf(Byte).
Da sich das Char aber angepaßt hat und jetzt ein WideChar ist, ergibt sie dieses Problem des SizeOf(WideChar) <> SizeOf(Byte), da RCx nunmal als byteweise Kodierung entwickelt wurde und am Ende auch noch "unberechenbare" Bytes rauskommen können, welche eine TEXT-weise Verrbeitung unmöglich macht.

[Jo78]

Vielen Dank für eure Antworten.
Also wenn ich stur alle Strings zu AnsiStrings umschreibe läuft es trotzdem nicht sauber. Sprich teilweise funktioniert es, ändere ich den text etwas funktioniert es nicht mehr. Genau das was ich eben mit unsauber meinte.

Zudem haut mir der Compiler mehrfach diese nette Meldung um die Ohren:

Code:

[DCC Warnung] mcry.pas(74): W1058 Implizite String-Umwandlung mit potenziellem Datenverlust von 'string' zu 'AnsiString'

Ich will mal ganz ehrlich sein: Irgendwie finde ich die ganze Methode mit diesen nicht darstellbaren Sonderzeichen unsauber.

himitsu, dein Vorschlag byteweise zu verschlüsseln hört sich gut an. Nur leider kann ich damit überhaupt nichts anfangen, sprich ich weiß nicht mal im Ansatz wie ich das umsetzen kann.

Was ich nicht verstehe ist warum hier nicht mehr Leute an Verschlüsselung interessiert sind. Es wird doch sichere mehrere Leuten geben die Sachen für ihr Programm extern abspeichern müssen und den ganzen Kram nicht jedem präsentieren möchten.

Edith sagt: Vielleicht sind meine Listboxen auch der falsche Ansatz? Nicht das die guten Boxen den Code weil er zu lang ist zerhackstückeln? Wüsste allerdings nicht welche Komponente ich dafür sonst nehmen sollte.


Vielen Dank,
Gruß
Joachim

[DeddyH]

Ich habe gerade noch ein älteren Thread zum Thema gefunden: http://www.delphipraxis.net/124699-r...r-delphi7.html

[Jo78]

Hallo,
vielen Dank nochmal für den Link. Habe dort den letzten Post befolgt.

Im Prinzip funktioniert es. Das Problem ist, teilweise verschluckt er sich ab einer gewissen Länge. Damit ihr nicht länger rumrätseln müsst was ich falsch gemacht habe, findet ihr die beiden pas Dateien anhängend.

Es wäre wirklich nett, wenn sich jemand den Kauderwelsch mal anschauen könnte :oops:

Zur Erklärung: In der oberen Listbox2 soll der Text in Klartext stehen, in Listbox3 verschlüsselt. Im Memofeld kann ich den Text bearbeiten.

Reihenfolge: Entschlüsseln (Button1) -> in Memobox laden (listbox2.onclick) -> bearbeiten (button3) -> verschlüsseln (button2) -> speichern(button4).

Anwendungsbeispiel (Eingabe):

Code:

123456789123456789123456789123456789123456789123456789123456789123456789123456789123456789

Vielen Dank,
Gruß
Joachim

[p80286]

Für die Warnung ist folgendes verantwortlich:

Delphi-Quellcode:

   for I := 0 to ListBox3.Items.Count -1 do
      ListBox2.Items.Add(RCxencode(R, listBox3.Items[I]));

Insbesonders wenn Windows seine Finger im Spiel hat, kann es tödlich sein, visuelle Komponenten für die Textspeicherung zu nutzen.
Wenn Du schon mit listboxen arbeiten willst, dann mach es doch wenigstens so:

Delphi-Quellcode:

var
  myinstring : ansistring;
  myencryptedstring : ansistring;
  
  mydecryptedstring : ansistring;

 for I := 0 to ListBox3.Items.Count -1 do begin
   myinstring:=ListBox3.Items[i];
   myencryptedstring:=RCxencode(R, myinstring);
   ListBox2.Items.Add(myencryptedstring);
   mydecryptedstring:=RCxdecode(R, myencryptedstring);
 end;

Dann gibt es zwar immer noch die Warnung, aber Du kannst die notwendigen Daten wenigstens laufend überprüfen.

Und überprüfe einmal den Inhalt von myinstring und mydecryptedstring wenn beide einen unterschiedlichen Inhalt haben, dann ist ein Wurm in deiner Ver-/Entschlüsselung.

Gruß
K-H

[Jo78]

Hallo nochmal,
vielen vielen Dank für deine hilfreiche Antwort.

Ich habe mir das geschriebene zu Herzen genommen und arbeite nun komplett ohne visuelle Komponenten. Alles wird in AnsiStrings verarbeitet und dann direkt in die Textdatei geschrieben.

Die Überprüfung ob Eingabewert und Verschlüsselung übereinstimmen habe ich ebenfalls eingebaut. Ergebnis: Übereinstimmung :-D Demnach muss das Verschlüsseln an sich jetzt korrekt sein.

Das Problem liegt möglicherweise im Speichern (und späteren Laden) in normale Textdateien. Wenn ich die Datei lade entschlüsselt er nicht richtig sondern nur einen Teil. Schaue ich mir die Verschlüsselung in der Textdatei an sind da neben nicht darstellbaren Sonderzeichen auch Leerzeichen.

Prozedur zum verschlüsseln & testen:

Code:

procedure TCry.btmakeClick(Sender: TObject);
var vergleich,fertig,textzeile: ansistring;
var R: TRCxContext; Datei: TextFile;
begin
Trim(textzeile);
try
    RCxInit(R, 'k9N7ZgV7aX');
      fertig:=(RCxdecode(R, textzeile));
  finally
    RCxDone(R);
     end;
AssignFile(Datei, 'sec.ini');
Rewrite(Datei);
if IOResult = 0 then
 begin
 writeln(Datei,fertig);
 closeFile(Datei);
   end;
// nur zum pruefen
   try
    RCxInit(R, 'k9N7ZgV7aX');
      vergleich:=(RCxencode(R, fertig));
  finally
    RCxDone(R);
     end;
if vergleich = textzeile then showmessage('Identisch');
  end;

Meine Prozedur zum Öffnen und Entschlüsseln:

Code:

procedure TForm1.laden;
var ergebnis,geladen:AnsiString; R: TRCxContext; Datei: TextFile;
begin
AssignFile(Datei, 'sec.ini');
Reset(Datei);
ReadLn(Datei,geladen);
CloseFile(Datei);
  try
    RCxInit(R, 'k9N7ZgV7aX');
      ergebnis:=RCxencode(R,geladen);
  finally
    RCxDone(R);
  end;
AssignFile(Datei, 'sec2.ini');
ReWrite(Datei);
WriteLn(Datei,ergebnis);
CloseFile(Datei);
end;

Findet dort jemand einen Fehler oder hat sonst eine Idee woran es liegen könnte? Da die Übereinstimmungsprüfung positiv ausfällt kann es ja "nur" am falschen Speichern oder Laden liegen?
Für die Hilfe welche mir bisher zu Gute gekommen ist nochmal herzlichen Dank an alle Beteiligten :thumb:

Vielen Dank natürlich auch für weitere Hilfe!

Gruß
Joachim

[himitsu]

Das wurde doch schon erwähnt?

Nach dem Umkodieren mit RCx entstehen Binärdaten ... das ist kein "Text" mehr.
Du speicherst es dann aber so wie einen Text (WriteLn) und liest es auch wieder so aus (ReadLn).

ReadLn und WriteLn behandeln aber gewisse Zeichen (Zeilenumbrüche, EOF und eventuell noch die #0) auf "besondere Weise" und nun gibt es Probleme, wenn bei deiner Kodierung solche "Steuerzeichen" innerhalb des Textes entstanden sind ... da muß das Auslesen also andere Ergbnisse liefern.

[Jo78]

besten Dank für diesen Hinweis. Du hast leider vollkommen Recht, ich hätte dies schon aus deinem vorherigen Beitrag schließen können. Aber da habe ich es noch nicht verstanden, entschuldige dies bitte.

Es funktioniert jetzt alles, nochmals vielen Dank an jeden Helfer.

Gruß
Joachim