Ich suche eine Methode um Daten zwischen PHP und Delphi verschlüsselt auszutauschen.
Dabei ist besonders Geschwindigkeit/Rechenauslastung wichtig.

Über die php-funktionen mcrypt_xxx kann man gut verschlüsselung und mit den DCPs auch in delphi entschlüsseln
Aber eben nur symetrisch.
Ich brauche es aber asymetrisch. Egal wie stark (muss nicht das maximum sein, aber möglichst gut)
das einzige was ich gefunden habe ist: SSL (RSA)
aber da muss die erweiterung aktiviert sein (wäre noch möglich) und ich weiß nicht, wie ich das mit delphi ver-/entschlüssle.

weiß da jemand was?

Für allgemein RSA mit Delphi würde zum Bleistift das hier gehen: sourceforge.net/projects/tplockbox/
Ansonsten sollten für verschlüsselte Kommunikation die Indies was bieten.

wieso muss es asymmetrisch sein? Es gibt da z.B. auxh AES, was allerdings symmetrisch ist.....

muss asymetrisch sein, da es für meinen anwendungszweck das beste ist.
kann leider nicht mehr dazu sagen

ich will ein byte-array verschlüsseln, von daher klappt das mit den indies nicht. (zumindest nicht AFAIK)
und RSA ist ja gut, aber weiß ne ob das mit dem php-zeug übereinstimmt

Moin und im Forum!

delphiCoder123 hat folgendes geschrieben :

Egal wie stark (muss nicht das maximum sein, aber möglichst gut)

Hä? Muss nicht gut sein, aber gut?

delphiCoder123 hat folgendes geschrieben :

muss asymmetrisch sein, da es für meinen anwendungszweck das beste ist. kann leider nicht mehr dazu sagen

Ich tippe mal darauf, dass du dich von diversen Quellen im Netz hast "beraten" lassen und dabei raus kam: am sichersten ist "asymmetrische Verschlüsselung" - egal was das ist und warum bzw. unter welchen Voraussetzungen das gilt... oder?

delphiCoder123 hat folgendes geschrieben :

Dabei ist besonders Geschwindigkeit/Rechenauslastung wichtig.

Dann scheidet eine asymmetrische Verschlüsselung schonmal aus, die sind nämlich sehr langsam. Die schnellen Verfahren sind alle symmetrisch. Wogegen auch im Grunde nichts spricht, es kommt eben darauf an, den Schlüssel sicher zu übertragen. Bei https (SSL) ist das auch so, hier wird (im Wesentlichen) der Schlüssel asymmetrisch ausgehandelt (bzw. verifiziert) und dann symmetrisch verschlüsselt (RC4).

delphiCoder123 hat folgendes geschrieben :

ich will ein byte-array verschlüsseln, von daher klappt das mit den indies nicht. (zumindest nicht AFAIK)

der organist hat folgendes geschrieben :

wieso muss es asymmetrisch sein?

Hier kann ich mich nur anschließen und fragen: Wozu soll das gut sein?!

Falls du die Daten-Übertragung von einer Delphi-Anwendung zu einem PHP-Script "absichern" möchtest: das wird eh nix, egal welches Verfahren du anwendest. Das Grundproblem ist nämlich: sowohl Sender als auch Empfänger müssen vertrauenswürdig sein. Ist es einer der Beiden nicht, kannst du die Integrität der Daten schon nicht mehr sicherstellen. Wenn du also eine Delphi-Anwendung raus gibst und von dieser aus Daten an ein PHP-Script senden willst, dann ist die Vertrauensstellung schon nicht mehr sichergestellt. Mal ein Beispiel:
Du möchtest den in einem in Delphi geschriebenen Spiel erzielten Punktestand an ein PHP-Script übergeben, dass einen Online-Highscore führt. Diese Datenübertragung kannst du nicht (vollständig) absichern, da der Spieler grundsätzlich erstmal als nicht vertrauenswürdig eingestuft werden muss (schließlich soll ein Spieler ja nicht moglen können - will es aber -> nicht vertrauenswürdig). Irgendwie muss dein Delphi-Programm die zu übertragenden Daten aufbereiten, damit das PHP-Script diese wieder entschlüsseln kann. Also muss im Delphi-Programm der Schlüssel dazu enthalten sein (egal ob der symmetrische oder asymmetrische). Der Ansatzpunkt wird also deine Delphi-Anwendung sein, statt sich mit der Datenübertragung aufzuhalten... Hat der Angreifer den Schlüssel aus deinem Programm "rausgebaut", kann er beliebige Daten "korrekt" an dein PHP-Script senden, welches die Manipulation erstmal nicht bemerken wird.

