Je suis implémentant pour iOS Code de décryptage pour un message originaire d'un serveur sur lequel je n'ai aucun contrôle. Une implémentation antérieure sur une autre plate-forme documente les exigences de déchiffrement AES256, spécifie la clé et le vecteur d'initialisation, et dit également: Les options de création d'un objet CCCRYPTOR comprennent uniquement KCCOPTIONPKCS7Padding et KCCOPTIONECBMODE, notant que CBC est la valeur par défaut. D'après ce que je comprends sur le rembourrage pour le cryptage, je ne comprends pas comment on pourrait utiliser les deux; Je pensais qu'ils étaient mutuellement exclusifs. Dans la création d'un CCCRYPTOR pour le déchiffrement, j'ai essayé d'utiliser à la fois un 0 pour options et kccoptionpkcs7padding, mais donnez-moi à la fois gibberish après décryptage. J'ai comparé la vidage de ce déchiffrement avec une vidage de l'octet décodé tampon sur l'autre plate-forme et confirmé qu'ils sont vraiment différents. Il y a donc quelque chose que je suis différent dans cette mise en œuvre qui est significativement différent, je ne sais tout simplement pas ce que ... et vous n'avez pas d'indice de savoir comment obtenir une poignée. Les plates-formes sont suffisamment différentes pour qu'il soit difficile de déduire une grande partie de la mise en œuvre précédente car elle est basée sur une plate-forme très différente. Et bien sûr, l'auteur de la mise en œuvre précédente a depuis quitté. Toute supposition de quoi d'autre pourrait être incompatible ou comment résoudre cette chose?
4 Réponses :
Tout d'abord, vous pouvez vous inquiéter du rembourrage plus tard. Fournir Pour déboguer cela, vous devez isoler votre système. Vous pouvez le faire en implémentant un test de bouclage dans lequel vous chiffrez, puis déchiffrez les données pour vous assurer de tout charger correctement. Mais cela peut être trompeur. Même si vous faites quelque chose de mal (par exemple, charger la clé à l'envers), vous pouvez toujours être capable de déchiffrer ce que vous avez crypté parce que vous le faites exactement la même mauvaise façon des deux côtés. P> Vous devez tester des tests de réponse connus code> (CODE> (KATS). Vous pouvez rechercher les kats officiels sur le AES Wikipedia Entry . Mais il se trouve que j'ai eu si j'ai posté une autre réponse ici sur afin que nous puissions utiliser. p> donné cette entrée: p> vérifie avec un programme tiers que vous pouvez déchiffrer le texte de chiffrement et obtenir le texte Texte simple. P> 0 code> Comme si vous avez effectué signifie AES CBC sans rembourrage, et avec cette configuration, vous devez voir votre message tout à fait. Albiet potentiellement avec quelques octets de rembourrage à la fin. De sorte que ça part:
$ openssl enc -in encrypted -out plain_text -d -aes-256-cbc \
-K 000102030405060708090a0b0c0d0e0f101112131415161718191a1b1c1d1e1f \
-iv 0000000000000000 -nopad
$ hexdump -C plain_text
00000000 65 6e 63 72 79 70 74 20 6d 65 06 06 06 06 06 06 |encrypt me......|
00000010
$
Il s'avère que l'explication de ce que je vivais était gênante simple: j'ai mal interprété quelque chose que j'ai lu dans la mise en œuvre précédente pour impliquer qu'il utilisait une clé de 256 bits, mais elle utilisait en fait un 128 bits clé. Faites ce changement et tout de suite ce qui était obscur devient clairtexte. : -)
0 pour l'argument des options, pour invoquer CBC, était en fait correct. Ce que la référence au rembourrage PKCS5 dans la mise en œuvre précédente est toujours mystérieuse, mais cela n'a pas d'importance car ce que j'ai maintenant fonctionné.
Merci pour le tir, Indiv.
PKCS # 5 Rembourrage et PKCS # 7 Le rembourrage est pratiquement le même (ajout d'octets 01, ou 0202, ou 0303 etc jusqu'à la longueur de la taille du bloc de l'algorithme, 16 octets dans ce cas). Officiellement PKCS # 5 Le rembourrage ne doit être utilisé que pour 8 blocs d'octets, mais dans de nombreux actes, les deux peuvent être interchangés sans problème. Le rembourrage survient toujours à la fin du CIPHERText, donc si vous obtenez juste Gibberish, ce n'est pas le rembourrage. La BCE est un mode de fonctionnement de bloc (qui ne doit pas être utilisé pour chiffrer des données pouvant être distingués de nombres aléatoires): il nécessiterait un remplissage, de sorte que les deux ne sont pas mutuellement exclusifs.
Enfin, si vous venez d'effectuer un déchiffrement (non Mac'ing ou d'autres formes de contrôle de l'intégrité), et que vous renvoyez le résultat du pidon du serveur (décryptage échoué), vos données de texte brut ne sont pas sûres à cause du rembourrage Oracle attaques.
PKCS # 5 Le rembourrage est pas la même chose que PKCS # 7 Rembourrage. Alors que les deux coussinets jusqu'à la longueur du bloc, le remplissage de PKCS n ° 5 n'est approprié que pour les algorithmes de chiffrement avec 8 blocs d'octets, PKCS n ° 7 étendit cela jusqu'à une longueur de bloc arbitraire. Ils peuvent se comporter de même où il y a moins de 8 octets de rembourrage requis et dans les bibliothèques Java PKCS, ils utilisent des pkcs # 7 Rembourrage et appelez IT PKCS # 5 mais ils sont différents
@DaveDeDurbin Oui, Je sais , mais en Java - qui utilise exactement "pkcs5padding" String donnée pour la configuration du serveur - il est en fait identique au rembourrage n ° 7 de PKCS. C'est le cas pour la plupart des applications qui permettent au remplissage de PKCS # 5 pour différents chiffres de blocs. Clarifié cela dans la réponse ...
Paul,
Le rembourrage du PKCS n ° 5 est nécessaire pour identifier le remplissage dans les données déchiffrées. Pour CBC, le tampon d'entrée doit être un multiple de la taille du bloc de chiffrement (16 pour AES). Pour cette raison, la mémoire tampon à crypter est étendue avec des octets supplémentaires. Notez qu'après cryptage, la taille d'origine des données est perdue. PKCS # 5 Le rembourrage permet de récupérer cette taille. Ceci est fait en remplissant le tampon de données étendu avec des octets répétés, avec une valeur égale à la taille du remplissage. E. g Si votre tampon ClearText était de 12 octets, pour le faire plusieurs de 16, vous devrez ajouter 4 octets plus. (Si les données étaient de 16 ans, vous allez ajouter 16 autres pour le faire 32). Ensuite, vous remplissez ces 4 octets avec '0x4' pour vous conformer au rembourrage PKCS # 5. Lorsque vous déchiffrez, recherchez simplement le dernier octet dans les données déchiffrées et soustrayez ce nombre de la longueur du tampon déchiffré.
Ce que vous faites est le rembourrage avec '0. Bien que vous semblez être heureux de voir les résultats, vous aurez une surprise lorsque vos données d'origine se termine dans l'un des autres '0's.