Quote

Beim Geheimwort weiß ich nicht, wie man das unkenntlich machen könnte.

Ich hab mir spaßeshalber vor Jahren mal eine elektronische Enigma programmiert :) - Programmtechnisch ist das ja recht simpel umzusetzen.
Ich habe von Verschlüsselungstechnik zwar keine Ahnung, halte das aber nach wie vor für ein sehr sicheres System, zumindest solange der potentiele Codeknacker nichts über das Verschlüsselungssystem weiß.
Für ein einziges Wort dürfte es aber, trotz des nicht so großen Aufwandes, erheblich simplere Lösungen geben.

thomas
Last edited: 2013-10-04 19:35:42 +0200 (CEST)

Nix selber programmieren! Geht nur schief.
Und MD5 ist einfach zu knacken.

Du kannst ja einen SaltedHash senden. Siehe auch Crypt::SaltedHash

Nunja, das Standardverfahren um den Übertragungsweg von HTTP-Anfragen abzusichern, ist eine HTTPS-Verbindung, also eine mit SSL bzw. TLS gesicherte Verbindung.

Aber es ist natürlich auch möglich Integritäts- oder Inhaltsschutz auf Anwendungsebene einzubauen, wenngleich kryptographische Operationen immer ein wenig trickreich sind, weil man mit kleinen unscheinbaren Anwendungsfehlern sehr schnell aus einem mathematisch sicheren Verfahren ein praktisch unsicheres machen kann ;-)

Eine Prüfsumme alleine bietet natürlich noch keinen Manipulationsschutz, weil ja unterwegs sowohl die Prüfsumme als auch der Inhalt manipuliert werden könnte. Und Sicherheit darauf zu basieren, dass bestimmt keiner die genaue Funktionsweise eines Programmes kennt hat sich historisch gesehen auch immer als ausgesprochen dumme Idee herausgestellt. Ich würde HMAC mit dem Prüfsummenalgorithmus der Wahl oder ein Verfahren wie den Digital Signature Algorithm empfehlen.

Ein Passwort würde ich entweder verschlüsselt übertragen, oder, noch besser, gar nicht übertragen, sondern als Grundlage für einen Zero-Knowledge-Beweis verwenden.

Du willst also einmal signieren und einmal verschlüsseln.
Gängige symmetrische Verschlüssler sind z. B. AES, 3DES oder Twofish. Für Standardsachen sollten 128 bit Schlüssel immer noch reichen. Wenns wirklich sicher sein soll wohl eher 256.

Signieren, also etwas vor Veränderung schützen geht mit Hashfunktionen wie MD5 oder wenns auch hier wirklich sicher sein soll SHA1.
Eine fertige Implementierung ist z. B HMAC. Das kann man aber auch nachimplementieren, ist kein großes Hexenwerk

Wenn nur die Übertragung verschlüsselt sein soll, dann nimm OpenSSH.
Schon ist das Problem erfolgreich deligiert.

Was haltet ihr von Crypt::Rijndael?
Stoße dabei leider auf die selben Probleme wie hier: [Crypt-CTR] AES mit CTR oder doch nicht? und hier: Crypt::Rijndael und die blocksize die ich in beiden Threads nicht wirklich als gelöst erkennen kann. Übersehe ich was?

Crypt::CBC scheint gut zu funktionieren und hat zur angenehmen Abwechslung sogar eine verständliche Doku:

Frage 1: Kann bei diesem Verfahren wirklich sichergestellt werden, dass jemand nicht allein aufgrund des verschluesselten Binärcodes auf den Schlüssel kommen kann?

Frage 2: Das Ergebnis wird später mit der Methode POST() von HTTP::Request::Common zu einem Request für LWP::UserAgent verwurstet. Ich vermute, dass an der Stelle aus dem Binärstring Base64 werden wird. Ist das so OK oder sollte ich schon bei der Verschlüsselung eine andere Methode verwenden, damit nichts binäres raus kommt?

