Le bloc final n'est pas correctement rembourré

J'essaie d'implémenter un algorithme de cryptage basé sur un mot de passe, mais j'obtiens cette exception:

javax.crypto.BadPaddingException: le bloc final donné n'est pas correctement rempli

Quel pourrait être le problème?

Voici mon code:

public class PasswordCrypter {

    private Key key;

    public PasswordCrypter(String password)  {
        try{
            KeyGenerator generator;
            generator = KeyGenerator.getInstance("DES");
            SecureRandom sec = new SecureRandom(password.getBytes());
            generator.init(sec);
            key = generator.generateKey();
        } catch (Exception e) {
            e.printStackTrace();
        }
    }


    public byte[] encrypt(byte[] array) throws CrypterException {
        try{
            Cipher cipher = Cipher.getInstance("DES/ECB/PKCS5Padding");
            cipher.init(Cipher.ENCRYPT_MODE, key);

            return cipher.doFinal(array);
        } catch (Exception e) { 
            e.printStackTrace();
        }
        return null;
    }

    public byte[] decrypt(byte[] array) throws CrypterException{
        try{
            Cipher cipher = Cipher.getInstance("DES/ECB/PKCS5Padding");
            cipher.init(Cipher.DECRYPT_MODE, key);

            return cipher.doFinal(array);
        } catch(Exception e ){
            e.printStackTrace();
        }
        return null;
    }
}

(Le test JUnit)

public class PasswordCrypterTest {

    private static final byte[] MESSAGE = "Alpacas are awesome!".getBytes();
    private PasswordCrypter[] passwordCrypters;
    private byte[][] encryptedMessages;

    @Before
    public void setUp() {
        passwordCrypters = new PasswordCrypter[] {
            new PasswordCrypter("passwd"),
            new PasswordCrypter("passwd"),
            new PasswordCrypter("otherPasswd")
        };

        encryptedMessages = new byte[passwordCrypters.length][];
        for (int i = 0; i < passwordCrypters.length; i++) {
            encryptedMessages[i] = passwordCrypters[i].encrypt(MESSAGE);
        }
    }

    @Test
    public void testEncrypt() {
        for (byte[] encryptedMessage : encryptedMessages) {
            assertFalse(Arrays.equals(MESSAGE, encryptedMessage));
        }

        assertFalse(Arrays.equals(encryptedMessages[0], encryptedMessages[2]));
        assertFalse(Arrays.equals(encryptedMessages[1], encryptedMessages[2]));
    }

    @Test
    public void testDecrypt() {
        for (int i = 0; i < passwordCrypters.length; i++) {
            assertArrayEquals(MESSAGE, passwordCrypters[i].decrypt(encryptedMessages[i]));
        }

        assertArrayEquals(MESSAGE, passwordCrypters[0].decrypt(encryptedMessages[1]));
        assertArrayEquals(MESSAGE, passwordCrypters[1].decrypt(encryptedMessages[0]));

        try {
            assertFalse(Arrays.equals(MESSAGE, passwordCrypters[0].decrypt(encryptedMessages[2])));
        } catch (CrypterException e) {
            // Anything goes as long as the above statement is not true.
        }

        try {
            assertFalse(Arrays.equals(MESSAGE, passwordCrypters[2].decrypt(encryptedMessages[1])));
        } catch (CrypterException e) {
            // Anything goes as long as the above statement is not true.
        }
    }
}

Si vous essayez de décrypter les données remplies par PKCS5 avec la mauvaise clé, puis de les décompresser (ce qui est fait automatiquement par la classe Cipher), vous obtiendrez probablement l'exception BadPaddingException (avec probablement un peu moins de 255/256, environ 99,61% ), parce que le remplissage a une structure spéciale qui est validée pendant unpad et que très peu de touches produiraient un remplissage valide.

Donc, si vous obtenez cette exception, attrapez-la et traitez-la comme une "mauvaise clé".

Cela peut également se produire lorsque vous fournissez un mot de passe erroné, qui est ensuite utilisé pour obtenir la clé à partir d'un fichier de clés, ou qui est converti en clé à l'aide d'une fonction de génération de clé.

