Clanintern Clanintern Clanintern

Forum

Öffentliche Foren
FORUM: Spiele & Computer THEMA: Verschlüsselung von Daten?
AUTOR BEITRAG
*al!ve* - Vorbereitung aufs Urlaubssemester

RANG Master of Clanintern

#1 - 09.04 16:04

Hoi.


Nachdem ich in meinem "Das Rad neu erfinden"-Thread nicht mehr posten kann und sich -- obwohl die Methode die selbe geblieben ist -- die Frage etwas geändert hat hier ein neuer Thread .

Die Frage ist, wie ich am sinnvollsten Daten mittels PHP verschlüsseln und wieder entschlüsseln kann. Evtl kann später die Sprache ein andere sein, ich kann mir auch vorstellen, später mal mit ASP, einer vorkompilierten Anwendung, einem Java-Applet oder einem JS im Browser zu arbeiten. Dass hier auf "Boardmittel" von PHP zurückgegriffen wird ist nicht zwingend notwendig, es sollte nur nicht all zu rechenlastig sein.


Mach ich gravierend was falsch, macht man das normalerweise anders, kann man irgend wo Performance rausholen oder lieg ich vielleicht sogar ganz daneben?


Die erste Idee, asymmetrisch zu arbeiten, hab ich aus Resourcengründen abgeblasen. Für eine Ver- oder Entschlüsslung von auch nur 20 Zeichen einige Minuten zu benötigen ist definitiv untragbar.

Die zweite Idee ist dann natürlich symmetrische Verschlüsselung. Etwas ausgearbeitet würde ich hier nicht zuletzt aus Resourcengründen zum Output-Feedback-Mode greifen.

Hierzu folgendes Vorgehen:

- Benutzer gibt Klartext und Passwort vor
- Script bläst das Passwort auf die Länge des Klartextes auf. Dies geschieht durch while(nochnichtlangenug) $passwort = md5($passwort).$passwort;.
- Geheimtext = Bitweises XOR von Klartext und Passwort

Die Entschlüsselung erfolgt analog.

Um Manipulationen zu erkennen, wird der MD5 des Klartextes mit übertragen und am Ende geprüft.

Um nicht immer das selbe Passwort und damit den selben Überdeckungsstring (der sich ja wie beschrieben unmittelbar aus dem Passwort errechnet) zu verwenden, sollte für jeden Verschlüsselungsauftrag eine zufällige Zeichenkette mit dem eigentlichen Passwort unkenntlich vereinigt werden und diese Zeichenkette im Klartext übertragen. Etwa $session_key = md5($user_pass.$session_rand); mit im klartext übertragenem $session_rand;.
Natürlich darf $session_rand nicht Session-einmalig sein und damit innerhalb einer Session trotzdem mehrfach verwendet werden sondern muss für jeden Verschlüsselungsauftrag extra gebildet werden.


Hier meine Beispielimplementierung:
http://alive.no-ip.com/sym_crypt/class.sym_crypt.phps
http://alive.no-ip.com/sym_crypt/index.phps
http://alive.no-ip.com/sym_crypt/index.php


Und jetzt schreibt fleißig. Wenn im ST-OT keine Antworten kommen dann kann ich das akzeptieren weil der Thread ja eigentlich nicht dafür gedacht ist. Wenn ich aber da schon vertrieben werde erwarte ich (wenigstens von den Vertreibern) Antworten in meinem eigenen Thread
horst

RANG Prophet of Clanintern

#2 - 09.04 16:24

Wofür brauchst du das nochmal gleich?
*al!ve* - Vorbereitung aufs Urlaubssemester

RANG Master of Clanintern

#3 - 09.04 16:47

Ich hab zwei PHP-Scripte die miteinander kommunizieren. Eines ruft das andere mittels fsockopen auf und schickt Daten im POST-Header rüber, das andere friemelt an den Daten rum und schickt sie im HTML-Body zurück. Nennen tu ich das vorerst "remote_transport". Denkbar wäre auch, dass Server und Client anstatt über HTTP hier über E-Mail arbeiten. Anfrage via SMTP senden, Antwort via POP empfangen. Dann halt so lange pollen, bis die Antwort da ist.

Darauf aufbauend ein RPC. Der Client packt Funktionsnamen und Aufrufparameter in ein remote_transport, schickt es zum Server, der führt den Funktionsnamen aus (die eigentliche Funktion muss natürlich auf dem Server hinterlegt sein und entsprechende Privilegien auf Benutzerebene gesetzt, damit nicht jeder alles ausführen kann) und schickt die Antwort zurück.

Das Ganze wird dann die Basis für ein paar Server-/Client-Apps.

Meine erste Anwendung dieser Art wird ein Kalender werden. Der Server stellt Funktionen wie "gib mir alle meine Termine zwischen ZeitA und ZeitB", "neuen Termin eintragen", "Termin ändern" oder sowas bereit.


Wenn ich ne normale Browseranwendung schreiben wollte, die der Benutzer direkt im Browser aufruft würd ich SSL zur Verschlüsselung nehmen, aber das kann ich bei bei fsockopen nur, wenn ich den zielhost mit ssl:// definiere und das SSL-Packet mitkompiliert hab. Da das aber nicht jeder Host hat und das auf meinem Entwicklungsserver auch nicht installiert ist, fällt SSL weg.

Zudem benutz ich die Eigenschaft, dass hoffentlich nur der richtige Benutzer in der Lage ist, ne Nachricht mit seinem Passwort zu verschlüssel als Authentifizierung.


Mehr darüber im nächsten Thread. Ich brauch allerdings noch ein bis zwei Tage bis zur Demonstration.
horst

