Verschlüsseln in PHP und entschlüsseln in Delphi?

[gpl]

Hallo an alle,

ich stehe aktuell vor dem Problem, dass ich mit Delphi und PHP Daten verschlüsselt austauschen möchte. Also primär vom Webserver zu Delphi und später eventuell auch umgekehrt.

Der Abruf selbst ist kein Problem, aber die Entschlüsselung.
Ich habe dazu so einiges hier im Forum und sonstwo im Netz gefunden und ausprobiert, aber eine wirklich funktionierende Lösung habe ich bisher nicht gefunden.

Eine einzige Lösung hat zwar soweit korrekt entschlüsselt, konnte aber nicht mit UTF-8 umgehen, was für meine geplante Anwendung aber notwendig ist.

Hat sich hier schon mal jemand mit einer solchen Lösung beschäftigt und kann mir einen Tipp geben, oder kennt jemand ein wirklich funktionierendes Beispiel?

Gruß Gerd

[Kas Ob.]

Zitat:

Zitat von gpl (Beitrag 1534244)

Hallo an alle,

ich stehe aktuell vor dem Problem, dass ich mit Delphi und PHP Daten verschlüsselt austauschen möchte. Also primär vom Webserver zu Delphi und später eventuell auch umgekehrt.

Der Abruf selbst ist kein Problem, aber die Entschlüsselung.
Ich habe dazu so einiges hier im Forum und sonstwo im Netz gefunden und ausprobiert, aber eine wirklich funktionierende Lösung habe ich bisher nicht gefunden.

Eine einzige Lösung hat zwar soweit korrekt entschlüsselt, konnte aber nicht mit UTF-8 umgehen, was für meine geplante Anwendung aber notwendig ist.

Hat sich hier schon mal jemand mit einer solchen Lösung beschäftigt und kann mir einen Tipp geben, oder kennt jemand ein wirklich funktionierendes Beispiel?

Gruß Gerd

Hi,

There can't be one solution to fix such problem, the problem is not with Delphi and not in PHP per se, but with the used libraries and their default in primarily PHP and then Delphi.

To help you solve this, which might be trivial, you need to share more details, like PHP library (with links), your working solution and sample(s) php encrypted data, with of course key (and/or if there is iv or all the parameters like if a password used instead of key), in other words more datils needed.

[Klaus01]

wie wird in php verschluesselt?
Wie funktioiert die einzige Loesung?

Das encoding sollte hier doch keine Rolle spielen, denn normalerweise wird auf Byte-Ebene verschluesselt.

Gruesse
Klaus

[Uwe Raabe]

Zitat:

Zitat von Klaus01 (Beitrag 1534246)

Das encoding sollte hier doch keine Rolle spielen, denn normalerweise wird auf Byte-Ebene verschluesselt.

Leider gibt es noch viel zu viele alte Lösungen, die auf PAnsiChar aufsetzen und von Encoding noch nichts gewusst haben.

[himitsu]

PHP wird heute oft als UTF-8 laufen. In Delphi sind Strings aber nun standardmäßig Unicode.

Wenn man also einen "String" ver-/entschlüsselt (z.B. ein Passwort), dann muß schon beachtet werden, welche Encoding auf jeder Seite benutzt wird.


Je, byte-weise wird meistens ver-/entschlüsselt,
aber wenn du jetzt UTF-8 vertschlüsslst, und das entschlüsselte als Unicode (2 Byte) betrachtest, dann sieht das Ergebnis ein bissl chinesisch aus.


Ansonsten braucht es natürlich auf beiden Seiten auch die gleichen Algorithmen und eventuell noch auf gleiche Settings achten.

[gpl]

Ich habe jetzt gefühlt 100 verschiedene Ansätze ausprobiert und viele davon waren schon älter und konnten wohl daher nicht mit UTF-8 umgehen.

Auf der PHP-Seite habe ich zum Testen ein kleines Script aus den gefundenen Ansätzen erstellt, dass einen Text verschlüsselt und sofort wieder entschlüsselt.
Wie man sieht, funktioniert das innerhalb PHP problemlos.

Code:

<?php

