Lockbox 3: Daten verschlüsseln und in PHP entschlüsseln

[amigage]

Hallo,

ich hoffe hier benutzt jemand Lockbox 3 zur Datenverschlüsselung und kann mir bei meinem Problem weiterhelfen.
Ich möchte Daten in AES und CBC Mode verschlüsseln und dann mit der PHP Funktion mcrypt_cbc() wieder entschlüsseln.

Das ist die Lockbox Komponente:

Delphi-Quellcode:

object Codec1: TCodec
    AsymetricKeySizeInBits = 1024
    AdvancedOptions2 = []
    CryptoLibrary = CryptographicLibrary1
    Left = 496
    Top = 40
    StreamCipherId = 'native.StreamToBlock'
    BlockCipherId = 'native.AES-192'
    ChainId = 'native.CBC'
  end
  object CryptographicLibrary1: TCryptographicLibrary
    Left = 568
    Top = 40
  end

Beim Klick auf eine Schltfläche soll eine Zeichenkette mit einem Passwort verschlüsselt werden.

Delphi-Quellcode:

procedure TfrmMain.Button1Click(Sender: TObject);
var
  base64Ciphertext : AnsiString;
  plaintext: String;
begin
  plaintext := 'LockBox3Test';
  
  Codec1.Cipher := 'native.AES-128'

  Codec1.Password := 'MeinPasswort123';
  Codec1.EncryptString( plaintext, base64Ciphertext);
  boxCipherTextOut.Text := base64Ciphertext;

end;

Ich erhalte z.B. die Base64kodierte zeichenkette: yMvS0IobfNR179gFFvyOE5+/cvm1bo1q+JfZ9WnFRtA=
Diese soll in den ersten 8 Bytes (Zeichen) den Initialisierungsvektor IV beinhalten. In Lockbox wird dieser aus Sicherheitsgründen ja zufällig erzeugt.

Mein PHP Skript sieht jetzt folgendermaßen aus:

Delphi-Quellcode:

<?php
  $pwd = 'MeinPasswort123';
  $cipherText = 'yMvS0IobfNR179gFFvyOE5+/cvm1bo1q+JfZ9WnFRtA=';
  $iv = substr ( $cipherText, 0, 8 );
  
  $encryptedcbc = mcrypt_cbc(MCRYPT_RIJNDAEL_128, $pwd, $cipherText, MCRYPT_DECRYPT, $iv);
  echo 'CBC encrypted: '.base64_encode($encryptedcbc);
?>

Leider erhalte ich nicht die ursprüngliche Zeichenkette.
Was mache ich falsch? Habe ich beim Auslesen des IV einen Denkfehler?

Besten Dank für jede Unterstützung.

[gammatester]

Ohne auf die speziellen Implentationen einzugehen: In Deine Codebeispielen geistern zwei verschiedene Schlüssellängen herrum: 128 und 192 Bit. Versuch's mal überall mit derselben Länge.

[Sir Rufo]

Zitat:

Zitat von gammatester (Beitrag 1201476)

Ohne auf die speziellen Implentationen einzugehen: In Deine Codebeispielen geistern alle drei möglichen Schlüssellängen herrum: 128, 192 und 256 Bit. Versuch's mal überall mit derselben Länge.

Zusätzlich ist da aber auch noch was mit Little und Big Endian zu berücksichtigen

[Bernhard Geyer]

Und auch noch ob man mit 8-Bit Ansi oder 8-Bit UTF-8 oder 16-Bit UTF-16 Codierten strings arbeitet.
Bei XE2 ist ein Character = 2 Byte. Die Frage ist ob Lockbox 3 schon das berücksichtigt oder hier noch mist baut.
Und auch ob und wie PHP das erwartet.

[gammatester]

Zitat:

Zitat von Sir Rufo (Beitrag 1201477)

Zusätzlich ist da aber auch noch was mit Little und Big Endian zu berücksichtigen

Richtig, aber eine weitere (eher wahrscheinlichere) Inkompatibilität ist die auf beiden Seiten unterschiedliche Gewinnung des Schüssels aus dem Passwort.

