AESCrypt déchiffrement entre iOS et PHP

Je vais avoir un diable de temps à essayer de comprendre comment décrypter une chaîne cryptée avec la NSData+AESCrypt.m (Expliqué ici)

J'ai été à la recherche à une poignée de d'autres fils, mais j'ai seulement besoin de l'iDevice pour envoyer une chaîne de caractères dans un fichier PHP crypté, puis il est décrypté à l'intérieur de PHP (où il est stocké dans une base de données).

Ce code :

NSString *encryptedString = [@"Hello" AES256EncryptWithKey:@"a16byteslongkey!"];
NSLog(@"The strign encrypted : %@",encryptedString);

Renvoie la chaîne cryptée : 7opqbb7sEVNoXplyQv/X8g==

Et voici mon code PHP pour le décryptage:

function decrypt_data($data, $key) {
    return mcrypt_decrypt(MCRYPT_RIJNDAEL_256, $key,$data,MCRYPT_MODE_ECB);
}

function unpadPKCS7($data, $blockSize) {
    $length = strlen ( $data );
    if ($length > 0) {
        $first = substr ( $data, - 1 );

        if (ord ( $first ) <= $blockSize) {
            for($i = $length - 2; $i > 0; $i --)
                if (ord ( $data [$i] != $first ))
                    break;

            return substr ( $data, 0, $i );
        }
    }
    return $data;
}

function decrypt_string($string) {
    $string = unpadPKCS7($string,128);
    $string = decrypt_data($string,"a16byteslongkey!");
    return $string;
}
die('<br>Basic :'.decrypt_string('7opqbb7sEVNoXplyQv/X8g=='));

Mise à JOUR:

Fait quelques MD5 de déchiffrement et d'expérimenter beaucoup de choses, mais encore loin d'atteindre des résultats utilisables. C'est ce que j'ai obtenu jusqu'à présent:

Original string : Hello
AES256Encrypt result : 7opqbb7sEVNoXplyQv/X8
base64_decode Decrypted: îŠjm¾ìSh^™rBÿ×
mcrypt_rijndael_128 : Õ¯Öå«Ž(ás2’'u)
mcrypt_rijndael_128 & hex2bin : UÃ)ı+úy´e

Malheureusement, peu importe comment je flexion et torsion cela, je viens d'obtenir jibberish. N'importe qui peut voir ce que je fais mal?

Connexes: Comment faire AES256 décryptage en PHP?
J'ai été en regardant ça, et essayé avec une copie directe de son decrypt_data fonction, et à l'aide de 1234567890123456 que mon iv dans l'encodage de la fonction... mais toujours pas de cigare
Vous avez vu le pack() commentaire là? Non pas que je pense que c'est la solution, mais sans doute la peine d'être conscient de.
Oui vu.. ont été en cours d'exécution autour de pack () ing toutes les variables que j'ai pu trouver (car je ne peux pas voir où son censé être utilisé directement, le montant de la var ne figure pas dans le dialogue), mais sans succès... :je je vais continuer à expérimenter, souhaite juste que c'était plus propre
Notez que la BCE mode n'est pas sûr dans le sens où l'information peut encore être appris à partir de vos données chiffrées, voir secure.wikimedia.org/wikipedia/en/wiki/... pour un exemple. À l'aide de la SRC ou de la BFC est recommandé.

OriginalL'auteur Nils Munch | 2011-06-23

  1. 11

    Avertissement: j'ai zéro iPhone expérience de développement.

    Réponse courte - ce que tc. dit. Quelque chose est terriblement mal avec le AES256EncryptWithKey:

    Être AES256 vous vous attendez à ce qu'il exige de 32 octets de la clé, pas une clé 16 octets. Mais OK, disons qu'il coussinets plus courte touches avec des octets nuls à faire de 32 octets. Cela peut expliquer pourquoi votre clé 16 octets est rembourré avec 16 caractères null.

    Mais, quand il s'agit de la loi de chiffrement, c'est à l'aide d'AES 128, mais avec 32 octets de la clé. Dire wha?

    De conversion tc.'s, Python, PHP:

    $base64encoded_ciphertext = '7opqbb7sEVNoXplyQv/X8g==';
$key = 'a16byteslongkey!';

$padded_key = $key . str_repeat(chr(0x00), 16); //Argh!