function MyEncrypt ($data, $key, $iv)
  {
    //Remove the base64 encoding from our key
    $encryption_key = $key;
    //Encrypt the data using AES 256 encryption in CBC mode using our encryption key and initialization vector.
    $encrypted = openssl_encrypt($data, 'AES-256-CBC', $encryption_key, 0, $iv);
    //The $iv is just as important as the key for decrypting, so save it with our encrypted data using a unique separator (::)
    return base64_encode($encrypted);
  }
  
function MyDecrypt ($data, $key, $iv)
  {
   $encryption_key = $key;
   $indata = base64_decode($data);  // Base64-Dekodieren
   $unencrypted = openssl_decrypt($indata, 'AES-256-CBC', $encryption_key, 0, $iv);
   return $unencrypted;
  }  

$key = "ABCDEFGHIJKLMNOPQRSTUVWXYZABCDEF"; 
$plaintext = 'zu verschlüsselnde Nachricht äöüÄÖÜß';
$iv = "1234567890123456";
echo 'Plaintext     : '.$plaintext.'<BR>';
echo 'Key           : '.$key.' ('.strlen($key).')<BR>';
echo 'IV            : '.$iv.' ('.strlen($iv).')<BR>';
$enc = MyEncrypt($plaintext, $key, $iv);
echo 'Verschlüsselt : '.$enc.'<BR>';
echo '<br>';
echo 'Entschlüsselt : '.MyDecrypt($enc, $key, $iv);
 
?>

Ergebnis:

Code:

Plaintext : zu verschlüsselnde Nachricht äöüÄÖÜß
Key : ABCDEFGHIJKLMNOPQRSTUVWXYZABCDEF (32)
IV : 1234567890123456 (16)
Verschlüsselt : akMrallnS09ZVmlvOER5Y2w3WCtsVDJ3UEpYbTY4Yy9QQWg2N0xjaFYrdHNpL29pUEdOVVdvUHZNT2ZiQVMwWQ==

Entschlüsselt : zu verschlüsselnde Nachricht äöüÄÖÜß

[himitsu]

für AES mit CBC
siehe GetIt:

LockBox
Delphi Encryption Compendium
usw.

oder im Indy sollte sich auch was für OpenSSL finden, wenn man dessen AES-Code nutzen mächte
sowie andere OpenSSL-Libs für Delphi

[Kas Ob.]

@gpl ,

Please look at the answer for this question on SO :
https://stackoverflow.com/questions/...ncrypt-decrypt

Then adjust the PHP code to something similar then after that we talk about Delphi, encrypting data and send it over the wire (Internet) should be authenticated, it looks like trivial and not needed but when things go south the damage will be huge.

By just encrypting some data with fixed IV (!) and send it to different machine with authentication (for verification of integrity of the data) is like loading a gun with live bullet and aim it at your feet and wait, then wait for someone cough loudly around you !

I saw a damage similar to this implementation, the server was using different (random) IV per encryption as it should, yet there wasn't any authentication, the thing is with AES or any other symmetric encryption is that it will produce data no matter for any key (and IV), and there is no way to know if it is corrupted or not, anyway the server was sending the data and in that software after an update they request extra fields for the address (extra phone number) and someone forgot few lines that handle the password(s) from internally debugging the development build, after putting that server online some clients updated by adding the fields not looking that the other fields is garbage (or mostly empty because it was structured as list of strings) then clicked apply, data sent to the server and saved now it is all the fields are lost except the last one, which also unreadable because the list (data structure) was violated too.

This could have been prevented by adding an authentication, hence the decryption with wrong key(IV or password ...) could either raise an exception or simply not get the corrupt data allowing overwriting and losing valuable information.

So and sorry for long writing, either take some advices from that SO question or search for better solution, change the PHP side after, only after that you will not need a lot to write the same with Delphi as long you are not using some PHP library with unknown default parameters.

Also my suggestion is something like this answer to be exact:
https://stackoverflow.com/questions/...72528#46872528
it does Encrypt-then-MAC, but if you are going to use fixed IV (highly not recommended and simply wrong) then you should switch to MAC-then-Encrypt by calculating the HMAC for "$plaintext . iv" instead of "$ciphertext . iv" then test for data integrity (unlike that example) after the decryption not before.

Also you didn't mention what is the encryption library in Delphi you will use or prefer to.

ps: as said above the problem is from string encoding.
ps2 : DON'T REUSE IV, IV should be unique for each encryption, also should be sent over with the encrypted data, reusing it will defeat the whole point of the encryption.

