Cryptage / déctyptage PBEEncryptor

**Jose.N70** · 12/02/2010, 10h17

Bonjour à tous, je viens vers vous afin de solliciter une aide de votre part sur l'usage d'une class disponible sur ce site.

J'utilise la class PBEEncryptor pour encrypter un fichier avec un mot de passe, puis pour le décrypter.

Pour le cryptage cette class semble fonctionner sans problème, mais lors du décryptage je rencontre un problème voici le code utilisé et l'erreur rencontrée :

Pour le cryptage :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
 
String mdp = "password";
char[] password = mdp.toCharArray();
 
SecretKey cle = PBEEncryptor.generateKey(password);
try {
PBEEncryptor cryptage = new PBEEncryptor(cle);
cryptage.encryptFile(compressFile, crypteFile);
} catch (InvalidKeyException e1) {
e1.printStackTrace();
} catch (FileNotFoundException e1) {
e1.printStackTrace();
} catch (IOException e1) {
e1.printStackTrace();
}

Pour le décryptage :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
String mdp = "password";
char[] password = mdp.toCharArray();
 
SecretKey cle = PBEEncryptor.generateKey(password);
try {
PBEEncryptor decryptage = new PBEEncryptor(cle);
decryptage.decryptFile(crypteFile,compressFile);
 
} catch (InvalidKeyException e1) {
e1.printStackTrace();
} catch (FileNotFoundException e1) {
e1.printStackTrace();
} catch (IOException e1) {
e1.printStackTrace();
}

L'erreur rencontrée au décryptage est :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
 
javax.crypto.BadPaddingException: Given final block not properly padded
    at com.sun.crypto.provider.SunJCE_f.b(DashoA13*..)
    at com.sun.crypto.provider.SunJCE_f.b(DashoA13*..)
    at com.sun.crypto.provider.SunJCE_ab.b(DashoA13*..)
    at com.sun.crypto.provider.PBEWithMD5AndDESCipher.engineDoFinal(DashoA13*..)
    at javax.crypto.Cipher.doFinal(DashoA13*..)
    at org.cosmopol.crypto.CipherEncryptor.crypt(CipherEncryptor.java:70)
    at org.cosmopol.crypto.PBEEncryptor.decryptStream(PBEEncryptor.java:351)
    at org.cosmopol.crypto.StreamEncryptor.decryptFile(StreamEncryptor.java:100)
    at org.test.Application$1.actionPerformed(Application.java:323)
    at javax.swing.AbstractButton.fireActionPerformed(Unknown Source)
    at javax.swing.AbstractButton$Handler.actionPerformed(Unknown Source)
    at javax.swing.DefaultButtonModel.fireActionPerformed(Unknown Source)
    at javax.swing.DefaultButtonModel.setPressed(Unknown Source)
    at javax.swing.plaf.basic.BasicButtonListener.mouseReleased(Unknown Source)

Mon fichier pèse 1 754 Ko ( environ )

Ps : pour le mot de passe la c'est pour le test cela va de soit

Merci à vous

**Marco46** · 12/02/2010, 11h18

Erreur de padding = erreur de bourrage. En gros ça doit être un chiffrement par bloc et qui dit bloc dit blocs de longueurs identiques ce qui signifie que s'il manque des bytes pour avoir des blocs de longueur identiques sur le dernier bloc, ce dernier est complété par des caractères par défaut (ça dépend du padding utilisé.).

Voilà en gros pour l'explication.

Maintenant pour trouver concrètement le problème il faudrait avoir le code source des méthodes encryptFile() et decryptFile().

EDIT : au fait on dit chiffrement et pas cryptage qui n'existe pas.

**Jose.N70** · 12/02/2010, 13h15

La classe utilisée :

http://www.developpez.net/forums/m2495734-75/

La superclasse :

http://www.developpez.net/forums/m2474125-73/

La classe encryptFile() et decryptFile()

http://www.developpez.net/forums/m2587386-76/

----------

Merci pour la correction cryptage / chiffrement

**Marco46** · 12/02/2010, 14h53