$result = mcrypt_decrypt(MCRYPT_RIJNDAEL_128, $padded_key, base64_decode($base64encoded_ciphertext), 'ecb');

//Yetch - $result ends up being padded with 0x0b's (vertical tab).
var_dump(rtrim($result, chr(0x0b)));

    Résultat:

    string(5) "Bonjour"

    ~~

    Edit: Ce post de Henno a des détails pertinents.

    ~~

    Fait quelques recherches supplémentaires. Le nul de rembourrage sur votre clé est probablement parce que AES256 requiert l'un de 32 octets de la clé. Le 0x0B rembourrage sur le texte en clair est grâce à PKCS7. PKCS7 est un protocole de remplissage où l'octet utilisé pour le rembourrage est de valeur égale au nombre d'octets ajouté. Dans cet exemple, de 11 octets ont été ajoutés à la fin de "Bonjour" en tournant votre 5 octet d'entrée en 16 octets du bloc pour l'AES. 11 = 0x0B.

    Ainsi, le code ci-dessus ne fonctionnera pas lorsque le texte en clair n'est pas la longueur = 5. Essayer ce qui suit:

    $pad_char = ord(substr($result, -1));
$result_without_padding = substr($result, 0, strlen($result) - $pad_char);
    Oh mon nombreux dieux! Il fonctionne! Merci beaucoup, ce code sera mis en vigueur, et de câlins virtuels permettra d'atteindre à travers les interwebs dans votre direction ;]
    C'est bizarre; vous vous attendez MCRYPT_RIJNDAEL_128 à se plaindre quand pssed une clé de 256 bits. +1 pour s'en rendre compte le remplissage PKCS#7 qui me manquait entièrement!
    BCE mode ne doit pas être utilisé pour chiffrer des chaînes. L'utilisation de la CBC avec un prepadded aléatoire IV ou d'un ruisseau mode de chiffrement. Les mots de passe ne sont pas des touches, vous avez besoin d'une fonction telle que PBKDF2 pour créer une chaîne sécurisée. Zéro de remplissage peuvent travailler pour les cordes, mais pour des données binaires essayer de remplissage PKCS#7 à la place.
    Ce code ne fonctionne pas dans certains cas. Par exemple: "No" -> 2cSCpEVx1LB6lVxTwy901A== -> ok "Hello" -> 7opqbb7sEVNoXplyQv/X8g== -> ok "Error: 305" -> boaAGQwN1PdyNCywCRW2Nw== -> ok "OK" -> ZMedtnsamfYZ9oOnPRC8hw== -> ok "400: OK" -> Xc5Sn1tvDMCTNVqCxR9D6w== -> ok "500: OK" -> ZvEJ0+qvDHSFapRgJXCI3Q== -> PHP-code ne peut pas le déchiffrer
    Désolé. C'est parce chaîne codée avait "+" et a été traité à tort.

    OriginalL'auteur Tails

  2. 2

    La chaîne cryptée dirait qu'il a été encodé en base64. Essayez de décoder avant de le décrypter.

    Merci de ne pas demander de compteur de questions réponses. C'est ce que les commentaires sont pour.
    mettre un $string = base64_decode($string); avant le decrypt_data partie de la chaîne déchiffrée un peu plus court... mais toujours pas de cigare dans le long terme...
    Je pense que vous avez vu un combiné problème. Je vous laisse le base64_decode et essayer de résoudre le mcrypt problème.
    Im de le garder et va le jeter autour, avec quelques tentatives. J'ai des mises à jour de la msin thread avec mes résultats jusqu'à présent.

    OriginalL'auteur tangrs

  3. 1

    Tout d'abord, le code Objective-C que vous utilisez est assez terrible:

    • L'espace est très limité (sans doute octets UTF-8 terminée par un octet nul, étendu avec des octets nuls à 32 octets). La façon la plus simple de générer une clé aléatoire est de s'en tenir à l'ASCII, ce qui vous limite à environ 223.6 bits pour la valeur par défaut de la taille des clés de 256 bits.
    • De chiffrement se fait en mode ECB.
    • Des données semble être de manière irréversible rembourré avec 0x0B.

    L'éviter à tout prix. Il n'est pas sûr.

    Il peut être "décrypté" en Python, avec quelque chose comme ceci:

    >>> import Crypto.Cipher.AES