Dazu kommen noch eventuell unterschiedliche Paddingversion bei CBC, wenn die Textlänge kein Vielfaches der Blocklänge ist.

Außerdem muß ein IV 16 Bytes lang sein, da ist mit 8 Zeichen des Base64-Strings nichts zu machen.

[amigage]

Besten Dank für Eure schnellen Meinungen.

Zitat:

In Deine Codebeispielen geistern zwei verschiedene Schlüssellängen herrum: 128 und 192 Bit.

Ich passe die zur Laufzeit an 128 Bit an, so dass bei Delphi und PHP mit AES 128 Bit gearbeitet wird.

Zitat:

aber eine weitere (eher wahrscheinlichere) Inkompatibilität ist die auf beiden Seiten unterschiedliche Gewinnung des Schüssels aus dem Passwort.

Naja, in dem codierten Base64 String sollen ja alle benötigten Informationen vorhanden sein.


Sean, der Enwtickler von Lockbox schrieb folgendes:

Zitat:

• If the plaintext message is zero length, then the ciphertext message is zero length.
• Otherwise if the plaintext message is a whole number of blocks, then there is no padding and no ciphertext stealing.
• Otherwise if the plaintext message is greater than one block, then there is no padding. Instead ciphertext stealing is used for message termination. Ciphertext stealing applies for all IV-using non-key-streaming modes, such as CBC.
• Otherwise CFB 8-bit is forced, which is a key-streaming mode. There is no padding for key-streaming modes.

Note also, that LB3 injects the low 8 bytes of the randomly generated IV, in the clear, prepended at the beginning of the ciphertext message. If decrypting in another language, you need to first extract the IV from the head of the ciphertext.

Vielleicht könnt ihr mir mit diesen Informationen weiterhelfen.

[gammatester]

Das mit dem IV ist Unsinn. Es gibt bei AES keine 8-Byte IVs! Irgendwo müssen noch 8 weitere Bytes herkommen: entweder 0, Sequenznummer oä.

Wenn ich Dich richtig verstehe, kannst Du auf PHP-Seite nichst ändern und willst die Delphi-Seite dazu bringen, kompatible Ciphertexte zu erstellen. Dazu ist es notwendig genau zu wissen, was die PHP-Seite macht. Abgesehen von Little/Big-Endian, Unicode etc hast Du schon auf Byteebene zu klären:

- Wie wird ein Passwort in einen 128 bzw 192 Bit-Schlüssel überführt? Hashfunktion (wenn ja welche?) oder KDF (welche?)

- Welches Padding wird werwendet wenn die Textlänge kein Vielfaches von 16 ist. Oder wird Ciphertext-Stealing verwendet? Das DEC-artige Umschalten auf CFB-8 scheint mir wieder selbstgestrickt und nicht-standard.

- In welcher Form wird der IV erwartet.

Erst wenn das alles geklärt ist, kannst Du auf Delphi-Seite anfangen. Notfalls halt IV, Padding und Schlüssel zu Fuß behandeln.

[amigage]

Zitat:

Wie wird ein Passwort in einen 128 bzw 192 Bit-Schlüssel überführt?

Meinst Du das?

Delphi-Quellcode:

  if Length(MeinPasswort) <= 16 then
    Codec1.BlockCipherId := 'native.AES-128'
  else if Length(MeinPasswort) <= 24 then
    Codec1.BlockCipherId := 'native.AES-192'
  else
    Codec1.BlockCipherId := 'native.AES-256';

Zitat:

Welches Padding wird werwendet wenn die Textlänge kein Vielfaches von 16 ist. Oder wird Ciphertext-Stealing verwendet?

Laut seiner LockBox Beschreibung "Ciphertext-Stealing".
In PHP sehe ich, dass ZeroPadding verwendet wird.

Zitat:

In welcher Form wird der IV erwartet

Als Zeichenkette. http://www.php.net/manual/de/functio...pt-decrypt.php

[gammatester]

Zitat:

Zitat von amigage (Beitrag 1201512)

Zitat:

Wie wird ein Passwort in einen 128 bzw 192 Bit-Schlüssel überführt?

Meinst Du das?