Frage 3: Der Parameter -cipher ist mir nicht ganz klar. In der Doku steht u.a. You may use any compatible block encryption algorithm that you have installed.. Habe ich eine Chance herauszufinden, was ich alles installiert habe? Oder bezieht sich das darauf, welche der nachfolgend erwähnten Module installiert sind?
Angenommen, davon wäre keines installiert, welche Wahlmöglichkeiten habe ich dann? Ist Blowfish die einzige?
Würde gern sicherstellen, dass das Verfahren verwendet wird, was den größten "Knackschutz" bei vertretbarem Rechenaufwand bietet.

Edit:
Frage 4: Wenn jemand während der Übertragung die Datei austauscht und mein Empfänger entschlüsselt die Datei mit dem selben Schlüssel wie der Absender, dann kommt ja trotzdem etwas raus. Das entspricht natürlich nicht mehr dem, was abgesendet wurde aber wie kann der Empfänger das feststellen?
Last edited: 2013-10-05 12:36:34 +0200 (CEST)

Erst einmal zum Passwort.
Das Passwort ist ja beiden Seiten bekannt, es muss nur sichergestellt werden, das man die Übertragung nicht nutzen kann um das Passwort wieder herzustellen. Hier eignen sich Hashingalgorithmen, um Das Passwort in eine eindeutige, aber nicht rekonstruierbare Form zu bringen. Die Gegenseite macht das selbe und vergleicht dann die erzeugten Zeichenketten miteinander. Sind sie identisch, muss aus auch das Passwort identisch gewesen sein.
Das Problem ist natürlich das ein Passwort meist aus lesbaren Zeichen besteht, recht kurz ist und häufig auch einen "Sinn" hat. Das macht das entschlüsseln einfacher. (Gerade MD5 ist da Anfällig weil man sehr effiziente Rainbowtables erstellen kann, die schon recht früh nicht darstellbare Zeichen ausschließen können und die Entschlüsselung damit sehr beschleunigen)
Hier kommt das "Salt" ins Spiel. Das ist eine zufällige Zeichenfolge, die auf das Passwort angewendet wird. Dadurch wird das Länger und komplizierter. Im Idealfall wird auch das Specktrum der verwendeten Zeichen Größer. Das Salt kann man einfach als Klartext mitschicken. Er dient nur dazu dem erzeugten Hasch eine "Rauschen" mitzugeben, was das entschlüsseln erschwert. (Bei MD5 steht die Zeit zum entschlüsseln in Fakultät zur Länge des Passworts. Wenn man Rainbowtables verwendet. Ein Zeichen mehr kann den unterschied von einem Tag zu einigen Monaten bedeuten. Wenn man das Salt nicht nur anhängt, sondern z.B. per XOR darauf anwendet wird auch die Zeichen Varianz größer und Normale Rainbowtables funktionieren nicht mehr.)

zum verschlüsselten übertragen von Daten.
Die Beste Verschlüsselung ist das XOR mit einer zufälligen Zeichenfolge, welche die selbe Länge hat wie die zu verschlüsselten Daten. Das Ergebnis ist eine Zufällig wirkende Zeichenfolge, die erst wider Sinn Ergibt wenn noch einmal Xor mit zufälligen Zeichenfolge darauf angewendet wird. Das Problem ist nun, dass man die Zufallsfolge nicht so einfach weitergeben kann. Zum einen ist das eine nicht geringe Menge an Daten, zum anderen Muss man sicherstellen das kein anderer diese Folge zu sehen bekommt.
Die Länge kann man reduzieren wenn man Pseudozufallsgeneratoren verwendet. Das sind Algorithmen, die eine Serie von Werten ausgeben, die Zufällig erscheinen. Der Nächtse Wert basiert aber immer auf dem letzten Wert der aus dem Algorithmus kam. Einerseits bedeutet es, man kann über einen Anfangswert "Seed" bestimmen welche Folge generiert wird zum anderen lässt sich aus einer genügend großen Folge der "Seed" rekonstruieren. Die Güte eines Algorithmus bestimmt sich nach welcher Anzahl von Werten er sich wiederholt, wie viele Werte man braucht um den Seed zu rekonstruieren und wie zufällig die Werte erscheinen.
Mit einem guten Pseudozufallsgenerator braucht nur noch der Seed beiden Seiten bekannt zu sein um Daten verschlüsselt übertragen zu können. Man kann natürlich das Passwort als Seed benutzen, was aber problematisch ist da ein Passwort wie schon ausgeführt nicht sehr zufällig ist. Wenn die Daten nicht extrem Brisant sind und deren Gültigkeit recht kurz ist. Kann das schon reichen.