Fazit: (100%ige) Sicherheit gibt es nur, wenn beide Endpunkte einer verschlüsselten Strecke "sicher" sind.

cu
Narses

Zitat:

Hä? Muss nicht gut sein, aber gut?

heißt einfach: wenn möglich lieber schneller als sicherer (also kein ewig langer schlüssel)

und nein ich hab mich nicht beraten lassen oder so, kommt später...ich weiß was was ist und kenn mich mit den verfahren sehr gut aus.

wegen geschwindigkeit: das bytearray hat eine länge von ~500Byte (variabel)
da sollte auch eine asymetrische das ergebnis noch "sofort" liefern können, der nicht?
ich will ja keine datei verschlüsseln.

wegen Sicherheit: Es gibt keine 100%ige sicherheit! Das weiß ich. Ich möchte in meinem Fall eine serveremulation verhindern.
Sprich: mein programm erhällt daten vom server nach erfolgtem login. diese daten ändern sich nur alle paar tage.wenn jemand die verschlüsselung kennt und den schlüssel ausliest, kann er den server emulieren.
bei einer asymetrischen, bekommt er nur den client-schlüssel aber nie den vom server-->er kann den server nicht emulieren.

das war mein gedankengang. ich könnte auch über schlüsselaustausch o.ä. gehn, aber ich möchte aus zeitgründen (user soll nicht warten) mit nur einer anfrage an ein php script auskommen.

wenn es eine andre möglichkeit gibt, dann gerne

Also zur Geschwindigkeit asymmetrischer Verfahren: Ich nutz RSA Public Key Authentification auf meinem Server. Bei einem 8192er RSA-Key musste ich das Login-Timeout auf 5 Minuten hochstellen, da ansonsten mein Client sich nicht schnell genug (60 Sekunden) authentifizieren konnte. Bei 4096 ist man aber auch schon bei 5-10 Sekunden für's Login (im Grunde genau ein Verschlüsslungsvorgang.

Und zu dem "Schnell, nicht sicher": Dann nimm nen NULL Chiffre, die sind extrem schnell

Anyone who is capable of being elected president should on no account be allowed to do the job.
Ich code EdgeMonkey - In dubio pro Setting.

verdammt...gibt es eine andere möglichkeit?

Wenn ich dein Post richtig verstanden habe, gibt es andere Möglichkeiten:

delphiCoder123 hat folgendes geschrieben :

Sprich: mein programm erhällt daten vom server nach erfolgtem login. diese daten ändern sich nur alle paar tage.wenn jemand die verschlüsselung kennt und den schlüssel ausliest, kann er den server emulieren.

Wenn ich das richtig verstanden habe erfolg zuvor eine Login!? Folglich muss dies durch eine Authentisierung erfolgen, was in der Digitalen Welt in der Regel durch ein beiden Seiten bekanntes Geheimnis geschieht. Da sich beide Parteien bereits ein Geheimnis teilen, ist es ein leichtes daraus symmetrische Schlüssel abzuleiten und eine symmetrische Verschlüsselung einzusetzen.

Gleichzeitig stellt sich mir jedoch die Frage, wie es möglich sein sollte mit asymmetrischer Kryptographie das beschriebene Problem zu beseitigen?

Sollte ich nicht direkt richtig liegen, wäre es zur Lösung deines Problems sinvoll dein Vorhaben etwas detaillierter zu beschreiben...

nein folgendes:
client setzt verschlüsselte anfrage an server mit zum teil statischem key und zufallsteil
der server antwortet genauso aber mit anderem grundkey, den der client natürlich schon hat

ich tausche also keine schlüssel aus sonder lediglich infos wie der schon vorhandene schlüssel zu verwenden ist

