2017-02-09 1 views
0

J'essaye de passer de l'utilisation de la bibliothèque de déchiffrement propriétaire de Chilkat à la crypto commune d'Apache. J'ai 2 exemples d'entrées cryptées avec lesquelles je travaille. Le premier est de 16 octets et le second de 96 octets. Le premier fonctionne très bien, mais sur le second, CryptoCipher ne semble pas consommer les 16 derniers octets.Java CryptoCipher Ne consomme pas tous les octets d'entrée

Voici quelques exemples de code de la configuration et le décryptage et la sortie:

Properties properties = new Properties(); 
    CryptoCipher crypt = CryptoCipherFactory.getCryptoCipher("AES/CBC/PKCS5Padding", properties); 
    MessageDigest digest = MessageDigest.getInstance("SHA-256"); 

    byte[] hashedKeyBytes = digest.digest("SHARED_SECRET".getBytes(
      StandardCharsets.UTF_8)); 
    MessageDigest ivDigest = MessageDigest.getInstance("MD5"); 

    byte[] ivBytes = ivDigest.digest("SHARED_SECRET".getBytes(StandardCharsets.UTF_8)); 
    final SecretKeySpec key = new SecretKeySpec(hashedKeyBytes, "AES"); 
    IvParameterSpec iv = new IvParameterSpec(ivBytes); 

    crypt.init(Cipher.DECRYPT_MODE, key, iv); 

    ByteBuffer encBuffer = ByteBuffer.allocateDirect(enc.length); 
    System.out.println("--" + enc.length); 
    encBuffer.put(enc); 
    encBuffer.flip(); 
    System.out.println("encln " + encBuffer.limit()); 

    ByteBuffer decoded = ByteBuffer.allocateDirect(bufferSize); 
    CryptoCipher crypt = init(); 

    System.out.println("consume " + crypt.update(encBuffer, decoded)); 
    System.out.println("finish " + crypt.doFinal(encBuffer, decoded)); 
    decoded.flip(); 
    return asString(decoded); 

Ce produit ces 2 sorties pour les 2 entrées:

entrée courte:

--16 
encln 16 
consume 0 
finish 13 

entrée longue :

--96 
encln 96 
consume 80 
finish 3 

Comme vous pouvez le voir, il ne consomme que 80 octets en entrée ... Étant donné que l'entrée la plus courte produit la sortie correcte par rapport à ce que Chilkat a produit, je ne sais pas trop comment l'utiliser .

Répondre

4

Le nombre renvoyé par crypt.update() et crypt.doFinal(..) est le nombre d'octets déchiffrés, pas le nombre d'octets consommés par l'opération. Comme vos données sont complétées (ou au moins vous l'indiquez comme PKCS5Padded), vos données cryptées seront toujours un peu plus grandes que la version déchiffrée. Avec PSCS5 et AES le remplissage ajoutera 1 à 16 octets de remplissage au multiplix le plus proche de 16 octets qui est la taille de bloc de AES.

Dans le premier exemple, vos 13 octets de données claires ont 3 octets de remplissage donnant 16 octets de données cryptées (ou un bloc AES complet). Dans le deuxième exemple, vous avez 83 octets de données claires et 13 octets de remplissage (donnant 6 blocs AES de 16 octets).

+0

Hmmm ... Je me demande pourquoi les derniers caractères sont supprimés de la fin ... Je vais passer un peu de temps à confirmer que le tableau des octets entrants est correct. Peut-être que c'est en quelque sorte se couper lors de la conversion d'une chaîne en un octet [] ... – user2963069

+0

Le remplissage est ajouté automatiquement lorsque vous cryptez, et supprimé automatiquement lorsque vous décryptez. Si vous déchiffrez un message de 16 octets avec 3 octets de remplissage, vous obtiendrez seulement 13 octets de données décryptées. –