Verschlüsselung im Net-Framework

[Mario]

Ich habe heute Beispiele für Verschlüsselung im Net-Framework gefunden. Prinzipiell tut es ja, aber sicher kennen alle von Euch, die mit Net zu tun haben, den Reflektor. Damit kann ich wunderschön, alle Konstanten und Routinen anschauen. Normalerweise stört es mich nicht, aber bei einer Verschlüsselung die für das Ver- und Entschlüsseln den selben Key verwendet, mache ich die Verschlüsselung damit fast sinnlos.

Habe ich da was übersehen?

[Lemmy1]

Zitat:

Zitat von Mario

Ich habe heute Beispiele für Verschlüsselung im Net-Framework gefunden. Prinzipiell tut es ja, aber sicher kennen alle von Euch, die mit Net zu tun haben, den Reflektor. Damit kann ich wunderschön, alle Konstanten und Routinen anschauen. Normalerweise stört es mich nicht, aber bei einer Verschlüsselung die für das Ver- und Entschlüsseln den selben Key verwendet, mache ich die Verschlüsselung damit fast sinnlos.

Habe ich da was übersehen?

Generell sollte ein Key nicht im Programm fest hinterlegt sein. Auch bei nicht-dotnet Programmen ist das unsicher, nur nicht GAANZ so offensichtlich...die Frage ist, WAS Du genau vor hast: Willst Du z.B. Passwörter in ner DB abspeichern dann sollte man die nicht verschlüsseln sondern stattdessen mit nem Machine Key hashen.

Was genau hast Du vor, dann kann ich vielleicht helfen?

[Mario]

Eigentlich ist es relativ einfach: Ich will den Inhalt von StringListen verschlüsseln. Das soll diese vor Manipulationen schützen. Der Schlüssel muss also für alle Zielsysteme gleich sein. Hast Du eine Idee?

[Lemmy1]

Zitat:

Zitat von Mario

Eigentlich ist es relativ einfach: Ich will den Inhalt von StringListen verschlüsseln. Das soll diese vor Manipulationen schützen. Der Schlüssel muss also für alle Zielsysteme gleich sein. Hast Du eine Idee?

Früh auf :)

Hab die Anwendung noch nicht ganz verstanden:

Du hast hart-verdrahtete StringListen in einer Exe und willst verhindern, dass jemand die ändert? Richtig soweit? Wenn ja wär wahrscheinlich ein Tool das Exen vor Modification schützt das Richtige...

P.S.: Hab in einer Stunde meine Vordiplomsprüfung (schluck) kann daher erst heute nachmittag antworten :)

[Mario]

Das Problem ist ganz einfach: Wir liefern unsere Übersetzungen in einfachen Text-Dateien mit. Das ist einfach und erfordert keine Treiber etc.. Wir möchten uns nun aber davor schützen, dass jemand diese Texte abändert, also haben wir Sie einfach verschlüsselt, da uns so niemand ohne großen Aufwand Texte unterschieben kann. Das wäre natürlich sinnfrei, wenn der Key recht einfach im Reflector zu finden ist. Genau hier hoffe ich, dass es irgendeine grundsätzliche Lösung für das Problem gibt.

[Dax]

Nimm doch den Hashcode des Schlüssels als Schlüssel für deine Verschlüsselung.. .NET hat soweit ich weis ja Hash-Algos implementiert, und wenn jemand, der dein Prog knacken will, nicht weiß, welchen du benutzt, steht er trotz Kenntnis des Keys dumm da ;)

[Mario]

Aber ein Hash ist eine Einweg-Verschlüsselung. Ich muss aber wieder entschlüsseln, da ich die Texte ja anzeigen will.

[Dax]

Ich meinte das so: Du hast deinen Key. Den schickst durch einen Hash-Algo und verschlüsselst damit deine Texte. Die bindest du in dein Programm ein. Im Programm hast du deinen ungehashten Key eingebaut. Zum entschlüsseln deiner Texte hashst du den Key und verwendest das Resultat als zum entschlüsseln der Texte.

Kurz: Nicht mit dem Schlüssel wird ver/entschlüsselt, sondern mit dessen Hash-Wert ;)

[Mario]

Habe ich vielleicht noch nicht richtig verstanden, darum frage ich nochmal nach:

Im ausgelieferten Programm ist damit der Schlüssel und dessen Hashen "dokumentiert", was die Basis fürs Entschlüsseln ist. Somit liefere ich ja auch alles mit für eine erneute Verschlüsselung, oder?

[Dax]

Wenn du das so siehst, bleibt dir nichts anderes übriges, als deine Texte wirklich als Texte, nicht verschlüsselt, mitzuliefern, oder den Entschlüsselungscode in eine DLL zu packen und irgendwie einzubinden..

[Lemmy1]

Hrm später Antwort sorry...

Ich glaube nicht, dass Verschlüsselung Dein Problem überhaupt lösen kann. Das Problem ist, dass Du einen User daran hindern willst, etwas auf seinem Rechner zu tun. Sowas wird nie perfekt gehen. D.h. du kannst zwar Verschlüsseln etc aber der User kann sich den .NET code ja dekompilieren und anguckn und dann hast eigentlich immer verloren. Wenn Du den entsprechenden Code in eine Dll packst, wirds auch nicht viel helfen weil da ja dann dasselbe gilt :) Das bedeutet grundsätzlich erstmal: Du kannst keine prinzipielle Lösung finden aber versuchen, es dem User schwer zu machen.

Wie gesagt nochmal: DotNet erzeugt dieses Problem nicht aber es wäre ohne .NET halt für einen User schwieriger, an den Code/die Texte etc ranzukommen. (Dekompilierung ist halt in der nativen Welt schwieriger).

Wie wärs, wenn Du den Textfilereader als native Dll implementierst, sprich Win32 und da irgendeine Form von Verschlüsselung machst?

Ansonsten versuch, den Key irgendwie kompiliziert zu generieren...nimm mehrere private functionen in einer Klasse die das bewerkstelligen und lass dann das ganze obfuskieren.

[Lemmy1]

Grad nochmal drüber nachgedacht....prinzipiell ginge natürlich auch Public-Private Verschlüsselung. D.h. Du verschlüsselt mit Deinem privaten Key die Texte und via Public key wird entschlüsselt. Vorteil: Niemand kann verschlüsselte Texte so erzeugen, dass sie mit Deinem Public Key einen gewünschten Text ergeben.

Im Klartext als:
- Generier ein Key-Paar Public und Private
- Verschlüssel via Private Key
- Irgendwohin schreiben
- Entschlüssel im Programm via Public

Sollte eigentlich sicher sein womit ich meine vorige Aussage ad absurdum geführt habe :) Kann Dir aber nix dazu sagen, wie man das im .NET Framework bewerkstelligt...irgendwo unter System.Security jedenfalls :)

[Mario]

Danke für die Info. Das werde ich mir mal anschauen.