wenn jemand das weis, kann der einfach verschlüsseln und entschlüsseln wie er will
bei ner asymetrischen ist ein statischer key kein problem, da der angreifer nie an den key vom server kommt
und der vom client nützt ihm ja nix

ich will am ende verhindern, dass jemand gefakte pakete verschicken kann

Eigentlich solltest Du doch eher darauf gucken, dass du nicht versuchst, gefakte Pakete zu verhindern, sondern diese so gut es geht zu erkennen und auszufiltern. Sicherlich gehört es dazu, die Hürde für gefälschte Pakete so hoch wie möglich zu setzen. Es bringt Dir nichts, wenn man zwar praktisch keine Pakete fälschen kann, aber dein Programm bei einem Bitübertragungsfehler aus dem Tritt gerät.

Anyone who is capable of being elected president should on no account be allowed to do the job.
Ich code EdgeMonkey - In dubio pro Setting.

delphiCoder123 hat folgendes geschrieben :

bei ner asymetrischen ist ein statischer key kein problem, da der angreifer nie an den key vom server kommt und der vom client nützt ihm ja nix ich will am ende verhindern, dass jemand gefakte pakete verschicken kann

Dennoch kann ein Angreifer mit dem PubKey des Servers Daten an diesen senden. Gleichzeitig verwendest du einen konstanten PrivKey des Clients welchen man jeder Zeit aus mit geeignetem Aufwand dem Programm auslesen kann und somit in beide Richtungen den Datenverkehr verändern/mithören/stören kann!

Du koppelst zur Zeit die Sicherheit deines Systems an den Besitz des Programmes und einen vertrauenswürdigen Besitzer wenn ich das recht verstehe!

Beschreibe doch bitte nocheinmal etwas detaillierter, wo welches Sprache für was eingesetzt wird?! - also wie die Kommunikation genau statt findet: Verbindungsaufbau, Datenaustasuch, Verbindungsabbau.

Fälschungen kann man in erster Ebene durch vertrauenswürdige Benutzer erreichen, was wiederum durch gegenseitige Authentisierung (zum Teil) erreicht werden kann.

bei einer asymetrischen veschlüsselung, wäre nur ein key im client.
man kann also daten an den server senden. ok kein problem
aber man kann keine daten an den client senden
und das ist was ich will

was wo passiert:
client (delphi) sendet verschlüsselte logindaten (per IdHTTP)
server (php) sendet verschlüsselte programmparameter mit denen das programm dann funktioniert

in den paketen sind noch verschiedene Daten zur Erkennung gefakter Pakete enthalten

wenn die verschlüsselung jetzt aber zu lange dauern würde, bleibe ich bei meinem jetzigen system und vertraue auf die erkennnung gefakter pakete

delphiCoder123 hat folgendes geschrieben :

bei einer asymetrischen veschlüsselung, wäre nur ein key im client.

Jain, an sich sind für eine Kommunikation zwei Schlüssel vorhanden!

delphiCoder123 hat folgendes geschrieben :

man kann also daten an den server senden. ok kein problem aber man kann keine daten an den client senden und das ist was ich will

Diese Variante der Nutzung von Asymmetrischer Kryptographie habe ich bisher noch nicht kennen gelernt: Die Geheimhaltung des öffentlichen Schlüssels des Clients!

delphiCoder123 hat folgendes geschrieben :

was wo passiert: client (delphi) sendet verschlüsselte logindaten (per IdHTTP) server (php) sendet verschlüsselte programmparameter mit denen das programm dann funktioniert

Wenn ich das also richtig verstanden habe:
Client: HTTP-GET/POST-Request an Server mit Login-Daten
Server: Sofern Login-Daten korrekt: HTTP-Response mit wichtigen zu verschlüsselnden Daten!

Von daher wäre dieses System an sich für den Einsatz von symmetrischer Kryptographie geeignet, sofern es sich bei den Login-Daten um mindestens ein Geheimnis handelt! Dann wäre ein Login-Vorgang per Challenge & Response möglich und eine anschließende Schlüsselableitung mit Hilfe einer beiden Seiten bekannten Nonce möglich.

