0

I want to use PBE to encrypt my data. So far, I have written the following code :

    moteurCryptage = Cipher.getInstance("PBEWithMD5AndDES");

        PBEKeySpec spécifClé=new PBEKeySpec(mdp.toCharArray());
        SecretKeyFactory usineàClefs=SecretKeyFactory.getInstance("PBEWithMD5AndDES");
        SecretKey clé=null;
        try {
            clé = usineàClefs.generateSecret(spécifClé);
        } catch (InvalidKeySpecException ex) {
            Logger.getLogger(DiskUtilView.class.getName()).log(Level.SEVERE, null, ex);
        }

    moteurCryptage.init(Cipher.ENCRYPT_MODE,clé);
        byte[] paramètresEncodage;
        try {
            paramètresEncodage=moteurCryptage.getParameters().getEncoded();
        } catch (IOException ex) {
            paramètresEncodage=null;
        }

    destination=moteurCryptage.update(source1.getBytes());
    destination=moteurCryptage.doFinal(source2.getBytes());

    moteurCryptage.init(Cipher.DECRYPT_MODE,clé,paramètresEncodage);

    source=new String(moteurCryptage.doFinal(destination));

Encryption seems to work (I don't get any error, neither during compilation nor execution) but the initialisation of the Cipher object for decryption doesn't accept the javax.crypto.SecretKey class (compilation error). It instead asks for a java.security.key.

What can I do?

Thanks in advance for the time you will spend trying to help me.

Zelig63
  • 1,592
  • 1
  • 23
  • 40
  • 1
    Uff, the french characters were hard to eliminate. Also, the variable names would be much more readable if in English :). And there were variables that were of unknown type to us. Please, next time, try to make it as compilable as possible. – Petr Janeček Mar 29 '12 at 15:34

1 Answers1

1

The problem is the line

moteurCryptage.init(Cipher.DECRYPT_MODE, cle, parametresEncodage);

which should be

moteurCryptage.init(Cipher.DECRYPT_MODE, cle, moteurCryptage.getParameters());

Also, as you pointed out, it then doesn't work for some strings (works only for those really short). The problem is that when you call update(), it saves some data into the resulting byte[]. When you call doFinal() on the same variable, it overwrites the data and they are lost forever. The doFinal() method doesn't do all the encrypting again, it only does the remaining part!

That means, that you

  • have to concatenate the source strings before you process them
  • or you have to preserve destination after update(), make destination2 for doFinal() and then both decrypt the same way - update() destination and doFinal() destination2
  • or you can make destination and destination2, concatenate them (here's how, e.g.) into a single completeDestination array and do decrypting doFinal() on that.

If you would like to see the code for all the above, just say a word.

Community
  • 1
  • 1
Petr Janeček
  • 37,768
  • 12
  • 121
  • 145
  • Well, it almost work fine. The compilation error has disappeared, encryption realized with the call of "doFinal" is correctly decrypted but a "double" encryption with a call to "update" followed by a call to "doFinal" leads to an unexpected result : if the first string is "First string" and the second string is "Second String", the decrypted result I obtain is "��/�q�L�nd string". :( – Zelig63 Mar 30 '12 at 15:11
  • OH! I'm going to edit my answer in 5 minutes, I have the solution. – Petr Janeček Mar 30 '12 at 15:58
  • I confirm that encrypting only one string at a time works. So, it is a solution to my problem. Nevertheles, it sounds strange : if I encrypt with "RSA/ECB/PKCS1Padding", the decrypted string contains both strings, one after the other. It seems that "update" and "doFinal" work differently depending on the algorithm used. – Zelig63 Mar 31 '12 at 06:57
  • I didn't test this, but I'd _guess_ that the `update()` on RSA returned `null` (please verify?), then the `doFinal()` encrypted the whole message. If the cipher is a block cipher, then `update()` encrypts only that much of the input that makes some blocks, and stores the rest in internal buffer for `doFinal()` or another `update`s. Enlarging the input sufficiently should conclude in the same behaviour we saw here. – Petr Janeček Apr 02 '12 at 21:29