Incorrecte de la taille de la clé lors du portage de Crypto++ chiffrement AES PHP mcrypt

Question

Plus tôt, j'ai réussi à port en C++ CryptoPP Rijndael_128 SRC code de MCrypt PHP, mais maintenant je vais avoir des problèmes avec le mode CFB.Le C++ et PHP résultats ne correspondent pas (bien que le premier octet correspond mais ce pourrait être une coïncidence, tout le reste ne marche pas).Avec certains diagnostics, il ressemble PHP mcrypt est pas de réglage de la longueur de la clé correctement?

Voici le C++ (diagnostics et les menues dépenses supprimées pour des raisons de simplicité):

CFB_Mode<AES>::Encryption encryptor(g_encrypt_key, AES::DEFAULT_KEYLENGTH, g_encrypt_iv);

StringSource ss( sInput.c_str(), true, 
        new StreamTransformationFilter( encryptor, 
            new HexEncoder( new StringSink( sEncryptedOut ) )
        ));

Et voici le code PHP:

$cipher = mcrypt_module_open(MCRYPT_RIJNDAEL_128, '', MCRYPT_MODE_CFB, '')
mcrypt_generic_init($cipher, $g_encrypt_key, $g_encrypt_iv);

$sEncryptedOutput = mcrypt_generic( $cipher, $sInput);
mcrypt_generic_deinit($cipher);
mcrypt_module_close($cipher);

g_encrypt_key et g_encrypt_iv sont à la fois 16 octets de long, et les octets de match pour le C++ et les versions de PHP.Pour la version de PHP c'est une chaîne binaire construit à partir des octets (oui j'ai vérifié ces données sont identiques).

J'ai ajouté des appels à la version de PHP pour vérifier $cipher's la taille du bloc, la taille de la clé, etc.La taille de bloc et iv de la taille de deux à 16;pris en charge les tailles de clés sont l'objet de 16, 24 et 32 - tout comme prévu.

Là où je pense que le problème, c'est que la taille de la clé est d'être présentées comme des 32 octets.En regardant les mcrypt docs, le seul moyen de réglage de la taille de la clé est de fournir une clé de la taille requise.Mais je suis de passage une clé 16 octets!Alors pourquoi est-il signalé la présence de 32 octets de la clé?Si le mode CFB doit utiliser un 32 octets de la clé, alors pourquoi ne CryptoPP l'accepter comme bien?Quelle est la solution?Puis-je forcer PHP à utiliser les 16 octets de la clé qui a été prévu?Ou est-il un paramètre que je suis absent qui est défaillant à un autre réglage dans CryptoPP que dans MCrypt?

Je suis en utilisant le mode CFB parce que je veux minimiser la longueur des données chiffrées qui en résulte.Les quelques octets de padding introduire, faire question dans la présente demande.

J'ai besoin d'être en mesure de chiffrer/déchiffrer en C++, mais seulement chiffrer en PHP.AES est sans doute exagéré de ma demande - le minimum dont j'ai besoin est "une bonne brouillage des octets" de sorte que la fonction de chaque octet de données dans les données ne sont pas évidentes.

Answer 1

Il a été un certain temps, mais j'ai eu des problèmes similaires avec mcrypt et openSSL à l'aide de la BFC il y a quelques années.En fin de compte, j'ai découvert mcrypt différente de commentaires par défaut de la chaîne de la taille de openssl dans le mode CFB.C'est-à-dire, je crois que la openSSL AES128 dans la BFC utilisé une taille de bloc et de la rétroaction de la taille de 128 bits, alors que mcrypt utilisé une taille de bloc de 128bits et un retour de la taille de 8 bits.Je n'ai aucun moyen de le confirmer, c'était juste de la spéculation à la fois basée sur la lecture de certains anciens messages du forum.Indépendamment de la vérité de cette théorie, je n'était pas le seul ou le premier à avoir ce problème particulier.

La solution pour moi a été d'utiliser nOFB comme toi-même.Selon l' PHP mcrypt de référence de la bibliothèque MCRYPT_MODE_NOFB les forces de la rétroaction de la chaîne à l'égalité de l'algorithme est la taille du bloc, dans ce cas, un bloc de 128 bits/commentaires pour AES128 (Rijndael), ce qui correspond à ce que l' page de manuel pour mcrypt module unis au sujet de nOFB.C'est bon que ce que j'ai dit nOFB rétroaction est synchrone à la taille de bloc.Ainsi, les deux mcrypt et OpenSSL dans nOFB étaient désormais 128 bits/iv/bloc/commentaires tailles pour AES128 et tout a bien fonctionné.

Dans la mesure où PHP rapports 256bit keysizes (32 octets), la fonction qui retourne le courant de chiffrement algorithme de la taille de la clé renvoie en fait au maximum la taille de la clé, ce qui n'est pas clairement indiqué dans la documentation.Je le sais parce que mon peu de classe que j'utilise tout le temps maintenant pour divers projets fonctionne parfaitement bien avec openSSL et tous les autres AES dans les bibliothèques de la SRC ou de nOFB .Ce ne serait pas le cas si mcrypt était rembourrage mon 128 bits(16 char) clé avec un supplément de 128bits de chaîne nulle, ou que ce soit, et ne serait pas techniquement correcte, en tout cas.

Pas vraiment une bonne réponse, mais le meilleur, je me suis basé sur une très amateur incursion dans le monde de la cryptographie il y a plusieurs années.

Answer 2

Découvrez phpseclib:

http://phpseclib.sourceforge.net/

Vous pouvez définir la taille de la clé et de la taille du bloc tout ce que vous voulez.

par exemple.$aes->setKeyLength(128) $ou aes->setKeyLength(256);

Answer 3

J'ai eu ce problème d'un couple de points.Par défaut, le PHP Rijndael mode définit la boucle de rétroaction de 8bits - être AES doit être de la même longueur que le IV/Clé.

Vous pouvez le faire en utilisant le mode "ncfb" au lieu de " cfb " ou MCRYPT_MODE_CFB.

Tous les détails de l'écriture aes_cfb_128 compatible PHP sont à cette Sécurité Stackexchange question: aes bfc 128 décryptage /problème de chiffrement entre Erlang et PHP.La position courte (de Tom Poireau):

...pour les deux CFB et OFB (qui sont distinctes les unes des autres et ne peuvent pas être utilisés de façon interchangeable), vous avez à vous soucier de la "feedback longueur" qui n'est pas forcément documenté avec une grande précision dans les différentes bibliothèques de chiffrement.Le chiffrement et le déchiffrement doit utiliser la rétroaction même longueur d'interopérer.