[TurboMagic]

Zitat:

Zitat von himitsu (Beitrag 1534249)

PHP wird heute oft als UTF-8 laufen. In Delphi sind Strings aber nun standardmäßig Unicode.

Vorsicht! Auch UTF8 ist Unicode! Nur eben anders codiert. ;-)
Aber das wusstest du ja bestimmt schon.

[TurboMagic]

Zitat:

Zitat von himitsu (Beitrag 1534251)

für AES mit CBC
siehe GetIt:

LockBox
Delphi Encryption Compendium
usw.

oder im Indy sollte sich auch was für OpenSSL finden, wenn man dessen AES-Code nutzen mächte
sowie andere OpenSSL-Libs für Delphi

Öhm, sorry wenn ich dich schon wieder korrigieren muss. Aber die Delphi Encryption Compendium Fassung
im GetIt ist dafür unbrauchbar, da diese keine Verschlüsselungen enthält. Du findest diese aber auf
GitHub:

https://github.com/MHumm/DelphiEncryptionCompendium

Grüße
TurboMagic

[himitsu]

Maaaaaa, dieses blöde AmiExportverbot vergessen,
aber zumindest das Produkt war schonmal richtig. :stupid:

Zitat:

unicode

OK, UTF-16 (früher UCS2).

[Frickler]

Zitat:

Zitat von TurboMagic (Beitrag 1534307)

Zitat:

Zitat von himitsu (Beitrag 1534249)

PHP wird heute oft als UTF-8 laufen. In Delphi sind Strings aber nun standardmäßig Unicode.

Vorsicht! Auch UTF8 ist Unicode! Nur eben anders codiert. ;-)
Aber das wusstest du ja bestimmt schon.

Genau. Ist es nicht sogar UTF-16?

[gubbe]

Warum sollte man bei einer direkten Verbindung zwischen Webserver und Delphi denn überhaupt selbst verschlüsseln und sich nicht auf die Transportverschlüsselung (https) verlassen?
Ich sehe wenig Sinn darin, hier etwas eigenes zu implementieren. Wie sieht denn die zugrundeliegende Anforderung aus?

[himitsu]

Jupp,

und dass UTF-16 auch nichts mit UTF-8 gemeinsam hat, außer einen Teil des Namens.

Prinzipiell ist UTF-8 "nur" eine ANSI-Codepage.

[TurboMagic]

Nee, UTF8 ist nicht eine ANSI Codepage.
Denn je nach Bitmuster können das 1-4 Byte oder so sein, damit auch alle asiatischen zeichen usw. dargestellt werden können.
Auf alle Fälle nicht als 8-Bit ANSI Codepage zu behandeln!

Grüße
TurboMagic

[himitsu]

Zitat:

Zitat von TurboMagic (Beitrag 1534326)

Nee, UTF8 ist nicht eine ANSI Codepage.

Für Windows schon, wobei sie sogar CodePages für Unicode (UTF-16 und UTF-16-LE) haben.

https://learn.microsoft.com/de-de/wi...hartomultibyte
CP_ACP = 0 : unser aktuelles ANSI
CP_OEMCP : DOS
CP_UTF8 :)
CP_UTF16 = 1200
CP_UTF16LE = 1201
$FFFF : ohne CodePage / ohne Konvertierung

Delphi-Quellcode:

type
  RawByteString = type AnsiString($ffff);
  UTF8String = type AnsiString(65001);  // AnsiString(CP_UTF8);

oder :lol:

Delphi-Quellcode:

   AnsiUnicodeString = type AnsiString(1200);  // CP_UTF16

[TuPas]

Warum nicht als passwortgeschütztes Zip?
Kann man in PHP packen und in Delphi entpacken.

[Sherlock]

Weil man es ann auch gleich bleiben lassen könnte. Die Frage ist welche Daten will man vor wem schützen. Dann kann man abschätzen welchen Aufwand man betreiben möchte oder muss.

[himitsu]

Also prinzipiell könnte man SSL somit auch als Verschlüsselung ansehn.

[Sherlock]

Natürlich. SSL ist ein Protokoll für Web-Browser und Server, das die Authentifizierung sowie die Verschlüsselung und Entschlüsselung von Daten beim Senden über ein Netz ermöglicht.