What is the key size for PBEWithMD5AndTripleDES?

Question

I am trying to replace PBEWithMD5AndDES with PBEWithMD5AndTripleDES in existing code. So far, I use the same passphrase as before, and get this exception:

java.security.InvalidKeyException: illegal key size

I looked online and saw that DES uses a 64-bit key, and TripleDES uses a 128-bit key. I don’t quite understand how my passphrase is used to generate the key, and I don’t know where to look in order to fully understand this. My passphrase is 260 characters long. I tried to double the length, but get the same Exception.

I generate PBEKeySpec from my passphrase with an 8-byte salt and iteration counter 12. I see that there is another constructor that takes a keyLength argument, but the documentation describes it as being derived, but I don’t understand this. I have an idea that I need to change the iteration counter and / or provide the keyLength argument, but I don't want to just do it blindly without fully understanding what I'm doing.

Here is the main outline of the code I'm currently using:

String passphrase = ... byte[] salt = ... int iterationCount = 12; String algorithm = "PBEWithMD5AndTripleDES"; KeySpec keySpec = new PBEKeySpec(passPhrase.toCharArray(), salt, iterationCount); SecretKey key = SecretKeyFactory.getInstance(algorithm).generateSecret(keySpec); Cipher cipher = Cipher.getInstance(key.getAlgorithm()); AlgorithmParameterSpec paramSpec = new PBEParameterSpec(salt, iterationCount); cipher.init(Cipher.ENCRYPT_MODE, key, paramSpec); byte[] encoded = cipher.doFinal(data); 

Answer 1

PBEWith <Hash> AndTripleDES Requires No Limit Policy

This algorithm uses a 168-bit key (although due to vulnerabilities, it has an effective strength of 112 bits). To use a symmetric key of this length, you will need the "unlimited power restriction policy" set in your Java runtime.

The message "Invalid key size" indicates that the key length is not allowed by the policy; if the key length is incorrect for the algorithm, the SunJCE provider uses the message "Invalid key size".

Do not use PBEWith <Hash> AndTripleDES

Please note that "PBEWithMD5AndTripleDES" is a poor algorithm to use.

Password-based encryption usually follows PKCS # 5. It defines an encryption scheme for DES (or RC2) called PBES1. Since PBES1 was designed to generate 64-bit (or less) keys, Oracle created a proprietary extension to generate longer keys. It has not been subjected to the same verification as PKCS No. 5, and if you need to interact with any other platform, you need in the source code to find out how the key and initialization vector are derived.

It is also strange that the initialization vector is obtained from the password. The goal of IV is to create different encryption texts each time a given plain text is encrypted with the same key. If an IV is generated from a key, that target is defeated. The key detection algorithm used by PBES1 avoids this by including a “salt,” which should be different each time the password is used. But it would be easy to spoil it; providing IV directly to initiate encryption is more arbitrary and makes what is happening more obvious.

Use PBKDF2 instead

PKCS # 5 also defines the PBKDF2 key generation algorithm, which is now supported by Java. It provides increased security for PBES1, because the initialization vector and any other parameters required by the cipher are not derived from the password, but are selected independently.

Here is an example with PBKDF2 using AES. If you cannot follow the recommendations for upgrading to AES, this example can be applied to DESede using a key length of 192 and changing the occurrences of "AES" to "DESede".

TDEA Keying Parameters

There are three key options that can be used with TDEA ("Triple DES" or "DESede"). They accept 64-, 128-, or 192-bit keys (including parity bits), depending on the option.

The key sizes adopted as a result of TDEA implementation are vendor-specific; some require you to generate a 192-bit key, even if you use a 56-bit key, which is actually DES instead of TDEA. Most implementations will accept 16 or 24 bytes as a key.

Only three keys (168 bits or 192 bits with parity) can be considered as “strong encryption”. It has 112 bits of effective power.

Answer 2

According to Erickson, the “correct” answer to this question is to install unlimited power restriction policy files in the JRE.

This will do the encryption using PBEWithMD5AndTripleDES, but the received data cannot be decrypted, as far as I can tell. You will get a fill error exception. There may be some way to fix this, but for me it was enough evidence that the pursuit of this route was not worth it, it seems that it is a road that does not travel enough to correct mistakes or to popularize working examples.

I also discovered PBEWithSHA1AndTripleDES and tried it, but when decrypting, I got the same padding error.

I managed to change our requirements from PBEWithMD5AndTripleDES to just TripleDES (DESede), and this fixed the whole problem for me!