aspose file tools*
The moose likes Security and the fly likes InvalidKeyException in 3DES Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Spring in Action this week in the Spring forum!
JavaRanch » Java Forums » Engineering » Security
Bookmark "InvalidKeyException in 3DES" Watch "InvalidKeyException in 3DES" New topic
Author

InvalidKeyException in 3DES

Suzi Cooper
Ranch Hand

Joined: Jul 23, 2005
Posts: 45
Hi,

I am trying to encrypt a string using Triple DES algorithm but i get the following exception :

java.security.InvalidKeyException: Wrong key size

Here is the code :



I have added the JCE jars (local_policy.jar and US_export_policy.jar) in JAVA_HOME/jre/security as suggested by some posts.

I understand that DESedeKeySpec requires at least 24 bytes and my string is around 20.

Can anyone suggest how to fix this?
greg stark
Ranch Hand

Joined: Aug 10, 2006
Posts: 220
Well, you could use a 24 byte key, right? Even better, use one of the Password-based encryption (PBE) Ciphers. The are some example in http://java.sun.com/javase/6/docs/technotes/guides/security/crypto/CryptoSpec.html and elsewhere.


Nice to meet you.
Suzi Cooper
Ranch Hand

Joined: Jul 23, 2005
Posts: 45
Here is what i am trying to do : I am calling a web service with encryted string (Triple DES). The encryption key provided is : "kgl51um6adpbjnbz6xln" which is 20bytes.

Here is the code :



I get the following exception:
java.security.InvalidKeyException: Invalid key length: 20 bytes

Am i missing something very basic here?
I am a novice to this arena so apologies if this is a silly question.
[ November 07, 2008: Message edited by: Suzi Cooper ]
Henry Wong
author
Sheriff

Joined: Sep 28, 2004
Posts: 18896
    
  40

Here is what i am trying to do : I am calling a web service with encryted string (Triple DES). The encryption key provided is : "kgl51um6adpbjnbz6xln" which is 20bytes.


Triple DES uses a 24 byte key -- not 20 bytes. You need 24 bytes. The key provided is not valid.


And BTW, taking a string, and using getBytes() to get a key is not a good idea. The letters and numbers fall into a tight range, defined by ASCII, so the key is not very strong.

Henry
[ November 07, 2008: Message edited by: Henry Wong ]

Books: Java Threads, 3rd Edition, Jini in a Nutshell, and Java Gems (contributor)
Pat Farrell
Rancher

Joined: Aug 11, 2007
Posts: 4659
    
    5

Originally posted by Henry Wong:
And BTW, taking a string, and using getBytes() to get a key is not a good idea. The letters and numbers fall into a tight range, defined by ASCII, so the key is not very strong.


It is much worse than this. DES is defined to use the most significant seven bits of each key byte, not the least significant bits. Thus the characters "a" and "b" are identical as key characters. They differ only in least significant byte.

3DES is just longer, same rules apply.

to get a reasonably strong key, you need to accept the user's input and put it through a hash, say MD5 or SHA1.

And, no one should be using DES or 3DES anymore. Use AES. If you think AES128 is too weak, use AES256.
Suzi Cooper
Ranch Hand

Joined: Jul 23, 2005
Posts: 45
Thanks for the info.
Please correct me if i am wrong here...if i use padding , should it not add relevant number of bytes to the key to make it 24 bytes.



What am i missing here?
Henry Wong
author
Sheriff

Joined: Sep 28, 2004
Posts: 18896
    
  40

Originally posted by Suzi Cooper:

Please correct me if i am wrong here...if i use padding , should it not add relevant number of bytes to the key to make it 24 bytes.


The "padding" is used for the buffer that is to be encrypted. It is not referring to padding the key. Triple DES uses a 24 byte key -- not 20 bytes. You need 24 bytes. The key provided is not valid.

Henry
Suzi Cooper
Ranch Hand

Joined: Jul 23, 2005
Posts: 45
Thanks a lot. I misunderstood the padding concept i guess.
Pat Farrell
Rancher

Joined: Aug 11, 2007
Posts: 4659
    
    5

Originally posted by Suzi Cooper:
I misunderstood the padding concept i guess.


Well, I think its more than none of us would consider padding the key. You could, in theory, just append four blanks, A's stars or whatever, to make your character string be 24 characters long, and then get the bytes from it. It would technically work.

But do not do this. Its a terrible idea.

Seriously, use a MD5 or SHA output as the key.
greg stark
Ranch Hand

