keytool -genseckey -alias TDES -keyalg DESede -keysize 128 works within jre/bin folder but not when the keytool.exe is on another location

Question

I would like to create a TDES key with size 128bits and 2KTDES key with 192bits for authentication in a Desfire smart card. Hence I have used the keytool to generate the jceks with the following command. When I run the same under the C:\Program Files (x86)\Java\jdk1.8.0_25\jre\bin folder I can see that the execution succeeds and the jceks is created. However when the export the keytool.exe to another location perhaps the desktop, I can see that the same command fails with the following error.

C:\Users\Charan\Desktop\KeyGen>keytool -genseckey -alias TDES -keyalg DESede -keysize 128 -storetype jceks -keystore TDES.jceks -storepass change -keypass change
keytool error: java.security.InvalidParameterException: Wrong keysize: must be equal to 112 or 168

C:\Users\Charan\Desktop\KeyGen>
C:\Users\Charan\Desktop\KeyGen>

I tried the same with both 112 and 168 options, either way it executes without errors but the keysizes created in both the cases is 192 bits. But the original question still remains a mystery because when I tried to create both 192 and 256 bit keys with DESEDE, I was able to do them when running the keytool from the bin folder. The keystore files generated did have the correct key length, 192 and 256.

Answer 1

Meta: this may better fit security or even superuser; if it migrates take my answer along please.

How big? A (full) TDES aka DESede key contains 168 bits of "real" key, but the stored form includes bits originally reserved for parity and today often ignored totalling 192 bits = 24 octets. "Two-key TDES" (TDEA keying option 2) has 112 "real" bits, stored sometimes as 128 bits = 16 octets where the first 8 octets (k1) is duplicated as k3 during encryption and decryption, sometimes as 192 bits = 24 octets where the first 8 octets are actually duplicated in the last 8 octets so that k3 = k1.

The KeyGenerator for DESede in the Oracle-formerly-Sun provider SunJCE accepts only 112 or 168 bits as the size, and stores always in the 24-octet form; generating 112 bits produces a stored key with k3=k1. This is apparently because the Cipher from that provider only works with the 24-octet form. The BouncyCastle provider (which I use) KeyGenerator accepts either 112 or 128 to generate the 16-octet form and either 168 or 192 to generate the 24-octet form, and its Cipher works with either form. No DESede implementation I've seen (Java or other) generates or uses a 256-bit key; are you sure you didn't confuse that with AES?

keytool.exe actually runs a JVM and loads Java classes to do the crypto operations including key generation. Normally it uses the JRE in the same directory, but if you've moved the .exe it must use some other method to find the JRE; on Windows I bet it uses same registry entries used to find the JRE for browser applets. This is not normally the JRE within a JDK like yours, and I'm not sure it can be. If you have the JRE-in-JDK customized with e.g. Bouncycastle, but the "browser" JRE not, you should get the results you describe.

Caveat: two-key TDES only has 56 bits of strength because of the meet-in-the-middle attack which is now at least nearly practical, and thus is not accepted as secure; see

• https://crypto.stackexchange.com/questions/16073/why-is-triple-des-not-vulnerable-to-meet-in-the-middle-attacks
• https://crypto.stackexchange.com/questions/24210/128-bit-3des-key-and-aes-key-whats-the-difference
• https://crypto.stackexchange.com/questions/25258/can-cycle-finding-techniques-reduce-the-memory-usage-of-the-mitm-attack-against

(and this point is definitely ontopic for crypto).