RANG Prophet of Clanintern

#4 - 09.04 16:59

Okay. Und Web-Services mit XML Encryption XML Signature und oder SAML kommen vermutlich nicht in Frage?
*al!ve* - Vorbereitung aufs Urlaubssemester

RANG Master of Clanintern

#5 - 09.04 17:26

Wohl eher nicht.

Ob ich jetzt XML durch die Gegend schieße oder stattdessen ein PHP-Array serialisiert spielt ja vom Prinzip her keine Rolle, nur kann ich das serialisierte Array halt in nem Einzeiler erzeugen, die Inhalte des Arrays in n XML zu packen würde schon ein paar mehr Zeilen benötigen. Aber auch dann müsste ich (so wie s bei Webservices nun mal gemacht wird) die Anfrage im HTML Post-Header schicken und die Antwort im HTML-Body erwarten. Tu ich ja jetzt schon, nur eben nicht in XML-Struktur.

Keiner der in XML Encryption verwendeten Verschlüsselungsalgorithmen ist nativ in PHP integriert, und diese nachzuschreiben dürfte wohl mehrere Monate in Anspruch nehmen. Nen AES256 oder nen Tripledes in PHP wär natürlich das Optimum. Nur hab ich weder die Zeit noch die Gedult, das ganze S-Box-Gedingense und Zeilenumhergeschiebe in PHP nachzuschreiben. Hat zwar unter Umständen schon mal jemand gemacht und ich könnte mir irgend wo Code klauen, aber sowas hab ich eigentlich net vor. Das wird eh hauptsächlich eines von den Projekten, die wenn schon dann komplett selber geschrieben werden .
Dazu kommt, dass AES auch mehr Aufwand ist. Diese ganzen Operationen auf Bitebene in x Runden sind zwar für ne kombilierte Anwendung lächerlich aber für PHP doch ein recht enormer Aufwand. Es dauert schon das einfache XOR (wobei XOR was anderes macht als ^, für mich ist ^ die Operation, die ich unter XOR kenne) eine halbe Ewigkeit.
horst

RANG Prophet of Clanintern

#6 - 09.04 18:46

quote:
Dass hier auf "Boardmittel" von PHP zurückgegriffen wird ist nicht zwingend notwendig, es sollte nur nicht all zu rechenlastig sein.
Deswegen hatte ich nachgefragt, ob WS-Sec in Frage kommt

Nur aus Interesse: Was macht denn XOR und was verstehst du unter XOR?

ab | c
---------
00 | 0
01 | 1
10 | 1
11 | 0

Das verstehe ich unter XOR...
*al!ve* - Vorbereitung aufs Urlaubssemester

RANG Master of Clanintern

#7 - 09.04 19:26

Jo, so hatte ich xor erwartet. Ist ja vom Grundsatz her auch so. Ich hatte nur mit einem Bitweisen xor gerechnet, das PHP-xor dagegen scheint den ganzen String als einen boolschen Wert anzusehen. Die Rückgabe von xor ist dagegen nicht zwangsläufig ein boolscher Wert sondern der Wert, den der linke Parameter hatte. So kommt es zu der recht verwirrenden Konstellation, dass sich ein String erzeugen lässt, der eine Länge größer 0 besitzt aber trotzdem den boolschen Wert false hat.


PHP-code:
<?
if ($a false xor false)
  echo 
'a';
echo 
'-'.$a."<br>\r\n";

if (
$b false xor 'jklö')
  echo 
'b';
echo 
'-'.$b."<br>\r\n";

if (
$c 'asdf' xor false)
  echo 
'c';
echo 
'-'.$c."<br>\r\n";

if (
$d 'asdf' xor 'jklö')
  echo 
'd';
echo 
'-'.$d."<br>\r\n";
?>


Ausgabe:
code:
-<br>
b-<br>
c-asdf<br>
-asdf<br>


Dass false xor false eben false ist ist mir klar, die erste Rückgabezeile "-" ist also auch klar weil 'a' nicht ausgegeben wird und $a leer ist.

Dass false xor 'jklö' nicht false ist und folglich 'b' ausgegeben wird leuchtet noch ein. Ich hätte jetzt aber erwartet, dass $b den Wert 'jklö' hat. Hat es aber nicht, es scheint leer zu sein.

Die dritte Zeile ist wieder klar, c wird ausgegeben weil 'asdf' xor false nicht false ist, und dass $c jezt 'asdf' ist hätte ich so auch erwartet.

Die vierte Zeile ist die merkwürdigste. d darf nicht ausgegeben werden weil links und rechts des xor ein nicht-falscher Wert steht. Soweit noch richtig. Trotzdem hat $d hier einen Wert, und zwar denjenigen des linken Parameters von xor 'asdf'. true xor true ist selbst also false, hat allerdings den nicht-falschen Rückgabewert true. Ich bin *äußerst* verwirrt.


Ergo: Für andere Dinge als zu ermitteln, ob A und B unterschiedliche Wahrheitswerte haben taugt xor, für alles andere ist xor ungeeignet.


Wobei auch ^ nicht 100% den gewünschten Effekt liefert. Wenn ich zwei Strings mittels ^ miteinander kombiniere hat die Rückgabe nur so viele Stellen wie der kürzere der beiden Eingabestrings. Erwartet hätte ich, dass die Rückgabe so viele Stellen hat wie der längere von beiden Eingabestrings. Jedenfalls käme mir das deutlich gelegener, in meinem Fall muss ich nämlich per Hand zwei Passwörter auf die gleiche Länge bringen.