Delphi-Quellcode:

  if Length(MeinPasswort) <= 16 then
    Codec1.BlockCipherId := 'native.AES-128'
  else if Length(MeinPasswort) <= 24 then
    Codec1.BlockCipherId := 'native.AES-192'
  else
    Codec1.BlockCipherId := 'native.AES-256';

Nein, das wählt ja offensichtlich nur die Schüssellänge. Es gibt wohl (in LB3.0.2) einen wählbaren Hashalgorithmus. Ist aber auch eigentlich egal: wenn PHP einen direkten Schüssel erwartet, muß Du halt den verwenden (bzw. das gehashte Passwort).

Zitat:

Zitat von amigage (Beitrag 1201512)

Zitat:

Welches Padding wird werwendet wenn die Textlänge kein Vielfaches von 16 ist. Oder wird Ciphertext-Stealing verwendet?

Laut seiner LockBox Beschreibung "Ciphertext-Stealing".
In PHP sehe ich, dass ZeroPadding verwendet wird.

Dann mußt Du das entsprechend einstellen, bzw wenn das nicht geht Deine Text manuell mit #0-Bytes füllen (nicht das Zeichen '0'!) bis die Textlänge (in Bytes!) ein Vielfaches von 16 ist.

Zitat:

Zitat von amigage (Beitrag 1201512)

Zitat:

Zitat:

In welcher Form wird der IV erwartet

Als Zeichenkette. http://www.php.net/manual/de/functio...pt-decrypt.php

Wenn es wirklich stimmt, daß nur 8 Bytes des IV dem Ciphertext vorangestellt werden, hast Du schlechte Karten.

Also ist entweder LB grundsätzlich nicht für Deine Aufgabe geeignet (was ich mir aber nicht so richtig vorstellen kann), oder Du mußt Dich stark in das Produkt einarbeiten.:( Vielleicht sind ja einige Spezialisten dafür im Forum.

[amigage]

Danke für Deine Bemühung, mir zu helfen. Bitte, eines noch: folgendes habe ich noch bei StackOverflow gefunden:
http://stackoverflow.com/questions/1...ing-for-aes-25

Zitat:

The upshot is that you can use the TCodec component without writing single line of code to manage IV's, and you still get all the cryptographic benefits of salting (basically meaning unpredictable IV's). This is in contrast to DCPCrypt, where you either have zeroised IV's or you self-manage the IV's.

und zum Padding:

Zitat:

...
Other (such as CBC)

No padding. Termination is handled by ciphertext stealing, which is "too cool for school"! If the message is too short for ciphertext stealing (less than 2 blocks), then it automatically switches to CFB-8 bit and treat as key-streaming.

Womöglich liegt es an meinem zu kurzen Probetext?
Was ist "CFB-8 bit and treat as key-streaming"?

Besten Dank.

[gammatester]

Zur IV-Problematik: Offensichtlich soll ein Feature verkauft werden: "Wir machen das automatisch für Sie, darum müssen Sie sich nicht kümmern". Problem ist nur das verschiedene Implementationen unterschiedliche Vorstellungen von Arbeitserleichterungen haben und sich nicht um Standards sorgen. Entweder es gelingt Dir den verwendenen IV zu ermittelt/setzen oder Du kannst den CBC-Modus für Deine Zwecken nicht verwenden. Punkt.

Zum Padding: Der reine CBC-Modus kann nur verwendet werden, wenn die Textlänge gleich der Blocklänge ist (für AES sind das 16 Bytes). Wenn nicht muß aufgefüllt werden (padding) oder eine andere Methode verwenden werden. Das Ciphertext-Stealing (wird manchmal CBC-CTS genannt) geht aber nur wenn mindestest 2 volle Blöcke vorhanden sind . CFB-8 ist ein weiterer Modus (der auf Bytebasis arbeitet). Also werden insgesamt von LB drei Methoden verwendet und unter CBC subsummiert.

Am einfachsten scheint mir, wenn Du einen Text 'manuell' mit #0-Bytes füllst auf ein Vielfaches von 16 (und mindestens 32 Bytes), also Textlängen von 32, 48, 64, ... verwendest.