Das ganze würde dann wie folgt aussehen:
Client: Anfrage an Server nach Verbindungsaufbau!
Server: Antwort mit Challenge!
Client: Bilden der Response: Hash( Challenge | Passwort/o.ä. ) und senden an Server!
Server: Überprüfung der Response durch Serverseitiges bilden dieser. Schlüsselableitung von Passwort/o.ä. durch bilden von: K = Hash( Nonce | Passwort/o.ä. ). Senden von Nonce und mit K verschlüsselten Daten an Client!
Client: Bilden von K mit Hilfe der Nonce und entschlüsseln der Daten!
Dieses Konzept benötigt einige wichtige sicherheitsrelevante Bedingungen und Voraussetzungen, soll jedoch zur Veranschaulichung reichen!

delphiCoder123 hat folgendes geschrieben :

in den paketen sind noch verschiedene Daten zur Erkennung gefakter Pakete enthalten wenn die verschlüsselung jetzt aber zu lange dauern würde, bleibe ich bei meinem jetzigen system und vertraue auf die erkennnung gefakter pakete

Ein solches System zu Erkennen von Angriffen sollte immer vorhanden sein, unabhängig von Verschlüsselungen o.ä.! Von daher kannst du die meinen obigen Vorschlag ja mal durch den Kopf gehen lassen und diesen evtl. umsetzen, sofern er in des Konzept passen würde!

Sirke hat folgendes geschrieben :

Jain, an sich sind für eine Kommunikation zwei Schlüssel vorhanden! Diese Variante der Nutzung von Asymmetrischer Kryptographie habe ich bisher noch nicht kennen gelernt: Die Geheimhaltung des öffentlichen Schlüssels des Clients!

wie jetzt?
asymetrische verschlüsselung: ein key (privat) hat der client, einen der server(public) oder andersrum, ist ja egal
wenn ich jetzt auf dem server die daten verschlüssele kann der client die daten mit seinem schlüssel (der vom angreifer auch ausgelesen werden kann) entschlüsseln
der schlüssel des client bringt dem angreifer aber nix, da er den server key nicht kennt und somit keine daten verschlüsseln kann.
ist praktisch wie ne signatur. wenn man die entschlüsseln kann wars ne korrekte antwort
also musst du mich falsch verstanden haben.

und ja das mit der kommunikation hast du richtig verstanden.

und dein konzept klingt zwar gut, aber ich möchte mit einer anfrage auskommen, aus zeitgründen
außerdem hätte das konzept noch das problem: man kann es genauso emulieren, da alles neu berechnet wird.
also setzt der angreifer nen server auf, der genau diese berechnung macht.

Okay, ich hatte wohl das ganze System etwas missverstanden: Es geht dir also nicht darum die Daten die vom Server kommen geheim zu halten, sondern nur deren Echtheit zu bestätigen!?

Dies hätte jedoch zur Folge, dass man einen Server emulieren könnte (ohne Schlüssel), der mit gecrackten Clients arbeiten könnte (ohne Verifikation)?!

wenn der client gecrackt wird ist eh keine chance mehr...
aber man muss ebn
a) den client cracken
UND
b) den server emulieren

und das ist schon sehr schwer. mehr an sicherheit lohnt den aufwand nicht

OKAY, da wir nun von der selben Sache reden ...

... würde ich sagen, dass du wirklich ein Problem hast, wenn du in PHP ein asymmetrisches Kryptosystem impementieren möchtest. Es existieren Varianten des RSAs oder DSAs, welche meist jedoch meist Lizenzen benötigen, sodass eine Verwendung sehr riskant wäre, da nicht einmal sicher wäre, ob die beiden Programmeirsprachen die selben Ein- und Ausgabeformate haben.

Eine SSL/TLS Verbindung unter Verwendung von HTTPS - sofern mit Indy möglich - wäre eine Lösung, sofern dies auf dem Server umgesetzt werden kann!


Auch bei diesen beiden Varianten wäre ein gecrackter Client von Nöten! Gleichzeitig wüsste ich jedoch nicht, wie egal welcher Angriff ohne einen gecrackten Client möglich wäre ...
Von daher würde ich das ganze System einmal in Ruhe überdenken und analysieren (Was will ich schützen und verhinden bzw. Was wären die Interessen und Ziele eines Angreifers), da mir z.B. bereits mehrere Angriffe einfallen würden.