La classe CipherEncryptor doit être bugguée lors du déchiffrement pour la gestion du padding. Lors du chiffrement normalement le Cipher fait le padding tout seul mails comme il fait tout à la mimine et que je ne vois aucune notion de padding dans la méthode crypt() de CipherEncryptor ...

D'ailleurs il le dit lui même dans ses posts :

Oui il y a quelques bugs dans ma librairie de Sécurité, mais les classes postées ne sont pas celles de la dernière version, et j'ai la flemme de tout modifier. Je vous donnerai avec plaisir la dernière version du jar par mp.

Utilises un autre exemple de code que celui-ici, visiblement il marche mal.

Par exemple regarde du côté de BouncyCastle dont voici un exemple de chiffrement AES :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
package chapter2;
 
import java.security.Security;
 
import javax.crypto.Cipher;
import javax.crypto.spec.SecretKeySpec;
 
import org.bouncycastle.jce.provider.BouncyCastleProvider;
 
 
/**
 * Basic symmetric encryption example
 */
public class SimpleSymmetricExample
{   
    public static void main(
        String[]    args)
        throws Exception
    {
    	Security.addProvider(new BouncyCastleProvider());
 
        byte[]        input = new byte[] { 
                0x00, 0x11, 0x22, 0x33, 0x44, 0x55, 0x66, 0x77, 
                (byte)0x88, (byte)0x99, (byte)0xaa, (byte)0xbb,
                (byte)0xcc, (byte)0xdd, (byte)0xee, (byte)0xff };
        byte[]        keyBytes = new byte[] { 
                0x00, 0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 0x07,
                0x08, 0x09, 0x0a, 0x0b, 0x0c, 0x0d, 0x0e, 0x0f,
                0x10, 0x11, 0x12, 0x13, 0x14, 0x15, 0x16, 0x17 };
 
        SecretKeySpec key = new SecretKeySpec(keyBytes, "AES");
 
        Cipher        cipher = Cipher.getInstance("AES/ECB/NoPadding", "BC");
 
 
        System.out.println("input text : " + Utils.toHex(input));
 
        // encryption pass
 
        byte[] cipherText = new byte[input.length];
 
        cipher.init(Cipher.ENCRYPT_MODE, key);
 
        int ctLength = cipher.update(input, 0, input.length, cipherText, 0);
 
        ctLength += cipher.doFinal(cipherText, ctLength);
 
        System.out.println("cipher text: " + Utils.toHex(cipherText) + " bytes: " + ctLength);
 
        // decryption pass
 
        byte[] plainText = new byte[ctLength];
 
        cipher.init(Cipher.DECRYPT_MODE, key);
 
        int ptLength = cipher.update(cipherText, 0, ctLength, plainText, 0);
 
        ptLength += cipher.doFinal(plainText, ptLength);
 
        System.out.println("plain text : " + Utils.toHex(plainText) + " bytes: " + ptLength);
    }
}

La classe utilitaire :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
package chapter2;
 
/**
 * General utilities for the second chapter examples.
 */
public class Utils
{
    private static String	digits = "0123456789abcdef";
 
    /**
     * Return length many bytes of the passed in byte array as a hex string.
     * 
     * @param data the bytes to be converted.
     * @param length the number of bytes in the data block to be converted.
     * @return a hex representation of length bytes of data.
     */
    public static String toHex(byte[] data, int length)
    {
        StringBuffer	buf = new StringBuffer();
 
        for (int i = 0; i != length; i++)
        {
            int	v = data[i] & 0xff;
 
            buf.append(digits.charAt(v >> 4));
            buf.append(digits.charAt(v & 0xf));
        }
 
        return buf.toString();
    }
 
    /**
     * Return the passed in byte array as a hex string.
     * 
     * @param data the bytes to be converted.
     * @return a hex representation of data.
     */
    public static String toHex(byte[] data)
    {
        return toHex(data, data.length);
    }
}

C'est quand même plus simple !

**Jose.N70** · 12/02/2010, 23h00

Merci de prendre le temps de m'aider, concernant les classes j'ai demandé à Razgriz ( auteur de ces classes ) les dernières modifications, ce dernier m'a fait parvenir les sources sans problème, mais l'erreur reste présente.