Besser ist es aber den Seed möglichst "Echt-Zufällig" zu wählen und verschlüsselt zu übertragen. Hier kommt die Asymmetrische Verschlüsselung ins Spiel. XOR ist eine Symmetrische Verschlüsslung da ein Wert zum ver- und entschlüsseln reicht. Das wichtige an asymmetrischen Verschlüsselungen ist nun, das man ein Wert hat mit dem man nur Verschlüsseln kann, den "Public Key" und einen mit dem man nur Entschlüsseln kann, den "Private Key". Damit kann man den Public Key ohne Probleme weiter geben. Dieser wird verwendet um das Seed für den Zufallsgenerator zu übertragen, mit dem alle weiteren Daten verschlüsselt werden.
Asymetrische Verschlüsselungen Basieren darauf was die Umkehrung einer mathematischen Operation schwerer sein kann als diese selbst. Als Beispiel die Multiplikation zweier Primzahlen. Die Zerlegung des Produkts dauert um ein vielfaches länger als die Multplikation. Wählt man sehr große Primzahlen wird es noch schwerer. Die Idee ist aus dem Produkt Wertepaare zu erzeugen, die sich gegenseitig so ergänzen, dass eine Mathematische Operation vom einen nur vom anderen umgekehrt werden kann. (Siehe dazu z.b das RSA Verfahren)

Das wären die Grundzüge einer verschlüsselten Kommunikation. Nun gibt es noch andere Angriffsmöglichkeiten als direkt auf die verschlüsselten Daten. z.B. ein "Man in the middle" Angriff. Dazu gibt sich ein System als Ziel einer Kommunikation aus und stellt sich für das eigentliche Ziel als Partner dar. Es baut auf beiden Seiten eine Verbindung auf und reicht die Daten durch. Auf dem System selber liegen die Daten somit Unverschlüsselt vor. Gegen so etwas kann man sich schützen. z.B indem man vorher über eine definitiv sichere Verbindung einen Öffentlichen Schlüssel überträgt (Eingabe per "Hand"). Oder beide Seiten bauen eine Verbindung zu einem Dritten auf der beide Seiten identifizieren kann.
SSH und SSL gehen solche Wege. Wenn man das Rad nicht neu erfinden will, sollte man darauf zurück greifen.


Ein Beispiel was schlechte Verschlüsselung ist:
Die Daten wurden von einem Nutzer A verschlüsselt und an einen Nutzer B gegeben der sie an einen Server weitergab welcher die Daten entschlüsselte und einen Teil davon für den Nutzer B anzeigte. Das ist soweit zwar nicht Ideal aber einfach zu implementieren. Nun kommt der Hammer. Zum verschlüsseln der Daten wurde das Zugangspasswort des Nutzers A und XOR verwendet. Wenn das Passwort zu kurz war wurde es so lange an sich selber angehängt bist es passte. Aus den für den Nutzer B angezeigten Daten konnte genügend des verschlüsselten Strings rekonstruiert werden, um daraus das Passwort des Nutzers A zu rekonstruieren, wenn es kürzer als 10 Zeichen war!