Verschlüsselung/Entschlüsselung mit Delph i und PHP
André Neumann
Hallo zusammen,
ich programmiere ein Delphi-Programm welches vertrauliche
Daten von einem Webserver via HTTP abholt. Dies funktioniert
bereits recht gut; ich stelle Daten mit einem PHP-Script
zur Verfügung.
Nun sollen die Daten wegen Ihrer Vertraulichkeit verschlüsselt
übertragen werden.
Ich habe bereits gegoogelt und ausprobiert was das Zeug hält,
komme aber zu keinem vernünftigen Ergebnis, denn eine Trivial-
Verschlüsselung wie die Caesar-Methode ist nun wirklich nicht
zufriedenstellend.
Meine Frage: Welchen Ver-/Entschlüsselungsalgorithmus kann
ich in Delphi und auch PHP verwenden. Falls jemand einen kennt:
Gibt es dazu bereits Quellcodes für Delphi und PHP?
Ich bedanke mich im Voraus und verbleibe mit freundlichen
Grüßen.
André Neumann
Benjamin Billian
> ich programmiere ein Delphi-Programm welches vertrauliche
> Daten von einem Webserver via HTTP abholt. Dies funktioniert
> bereits recht gut; ich stelle Daten mit einem PHP-Script
> zur Verfügung.
>
> Nun sollen die Daten wegen Ihrer Vertraulichkeit verschlüsselt
> übertragen werden.
dann lass das ganze doch einfach über eine ssl verschlüsselung laufen
(https)
benjamin
Frank Schenk
>
>
> Hallo zusammen,
>
> ich programmiere ein Delphi-Programm welches vertrauliche
> Daten von einem Webserver via HTTP abholt. Dies funktioniert
> bereits recht gut; ich stelle Daten mit einem PHP-Script
> zur Verfügung.
>
> Nun sollen die Daten wegen Ihrer Vertraulichkeit verschlüsselt
> übertragen werden.
VPN oder SSL würde sich da anbieten, google mal nach "Delphi TCP SSL"
oder "Delphi VPN" o.ä..
Konkrete Beispiele kann ich dir hierzu nicht anbieten (und will ich auch
garnicht), nur einen Denkanstoss ;)
lg, Frank
André Neumann
Hallo,
leider ist HTTPS bzw. SSL serverseitig nicht möglich.
Ich suche auch viel mehr folgendes: Ein Ver-/Entschlüsselungs-
verfahren, welches ich in Delphi und PHP gleichermaßen
einsetzen kann, um simple Strings zu ver- bzw. entschlüsseln.
Trotzdem schon einmal vielen Dank!
Marian Aldenhövel
> ich programmiere ein Delphi-Programm welches vertrauliche
> Daten von einem Webserver via HTTP abholt.
Muss es http sein? https wäre das Protokoll der Wahl.
> Nun sollen die Daten wegen Ihrer Vertraulichkeit verschlüsselt
> übertragen werden.
Sie sollen nur gegen Abhören auf der Leitung geschützt werden?
Du vertraust aber Deinem Client und dessen Benutzern? Und Du
brauchst keine über die Mittel von http hinausgehenden
Zusicherungen über die Identität von Server und Client?
In dem Fall könntest Du die Daten natürlich vor der Übertragung
verschlüsseln. Dazu könntest Du die mcrypt-Extension verwenden,
falls Deine PHP-Installation sie unterstützt. Auf der Delphi-Seite
würdest Du eine Delphi-Implementation des gewählten Algorithmus
verwenden. Wählst Du einen assymetrischen so kannst Du "nebenbei"
die Authentizität des Servers prüfen, denn nur er wird dann das
jeweils andere Teil des Schlüssels besitzen.
Kannst Du kein mcrypt verwenden, so verwendest Du GnuPG und
rufst es aus Deinem PHP-Skript mit passenden Parametern auf.
Dann würde ich auf der Delphi-Seite schlicht dasselbe tun um
Kompatibilität sicherzustellen. Wenn nicht GnuPG, so verwendest
Du OpenSSL, das hat ebenfalls Kommandozeilenprogramme.
Https wäre aber vernünftiger.
Ciao, MM
--
Marian Aldenhövel, Rosenhain 23, 53123 Bonn.
Fon +49 228 624013, Fax +49 228 624031.
http://www.marian-aldenhoevel.de
"specialization is for insects" Lazarus Long
Benjamin Billian
> leider ist HTTPS bzw. SSL serverseitig nicht möglich.
> Ich suche auch viel mehr folgendes: Ein Ver-/Entschlüsselungs-
> verfahren, welches ich in Delphi und PHP gleichermaßen
> einsetzen kann, um simple Strings zu ver- bzw. entschlüsseln.
dann würd ich eine public-key rsa verschlüsselung verwenden.
entweder selber coden, oder noch besser auf beiden rechnern gpg
installieren und zum ver/entschlüsseln aufrufen.
benjamin
Michael Mazanek
könntest auch sehr simpel den buffer vorm senden mit einem key XORn.
dann is er verschlüsselt. problem is nur die schlüsselübermittlung, wäre
aber eine einfache methode wenn es ok is, das der schlüssel lange fix is.
Marian Aldenhövel
> könntest auch sehr simpel den buffer vorm senden mit einem key XORn.
> dann is er verschlüsselt.
Eve, die mit libpcap an einem beliebigen Rechner unterwegs oder im
LAN des Clients sitzt, lauscht zwei verschlüsselte Übertragungen
ab, XORt diese zusammen und ist damit im Besitz des Schlüssels.
Mit diesem Schlüssel entschlüsselt sie die beiden abgehörten so
wie alle vergangenen und zukünftigen Nachrichten.
Du schreibst bitte 100mal: XOR ist sicher, so lange man jedes
Schlüsselbit nur ein einziges mal verwendet.
Joachim Duerr
<c6o8li$ebe5v$1...@ID-25169.news.uni-berlin.de>:
> Du schreibst bitte 100mal: XOR ist sicher, so lange man jedes
> Schlüsselbit nur ein einziges mal verwendet.
..aber gefälligst nur in Schönschrift tippen!
--
Joachim Duerr
EMEA Lead ADS Support, Extended Systems GmbH, Germany
advantage[AT]extendsys.de
European Advantage Conference 2004:
http://www.extendsys.de/go/eac2004
Michael Mazanek
> Hi,
>> könntest auch sehr simpel den buffer vorm senden mit einem key XORn.
>> dann is er verschlüsselt.
> Eve, die mit libpcap an einem beliebigen Rechner unterwegs oder im
> LAN des Clients sitzt, lauscht zwei verschlüsselte Übertragungen
> ab, XORt diese zusammen und ist damit im Besitz des Schlüssels.
> Mit diesem Schlüssel entschlüsselt sie die beiden abgehörten so
> wie alle vergangenen und zukünftigen Nachrichten.
> Du schreibst bitte 100mal: XOR ist sicher, so lange man jedes
> Schlüsselbit nur ein einziges mal verwendet.
ok ok....hast ja recht. wenn die "vertraulichen" daten aber nicht gerade
pins und tans sind, sondern die telefonnummern seiner freunde, dann
reicht diese security-by-obscurity verschlüsselung schon.
Man muss sich halt immer die frage stellen wie weit der aufwand der
notwendigkeit gerecht wird. stimmt hier die proportion nicht, hat man
was falsch gemacht.
ps:
;)
Wolfgang Bachner
Michael Mazanek wrote:
>
> Marian Aldenhövel wrote:
> > Du schreibst bitte 100mal: XOR ist sicher, so lange man jedes
> > Schlüsselbit nur ein einziges mal verwendet.
>
> XOR ist sicher, so lange man jedes Schlüsselbit nur ein einziges mal
Brav! Und jetzt lernen wir noch das Zählen bis 100 ;-)
Wolfgang
Marcel Hellkamp
> Hi,
>
>> könntest auch sehr simpel den buffer vorm senden mit einem key XORn.
>> dann is er verschlüsselt.
>
> Eve, die mit libpcap an einem beliebigen Rechner unterwegs oder im
> LAN des Clients sitzt, lauscht zwei verschlüsselte Übertragungen
> ab, XORt diese zusammen und ist damit im Besitz des Schlüssels.
> Mit diesem Schlüssel entschlüsselt sie die beiden abgehörten so
> wie alle vergangenen und zukünftigen Nachrichten.
Das musst du mir mal genauer erklähren.
Folgendes Beispiel:
A: 101
B: 110
key: 010
A* = A XOR key = 101 XOR 010 = 111
B* = B XOR key = 110 XOR 010 = 100
key = A* XOR B* ??
key = 111 XOR 100 = 011 --> falsch
mfg
Marcel
Marian Aldenhövel
> Das musst du mir mal genauer erklähren.
Das kann ich nicht, weil es tatsächlich Quatsch ist. Ich hatte
das mit einer Known-Plaintext-Attacke verwechselt, und dort ist
das natürlich wirklich so primitiv.
Der Einwand bleibt aber trotzdem vollkommen gültig. Sobald ein Teil
des Schlüsselstroms wiederverwendet wird, ist das im Ergebnis sichtbar
und trivial knackbar. So trivial, daß es fertige Programme dafür gibt,
die innerhalb von Sekunden das Ergebnis ausspucken.
Längere Schlüssel verlängern die Suche in diesem Fall nur linear und
nicht exponential weil der Angriff im Kern darin besteht die
"Monsternachricht" mit einer verschobenen Kopie von sich selbst
zu verknüpfen.
Alle Stromchiffren, und nicht nur das One-Time-Pad als Spezialfall,
brechen sofort zusammen sobald der Schlüsselstrom wiederverwendet
wird.
Ich habe meinen Schneier gerade verliehen und solche Dinge fallen bei
mir hinten runter weil ich weiß wo sie stehen :-). Ich kann also den
genauen Algorithmus nicht angeben. Vielleicht glaubst Du mir aber
auch so.