En ce qui concerne ton exemple certes il est plus simple mais sauf erreur de ma part il oblige à installer jce_policy-6 (unlimited strength cryptography) ce que je ne peux pas faire.

**Marco46** · 15/02/2010, 10h41

En ce qui concerne ton exemple certes il est plus simple mais sauf erreur de ma part il oblige à installer jce_policy-6 (unlimited strength cryptography) ce que je ne peux pas faire.

Effectivement c'est le cas.

Malheureusement je ne peux pas aller plus loin dans l'aide. C'est une erreur de padding c'est certain, il y a plusieurs padding différents, il te faut trouver lequel est utilisé par défaut pour l'algorithme de chiffrement que du utilise puis respecter les règles du padding lors du déchiffrement.

**Jose.N70** · 15/02/2010, 13h19

Merci en tout cas d'avoir pris le temps de répondre à cette question, je vais laisser un mail à son concepteur, ou éventuellement si une personne pouvait m'aiguiller pour ce problème.

Merci

**Razgriz** · 15/02/2010, 14h06

Avant toute chose, j'utilise cryptage/decryptage/chiffrement dans mes posts, c'est pour que l'opération que j'effectue soit bien claire.
Les puristes diront que qeul le mot chiffrement existe. Personnellement, j'utilise cryptage quand je transforme des données originales en données chiffrées, et décryptage quand j'effectue l'opération inverse. J'utilise le terme chiffrement quand le contexte est indépendant de l'opération (càd quand je fait soit l'une, soit l'autre, peu importe).

-------------------------------------------------------------------------

C'est carrément bizarre, moi j'ai aucune exception lancée, tout se crypte bien.
Comme je t'ai donné la dernière version de ma librairie, une des derniers problèmes qui pourrait y avoir est que tu possède une version corrompue/bugguée de l'api de sécurité Java.

Tu as la dernière version?

Comme l'a souligné un membre les erreurs de padding sont des erreurs de chiffrement de fin de fichier.

