Décryptage AES: javax.crypto.BadPaddingException: tampon de bloc corrompu dans Android

Je suis coincé avec un problème avec AES Décryptage dans mon Application android. J'ai beaucoup cherché, mais impossible d'obtenir la solution.

Voici les étapes, ce que je fais.

  • De crypter le numéro de carte de crédit avec ma clé envoyer vers le serveur Web.
  • Serveur Web de Déchiffrer le numéro de carte de crédit et de l'enregistrer.
  • Quand on va chercher le numéro de carte de crédit à partir du service Web.
  • Puis serveur web de crypter le numéro de carte de crédit avec la même clé et Nous l'envoyer.
  • Maintenant, Quand nous déchiffrer ce nombre, il jette le mauvais remplissage exception pour certains, numéro de carte de crédit de l'information.

Également des informations chiffrées n'est pas la même provenance du serveur, ce que nous avons envoyer dans un format crypté.
Alors que la même chose est faite en application iPhone, et iPhone est en mesure de déchiffrer les données avec succès.

J'utilise le code suivant pour le chiffrement et le déchiffrement.

public class AES256Cipher {
public static byte[] ivBytes = { 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00 };
public static String AES_Encode(String str, String key) throws java.io.UnsupportedEncodingException, NoSuchAlgorithmException, NoSuchPaddingException, InvalidKeyException, InvalidAlgorithmParameterException, IllegalBlockSizeException, BadPaddingException {
byte[] textBytes = str.getBytes("UTF-8");
AlgorithmParameterSpec ivSpec = new IvParameterSpec(ivBytes);
SecretKeySpec newKey = new SecretKeySpec(key.getBytes("UTF-8"), "AES");
Cipher cipher = null;
cipher = Cipher.getInstance("AES/CBC/PKCS5Padding");
cipher.init(Cipher.ENCRYPT_MODE, newKey, ivSpec);
return Base64.encodeToString(cipher.doFinal(textBytes), 0);
}
public static String AES_Decode(String str, String key) throws java.io.UnsupportedEncodingException, NoSuchAlgorithmException, NoSuchPaddingException, InvalidKeyException, InvalidAlgorithmParameterException, IllegalBlockSizeException, BadPaddingException {
byte[] textBytes =Base64.decode(str,0);
//byte[] textBytes = str.getBytes("UTF-8");
AlgorithmParameterSpec ivSpec = new IvParameterSpec(ivBytes);
SecretKeySpec newKey = new SecretKeySpec(key.getBytes("UTF-8"), "AES");
Cipher cipher = Cipher.getInstance("AES/CBC/PKCS5Padding");
cipher.init(Cipher.DECRYPT_MODE, newKey, ivSpec);
return new String(cipher.doFinal(textBytes), "UTF-8");
}

S'il vous plaît suggérer.

EDIT:
J'ai plus qu'une chose, c'est de travailler pour les < 16 chiffres de l'information. Lorsque nous avons mis les 16 chiffres de l'information, alors qu'il est en train de lancer une Exception dans le déchiffrement.

  • S'il vous plaît montrer le code côté serveur en tant que bien.
  • Je ne sais pas pourquoi le message d'erreur se produit, mais ton code est mauvais à partir d'un crypto point de vue. 1) IV 2) Pas de MAC 3) Utilise le texte comme clé directement 4) Ce code ne traite pas de la gestion des clés à tous, qui est le véritable problème difficile. | Avez-vous tout simplement à l'aide de TLS au lieu de la construction de la crypto protocole vous-même? | Depuis que vous avez à traiter avec des cartes de crédit, vous devez regarder dans la conformité PCI.
  • Quelle est la durée de votre clé (en octets)? Et où est le vecteur d'initialisation en venir? Comment est-il partagé avec le serveur?
  • Merci pour vos réponses rapides, Ma longueur de clé est de 256 octets, Et il est partagé en JSON demande au serveur web.
  • J'ai utiliser IV octets comme mentionné ci-dessus IVBytes. J'ai également essayé avec le nouveau IvParameterSpec(new byte[en chiffre.getBlockSize()]);
  • Votre code montre une constante que vous appelez IV. Mais depuis l'an IV doit être différent pour chaque chiffrement, ce n'est pas vrai IV. | "Mon longueur de clé est de 256 octets" AES ne prend pas en charge 256 octets clés. | "il est partagé en JSON demande au serveur" qu'un attaquant d'intercepter que JSON demande? Il va obtenir la clé, et puis il va déchiffrer le numéro de carte de crédit.
  • Il est très peu probable que la clé est de 256 octets de long si vous getBytes("UTF-8") pour générer le tableau d'octets. Sauf si vous êtes en utilisant tous les caractères ASCII, la longueur finale est difficile à prévoir.
  • roolkgnv;lvmfjdi0\p

InformationsquelleAutor Himanshu | 2012-12-27