>>> import base64
>>> Crypto.Cipher.AES.new('a16byteslongkey!'+'
    >>> import Crypto.Cipher.AES
>>> import base64
>>> Crypto.Cipher.AES.new('a16byteslongkey!'+'\0'*16).decrypt(base64.b64decode('7opqbb7sEVNoXplyQv/X8g=='))
'Hello\x0b\x0b\x0b\x0b\x0b\x0b\x0b\x0b\x0b\x0b\x0b'
    '    *16).decrypt(base64.b64decode('7opqbb7sEVNoXplyQv/X8g=='))
'Hello\x0b\x0b\x0b\x0b\x0b\x0b\x0b\x0b\x0b\x0b\x0b'
    Normalement je me serais volontiers écouter et de suivre les avertissements et des conseils, mais c'est une contracté mission pour l'état local, et ils sont très tenaces dans l'exécution de ce spectacle... j'ai seulement été choisie pour rendre cette partie plus petite, et n'ont aucune influence sur le niveau supérieur de choses (malheureusement). J'ai transmis votre alerte et de vos déclarations, mais ma conjecture est qu'ils ne bougera pas d'un pouce 🙂
    Cela dit, il pourrait être intéressant de faire un test avec un plus clair de distinguer entre la BCE et certains IV-moins de CBC-même. Dans ce dernier cas, il n'est pas terrible à condition de faire précéder l'entrée avec 16 octets aléatoires (ce qui est un changement facile de faire).

    OriginalL'auteur tc.

  4. 0

    voir mon post ici: PHP iOS Cryptage AES

    Je viens de recevoir par le biais de ce même type de projet. J'ai utilisé la bibliothèque que vous l'avez mentionné dans "également considéré comme..."

    Voici un exemple de code pour décrypter avec php:

    $iv2 = '';
for($i=0;$i<16;$i++){
    $iv2 .= "
    $iv2 = '';
for($i=0;$i<16;$i++){
$iv2 .= "\0";   
}
$plain_text_CBC = mcrypt_decrypt(MCRYPT_RIJNDAEL_128, $key, $encrypted_text, MCRYPT_MODE_CBC, $iv2);
var_dump($plain_text_CBC);
    "    ;   
}
$plain_text_CBC = mcrypt_decrypt(MCRYPT_RIJNDAEL_128, $key, $encrypted_text, MCRYPT_MODE_CBC, $iv2);
var_dump($plain_text_CBC);

    Assurez-vous que vos clés sont à la fois de 256 bits (32 caractères, je n'ai pas encore rencontré de problèmes d'encodage, mais si vous le faites, n'oubliez pas que vous êtes le chiffrement octets, pas de caractères). Notez que 128 en MCRYPT_RIJNDAEL_128 est la taille de bloc et non pas la taille de la clé, tandis que dans la méthode AES256DecryptWithKey, 256 est une référence à la taille de la clé, alors que la taille de bloc est de 128. AES256DecryptWithKey s'exécute en mode CBC, mais a une valeur null vecteur d'initialisation (iv).

    SRC signifie que chaque bloc dépend du dernier bloc, et donc il utilise un pré-réglage, généralement aléatoire, de bloc "-1" appelé le IV

    BCE signifie que chaque bloc est chiffré de la même façon, d'où il révèle lorsque deux blocs dans le même message est le même. La bibliothèque mentionnés ne l'utilise pas, donc je l'ai mentionné juste pour le contraste.

    L'utilisation d'un zéro iv (0000000000000000 en octets) est considéré comme l'insécurité, mais il ne vous donner quelques de sécurité supplémentaires (mais on peut toujours être en mesure de dire si le poing de 16 caractères de votre texte brut étaient les mêmes à chaque fois). Pour y remédier, vous devez créer un NSData *iv variable pour le IV et de modifier le CCcrypt argument de NSData+AESCrypt.m pour ajouter [iv octets] pour le iv paramètre (je n'ai pas encore testé ce code), et vous auriez besoin de les stocker iv et la passer au php avec vous message. Mais d'abord, je voudrais tester et avoir tout ce travail avec un zéro iv.

    Un zéro IV peut avoir plus de conséquences que de simplement montrer si le premier bloc est identique à la précédente. Juste un exemple: si elle est identique, il pourrait également fuite d'informations sur le deuxième bloc et ainsi de suite.

    OriginalL'auteur user1122069