En gros, un cipher travaille avec des blocs de taille fixe. Quand on arrive en fin de fichier, il est possible que le bloc soit pas rempli totalement, il faut donc y mettre des trucs pour qu'il soit plein.
Les classes que ma librairie font ça (dans le code, tu verras que si le dernier bloc est pas plein (si y a moins d'octets lus que la taille du buffer), on utilise doFinal plutôt qu'update).
En gros, y a un truc qui pue dans cette histoire.

Vérifie toujours ta version, je vais essayer de provoquer le bug chez moi.

Je viens à l'instant de faire un test sur un fichier texte de 3ko, et sur un mp3 et 4Mo, aucun problème dans les deux cas.

Voici le code de ma méthode main :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
 
String pass = "password";
SecretKey key = PBEEncryptor.generateKey(pass.toCharArray());
 
PBEEncryptor cipher = new PBEEncryptor(key);
 
File in = new File("test.mp3");
File out = new File("test.cypted");
File in2 = new File("test2.mp3");
cipher.encryptFile(in, out);
 
System.out.println("file encrypted");
 
cipher.decryptFile(out, in2);
 
System.out.println("file decrypted");

Ca ne plante pas, et in et in2 ont exactement le même contenu.

**Razgriz** · 15/02/2010, 18h09

En fait, ça plante quand on change de clé et de chiffre en cours de route.

Plus précisément, quand on ajoute

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
 
key = PBEEncryptor.generateKey(pass.toCharArray());
cipher = new PBEEncryptor(key);

après le premier println, ça foire. Ca c'est étrange, car la clé est reconnue correcte, ça se lance bien, c'est après que ça plante.

Plus précisément, ça plante sur la ligne cipher.doFinal() de ma librairie.

C'est ça qui est étrange. J'ai bien fait des update comme il le fallait, et comme je suis en décryptage, j'ai bien un fichier dont la taille est un multiple de la longueur de mes blocs.
Ce qui fait en gros que je fait n updates, et qu'raprès ces update il ne me reste aucun byte à lire, je les ai tous lus. (J'ai vérifié dans le code, c'est bien ce qui se passe).
Je fais donc un doFinal() pour clôturer le dechiffrement, et là, ça foire, alors que y a pas de raison.

Bizarre.

[EDIT]
Quand je sauve la clé pbe dans un fichier (ObjectOutputStream), que je la charge pour chiffrer, je crée l'encrypteur dessus, je crypte, ça marche.
Pour le déchiffrement, je charge la clé, je crée l'encrypteur dessus, je décrypte, ça marche aussi.

Donc visiblement le stress vient de la génération de clés. Le chiffrement lancé à partir de deux clés générées sur le même mot de passe se produit différemment. Mais uniquement à la clôture du fichier, tous les bytes sont déchiffrés correctement.
[/EDIT]

[EDIT]
@Marco

Envoyé par Marco

Lors du chiffrement normalement le Cipher fait le padding tout seul mails comme il fait tout à la mimine et que je ne vois aucune notion de padding dans la méthode crypt() de CipherEncryptor ...

Faux. Voici la méthode par laquelle tout le chiffrement passe, tu verras que le padding y est géré correctement.
Je m'explique : en premier lieu je calcule les tailles de blocs propres à l'algorithme de chiffrement.
Ensuite je chiffre les données par blocs de taille précédemment calculée, si je suis capable de lire autant de données.
Sinon, je fais un doFinal (plutôt qu'un update) sur ce qui reste.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
 
public void crypt(InputStream in, OutputStream out, Cipher cipher)
        throws IOException
    {
        int blockSize = cipher.getBlockSize();
        int outputSize = cipher.getOutputSize(blockSize);
        byte[] inBytes = new byte[blockSize];
        byte[] outBytes = new byte[outputSize];
 
        int inLength = 0;
        boolean done = false;
        while(!done)
        {
            inLength = in.read(inBytes);
            if(inLength == blockSize)
            {
                try
                {
                    int outLength = cipher.update(inBytes, 0, blockSize, outBytes);
                    out.write(outBytes, 0, outLength);
                }
                catch(ShortBufferException e)
                {
                    e.printStackTrace();
                }
            }
            else
                done = true;
        }
 
        try
        {
            if(inLength > 0)
                outBytes = cipher.doFinal(inBytes, 0, inLength);
            else
                outBytes = cipher.doFinal();
            out.write(outBytes);
        }
        catch(IllegalBlockSizeException e)
        {
            e.printStackTrace();
        }
        catch(BadPaddingException e)
        {
            e.printStackTrace();
        }
    }

Envoyé par Marco

C'est une erreur de padding c'est certain

C'est probablement faux, comme les tests dont j'ai parlé le montrent. C'est une erreur de padding qui fait planter le bazar, mais ça ne veut pas dire que c'est la source du problème. Au vu de ce que j'ai sit avec les edit, je suis à présent presque certain que ça vient de la génération de clés. Dtoit y avoir une subtilité à côté de laquelle je suis passé quand j'ai conçu tout ça.
[/EDIT]

A côté de ça ça me préoccupe ce bug, si qqn trouve la solution je suis preneur ;-)

**Jose.N70** · 15/02/2010, 21h05

Envoyé par Razgriz

....
Comme je t'ai donné la dernière version de ma librairie, une des derniers problèmes qui pourrait y avoir est que tu possède une version corrompue/bugguée de l'api de sécurité Java.

Tu as la dernière version?

Oui tout a fait ...

**Razgriz** · 17/02/2010, 00h11

Oui oui c'est normal, je cherche.
Marco a peut-être une idée aussi, j'ai peut-être dit des bêtises dans mon post, même si je suis à peu près sur d'être sur la bonne piste.

**Marco46** · 17/02/2010, 09h53

Ce que je comprends pas surtout c'est que tu programmes le padding toi même. Normalement en faisant le Cipher.getInstance() tu indiques en paramètre l'algo de chiffrement suivi du mode suivi du padding et c'est la classe fille de Cipher selon l'implémentation du provider choisi qui réalise le padding toute seule.

Toi tu fais des petits blocs d'abord que tu passes ensuite dans ton Cipher et ça j'ai du mal à le comprendre. Maintenant je connais pas l'algorithme que tu utilises, perso j'aurais utilisé plutôt AES mébon.

Donc voilà je peux pas dire mieux.

Invité · 17/02/2010, 13h03

Envoyé par Marco46

Ce que je comprends pas surtout c'est que tu programmes le padding toi même. Normalement en faisant le Cipher.getInstance() tu indiques en paramètre l'algo de chiffrement suivi du mode suivi du padding et c'est la classe fille de Cipher selon l'implémentation du provider choisi qui réalise le padding toute seule.

Toi tu fais des petits blocs d'abord que tu passes ensuite dans ton Cipher et ça j'ai du mal à le comprendre. Maintenant je connais pas l'algorithme que tu utilises, perso j'aurais utilisé plutôt AES mébon.

Donc voilà je peux pas dire mieux.

Je suis entiérement d'accord.
Bien que bugguée pour certaines choses l'API standard java de crypto permet de faire des choses standard, niveau padding notamment.
De plus utiliser MD5 avec simple DES de nos jours est vraiment pas sécure du tout.

@Jose: tu as regardé ce lien : http://www.java2s.com/Code/Java/Secu...ameterSpec.htm ?
Il initialise avec un padding PKCS#7 avec du triple DES et SHA (ce qui est vraiment beaucoup mieux que MD5), tente de voir si ton erreur de padding est toujours là...
Il utilise BouncyCastle apparemment, qui marche très bien et respecte la JCA

**Jose.N70** · 19/02/2010, 23h10

Envoyé par George7

...
@Jose: tu as regardé ce lien : http://www.java2s.com/Code/Java/Secu...ameterSpec.htm ?
Il initialise avec un padding PKCS#7 avec du triple DES et SHA (ce qui est vraiment beaucoup mieux que MD5), tente de voir si ton erreur de padding est toujours là...
Il utilise BouncyCastle apparemment, qui marche très bien et respecte la JCA

Pour utiliser cet exemple il faut installer jce_policy-6, et comme je le précise plus haut je ne peux pas ...
Mais merci tout de même

Invité · 20/02/2010, 12h47

Envoyé par Jose.N70

Pour utiliser cet exemple il faut installer jce_policy-6, et comme je le précise plus haut je ne peux pas ...
Mais merci tout de même

Oups au temps pour moi. Ceci dit en général j'essaie d'éviter les solutions maison (que ce soit pour la compatibilité ou la sécurité). Quelle est la raison qui fait tu ne peux pas utiliser jce_policy-6 ?

**Jose.N70** · 20/02/2010, 13h11

L'application que je développe est destinée à être utilisée sur plusieurs postes, et je n'ai pas la possibilité de modifier les données de ces ordinateurs.

**Marco46** · 22/02/2010, 09h48

???

J'avais pensé à une raison légale, pas à une raison technique quand tu disais ne pas pouvoir utiliser le jce_policy.

Il y a forcément une solution technique. Qu'entends-tu par "je n'ai pas la possibilité de modifier les données de ces ordinateurs", tu as bien la possibilité d'installer ton soft non ? Donc tu peux copier les bons fichiers aux bons endroits.

**Jose.N70** · 22/02/2010, 11h39

L'application est nomade ( utilisée sur une clé USB ). Les postes sur lesquelles elle sera utilisée ne m'appartiennent pas et je n'ai pas l'autorisation d'y modifier des fichiers.

Et la contrainte légale est aussi présente

**Marco46** · 22/02/2010, 15h22

Alors là tu as un sacré problème, on ne peut pas te demander d'avoir un degré de sécurité pour tes fichiers via du chiffrement, et t'interdire derrière d'utiliser les APIs de chiffrement.

La limitation de longueur de clef est liée au JRE. Tu ne peux rien y faire. Es-tu obligé d'écrire ton application en Java ? Peut être qu'OpenSSL n'a pas besoin d'effectuer des paramétrages sur le système pour être utilisable, je ne sais pas. Pour ce qui est de Java ça me semble compliqué de chiffrer quoi que ce soit correctement dans ces conditions.

**Jose.N70** · 23/02/2010, 23h26

J'ai effectivement une contrainte imposée pour java

Cryptage / déctyptage PBEEncryptor

Sécurité Java

Discussions similaires

Partager

Partager