Joined: Aug 10, 2006
Posts: 220
or use the PBE ciphers as I mentioned earlier, as these perform the hashing for you as specified by PKCS5.
James Sabre
Ranch Hand

Joined: Sep 07, 2004
Posts: 781

Originally posted by Pat Farrell:


But do not do this. Its a terrible idea.

Seriously, use a MD5 or SHA output as the key.


Just using MD5 or SHA hashing not such a good idea. It adds no entropy to the key beyond that provided by the string being hashed. One still has to pad the key to 24 bytes.

As Greg says, if you must use a String as a key (and I hate the idea) then use PBE based encryption. With little programming effort, this provides a key and IV as appropriate to the algorithm being used. OK, this still adds no entropy to the key but it is a standard, has been thought out thoroughly and the limitations are well understood.
[ November 13, 2008: Message edited by: James Sabre ]

Retired horse trader.
 Note: double-underline links may be advertisements automatically added by this site and are probably not endorsed by me.
Pat Farrell
Rancher

Joined: Aug 11, 2007
Posts: 4659
    
    5

Originally posted by James Sabre:
Just using MD5 or SHA hashing not such a good idea. It adds no entropy to the key beyond that provided by the string being hashed. One still has to pad the key to 24 bytes.


MD5 generates a 128-bit hash value. (16 bytes).

SHA generates a 160-bit digest. (20 bytes)

If you are insisting on using three key 3DES, you have to generate two hashes, from separate parts of the long passphrase. If the user enters a eight character passphrase, nothing you can do will generate a proper 168 bit key (which naive arithmetic says needs 21 bytes, but in fact, needs 24 because DES uses only seven bits per key byte)

When using DES or 3DES, the hash helps a lot because it populates all the bit positions. Even with AES, hashing it converts all the seven bit ascii to eight bits.

Padding does not generate entropy. And padding with printable ASCII characters does not address the DES key's use of high order bits.

Using a HMAC is a better idea. but it does not add entropy to the resulting key, as the salt-like portion is constant.
James Sabre
Ranch Hand

Joined: Sep 07, 2004
Posts: 781

Originally posted by Pat Farrell:

MD5 generates a 128-bit hash value. (16 bytes).

Agreed but only 128 bit entropy if the value being hashed has more than 128 bit entropy.

SHA generates a 160-bit digest. (20 bytes)

Agreed but only 160 bit entropy if the value being hashed has more than 160 bit entropy.

If you are insisting on using three key 3DES, you have to generate two hashes,

Using hashing PBE does this behind the scenes using standard, well understood procedures the details of which depend on the PBE algorithm being used. It also generates an IV if required BUT the total entropy is not more than the entropy of the passphrase.

from separate parts of the long passphrase. If the user enters a eight character passphrase, nothing you can do will generate a proper 168 bit key (which naive arithmetic says needs 21 bytes, but in fact, needs 24 because DES uses only seven bits per key byte)

Agreed

When using DES or 3DES, the hash helps a lot because it populates all the bit positions. Even with AES, hashing it converts all the seven bit ascii to eight bits.

I'm not arguing about whether or not to hash; PBE uses hashing. I'm arguing that PBE should be used since it is a standard.

For DES or 3DES there is a small increase in entropy over just using the bytes because it spreads the entropy of the passphrase so that the least significant bit of the passphase does have some effect. With AES it makes no difference since ALL the bits of the key bytes are used.

Padding does not generate entropy. And padding with printable ASCII characters does not address the DES key's use of high order bits.

Agreed but hashing does not in general generated entropy. There is a small increase for DES and 3DES as explained above.

Using a HMAC is a better idea. but it does not add entropy to the resulting key, as the salt-like portion is constant.


Agreed but some PBE versions use it.

As far as I can see, the only thing I think we differ on is that I say don't just roll your own key generation from a password/passphrase; I say use the standard off-the-shelf PBE implementations.
[ November 14, 2008: Message edited by: James Sabre ]
Pat Farrell
Rancher

Joined: Aug 11, 2007
Posts: 4659
    
    5

Originally posted by James Sabre:
As far as I can see, the only thing I think we differ on is that I say don't just roll your own key generation from a password/passphrase; I say use the standard off-the-shelf PBE implementations.


In general, one should not roll your own anything related to crypto. Its really easy to make small mistakes and wreck the security of the system.

My only problem with the PBE provisions of the javax.crpyto stuff is that the documentation is terrible. Its next to impossible to know what values are legal, and so one might think that your PBE with DES is encouraged.

DES and 3DES should not be used for new work. its OK to use them for backward compatibility with legacy code, but its long past time to move past DES
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: InvalidKeyException in 3DES