Bien sûr, un mauvais remplissage peut également se produire si vos données sont corrompues pendant le transport.

Cela dit, il y a quelques remarques de sécurité concernant votre système:

• Pour le chiffrement basé sur un mot de passe, vous devez utiliser un SecretKeyFactory et PBEKeySpec au lieu d'utiliser un SecureRandom avec KeyGenerator. La raison en est que SecureRandom pourrait être un algorithme différent sur chaque implémentation Java, vous donnant une clé différente. SecretKeyFactory effectue la dérivation de clé d'une manière définie (et d'une manière jugée sécurisée, si vous sélectionnez le bon algorithme).

• N'utilisez pas le mode ECB. Il crypte chaque bloc indépendamment, ce qui signifie que des blocs de texte brut identiques donnent également des blocs de texte chiffré toujours identiques.

  Utilisez de préférence un mode de fonctionnement sécurisé , comme CBC (Cipher block chaining) ou CTR (Counter). Vous pouvez également utiliser un mode qui inclut également l'authentification, comme GCM (mode Galois-Counter) ou CCM (compteur avec CBC-MAC), voir le point suivant.

• Normalement, vous ne voulez pas seulement la confidentialité, mais aussi l'authentification, qui garantit que le message n'est pas falsifié. (Cela empêche également les attaques par texte chiffré choisi sur votre chiffrement, c'est-à-dire aide à la confidentialité.) Alors, ajoutez un MAC (code d'authentification de message) à votre message, ou utilisez un mode de chiffrement qui inclut l'authentification (voir point précédent).

• DES a une taille de clé effective de seulement 56 bits. Cet espace clé est assez petit, il peut être forcé brutalement en quelques heures par un attaquant dédié. Si vous générez votre clé par mot de passe, cela deviendra encore plus rapide. En outre, DES a une taille de bloc de seulement 64 bits, ce qui ajoute quelques faiblesses supplémentaires dans les modes de chaînage. Utilisez plutôt un algorithme moderne comme AES, qui a une taille de bloc de 128 bits et une taille de clé de 128 bits (pour la variante standard).

en fonction de l'algorithme de cryptographie que vous utilisez, vous devrez peut-être ajouter des octets de remplissage à la fin avant de chiffrer un tableau d'octets afin que la longueur du tableau d'octets soit multiple de la taille du bloc:

Plus précisément dans votre cas, le schéma de remplissage que vous avez choisi est PKCS5 qui est décrit ici: http://www.rsa.com/products/bsafe/documentation/cryptoj35html/doc/dev_guide/group_ CJ _SYM__PAD.html

(Je suppose que vous avez le problème lorsque vous essayez de chiffrer)

Vous pouvez choisir votre schéma de remplissage lorsque vous instanciez l'objet Cipher. Les valeurs prises en charge dépendent du fournisseur de sécurité que vous utilisez.

Au fait, êtes-vous sûr de vouloir utiliser un mécanisme de cryptage symétrique pour crypter les mots de passe? Ne serait-il pas meilleur hash à sens unique? Si vous avez vraiment besoin de pouvoir déchiffrer les mots de passe, DES est une solution assez faible, vous voudrez peut-être utiliser quelque chose de plus fort comme AES si vous devez rester avec un algorithme symétrique.

J'ai rencontré ce problème en raison du système d'exploitation, d'une plate-forme simple à différente sur la mise en œuvre de JRE.

new SecureRandom(key.getBytes())

obtiendra la même valeur sous Windows, alors qu'elle est différente sous Linux. Donc, sous Linux, il faut changer pour

SecureRandom secureRandom = SecureRandom.getInstance("SHA1PRNG");
secureRandom.setSeed(key.getBytes());
kgen.init(128, secureRandom);

"SHA1PRNG" est l'algorithme utilisé, vous pouvez vous référer ici pour plus d'informations sur les algorithmes.

Cela peut également être un problème lorsque vous entrez un mot de passe incorrect pour votre clé de connexion.