*
The moose likes Security and the fly likes 168 bit 3DES encryption and decryption.... Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Android Security Essentials Live Lessons this week in the Android forum!
JavaRanch » Java Forums » Engineering » Security
Bookmark "168 bit 3DES encryption and decryption...." Watch "168 bit 3DES encryption and decryption...." New topic
Author

168 bit 3DES encryption and decryption....

james edwin
Ranch Hand

Joined: Nov 22, 2001
Posts: 393
hi,

I am new to security. i have requirement where i need to stored password in encrypted format in database using 168 bit 3 DES. (and then 56 key will saved somewhere in secure path on server and that will changed frequently for security reasons and db will also be updated).

Can you guide me from where to start. i did some search for 3 des.

Thanks,

PS: this needs to implemented in Java


Regards,
James
Ulf Dittmer
Marshal

Joined: Mar 22, 2005
Posts: 41149
    
  45
The Java API for encryption/decryption is called "JCE", and it's part of the JDK. You can find some links regarding it in the http://faq.javaranch.com/java/SecurityFaq#encryption page, including an example of how to use DES. (Note that 3DES/Triple-DES is called "DESede" in the JCE world.)


Ping & DNS - my free Android networking tools app
james edwin
Ranch Hand

Joined: Nov 22, 2001
Posts: 393
Thanks i will have a look.
james edwin
Ranch Hand

Joined: Nov 22, 2001
Posts: 393
i looked at the link and that was helpful.

Can you please verify that i understood correctly or not.

Requirement - encrypt password using 168 bit using 3 des and save 56 bit keys on some where on server drive in secure location and save encrypted password in the database.


My understanding :- for 168 bit encryption, i need to generate three keys with 56 bits and do the following for encryption :-

ciphertext = EK3(DK2(EK1(plaintext)))
I.e., DES encrypt with Key 1, DES decrypt with Key 2, then DES encrypt with Key3.
E -encrypt and D - descrypt

Decryption is the reverse:

plaintext = DK1(EK2(DK3(ciphertext)))
I.e., decrypt with K3, encrypt with K2, then decrypt with K1.



and save all those three 56 bit keys in somewhere. Is my understanding is correct ?

I am new to security, It may be a small question, but important for me to clear my understanding.

I am also refering this http://java.sun.com/j2se/1.5.0/docs/guide/security/jce/JCERefGuide.html

Thanks



John Kimball
Ranch Hand

Joined: Apr 13, 2009
Posts: 96
1. That's basically the 168 bit version of the algorithm, but I dunno if the JCE has something which does it for you automatically.

2. If you don't need to reclaim the original password--that is, if it's ONLY for authentication by your system--then you can use a one-way hash function (e.g., SHA2). This avoids the need for storing the password somewhere in the network.

Just be warned that the bit-strength of a hash function is effectively HALF, because of the birthday attack. So a hash function that generates a 256 bit hash is effectively as strong 128 bits. That's a slight lie: In practice since most hash functions seem to have some exploitable weaknesses, so the bit strength would be somewhat less.

3. For password storage, it's not enough to just encrypt/decrypt. The problem is this: What happens if two users choose the same password? If they can access the password table they can now check and see who else has the same password!

The standard way around this is to alter the plaintext before encrypting/hashing: One easy way is to mix the password with the username.

...

If you're new to security, "Applied Cryptograhy" is a very nice read. The algorithms & cryptanalysis info are dated--don't assume otherwise!--but the ideas are still relevant and his writing style makes it fairly gentle.
james edwin
Ranch Hand

Joined: Nov 22, 2001
Posts: 393
Hi John,

Thanks for the reply. I need to retrieve password and use it again. I also thought of hash, but as i have to retrieve and use to again at some other place i can't use hash.

What i wanted to understand was for 3des, we have to generate three keys differently and there is not auto way for 168 bit..right ?
Ulf Dittmer
Marshal

Joined: Mar 22, 2005
Posts: 41149
    
  45
Maybe this full example will make things clearer: http://www.java2s.com/Code/Java/Security/TripleDES.htm It actually stores the key to disk so it can be reused later.
james edwin
Ranch Hand

Joined: Nov 22, 2001
Posts: 393
Thanks this really help.

is DESede by default means 168 bit or 112 bit. So where i need to specify 168 bit which i want like i asked in my previous post also, do i need to generate three keys for 168 ?
Ulf Dittmer
Marshal

Joined: Mar 22, 2005
Posts: 41149
    
  45
I think the default is 168 bit (I'm not sure how one would specify to use 112 bits, though). The easiest way to find out for sure is probably to run that code, and check the size of the file being created.
Ulf Dittmer
Marshal

Joined: Mar 22, 2005
Posts: 41149
    
  45
OK, I did a bit of searching, and the default is indeed 168 bits. If you want 112 bits, you'd call the KeyGenerator's init(int) method with a value of 112.

Looking at the file size is apparently not useful, as it might be identical for all DES variants, with the difference being that the first 8 bytes might be the same as the last 8 bytes for 112bit-DES.
james edwin
Ranch Hand

Joined: Nov 22, 2001
Posts: 393
Thanks for the searching and the reply.

So my understanding that " i need to generate three keys with 56 bits and do the following for encryption " is not correct..right... So will triple desede will internally do the following stuff for us ?

ciphertext = EK3(DK2(EK1(plaintext)))
I.e., DES encrypt with Key 1, DES decrypt with Key 2, then DES encrypt with Key3.
E -encrypt and D - descrypt

Decryption is the reverse:

plaintext = DK1(EK2(DK3(ciphertext)))
I.e., decrypt with K3, encrypt with K2, then decrypt with K1.


Ulf Dittmer
Marshal

Joined: Mar 22, 2005
Posts: 41149
    
  45
JCE will do it for you if you use it like that sample code shows. You'll have to supply your own 168 bits if you don't want to use some random key, but instead want to use your own key.
james edwin
Ranch Hand

Joined: Nov 22, 2001
Posts: 393
Thanks for the information. So life will be easy i will depend on JCE only and let them generate key for my application. If its 168 bit it's fine with me. Can i some how verify it's 168 bit or not ?

I dont want to generate my own keys, as i new to security and i dont want to mess right now. May be sometime later once i get some more hands on i try the same.

Ulf Dittmer
Marshal

Joined: Mar 22, 2005
Posts: 41149
    
  45
SecretKey has the getEncoded method which will return the raw bytes of the key. But as I understand it, the length will always be 168 bit, never 112. If the first 8 bytes are identical to the last 8 bytes, then the key size is really 112 bit. (And if the first 8 bytes are identical to the second 8 bytes are identical to the final 8 bytes, then you have in effect standard 56bit DES.)

Supplying your own key is useful if -instead of using a random key that a human being can't remember- you want to use a passphrase. In that case you'd construct a DESedeKeySpec object with the raw key data, which you can use as a SecretKey.
james edwin
Ranch Hand

Joined: Nov 22, 2001
Posts: 393
When i printed the byte length (byte[] getEncoded())..i get the size 24. so this should be 168 or 24....I am little confused now

Is this statement is true ...."Single DES the key is fixed size of 8 bytes. For Triple DES it is 24"...may be that's why i am getting the length of array as 24.

I changed the encryption from "DESede" to "DES" and got the result 8 back. which validates this statement ("Single DES the key is fixed size of 8 bytes. For Triple DES it is 24"...)

But after getting byte[] back from getEncoded, still how do i verify it's 168 bit. or getting length 24 ensure that it's 168 bit.
(let do some math here 24 *7= 168, but one 1 byte we have 8 bits which make 24 * 8 = 192..isn't ?..)...

Below URL explains that only 7 bit are used.

URL

so if we are getting size of 24 bytes back, then 24 * 7 = 168 which makes sense to me.

Is there is any other way to verify that's key is 168 bit.
Ulf Dittmer
Marshal

Joined: Mar 22, 2005
Posts: 41149
    
  45
I'm not sure now what else you're looking for. You've verified that the key is 24 bytes (=192 bits), and you've found the explanation why JCE only uses 7 out of every 8 bits for DES, which makes an 192 bit JCE key a 192 * 7 / 8 = 168 bit DES key. Is that not exactly what you're looking for?

As I've mentioned before, you still need to look inside of the key to verify that the 168 bit 3DES key is not actually a 2DES or DES key.
greg stark
Ranch Hand

Joined: Aug 10, 2006
Posts: 220
length of 24 means it is 168-bits internally. In ancient times, the original DES key formats specified that DES keys were to be carried in in 8 bytes, with one bit in each byte reserved for error detection. Thus only 7 bits of each byte are significant: 7*8 = 56. Triple DES keys carried this notion forward, 24 bytes, but only 7-bits are significant in each byte: 24*7 = 168.


Nice to meet you.
james edwin
Ranch Hand

Joined: Nov 22, 2001
Posts: 393
Thanks for the quick reply and i really Appreciate that.

I was just curious to know is there is any other way to verify the key. But as i understand 24 bytes is also a way to verifying the same.

Once again thanks for your help.
greg stark
Ranch Hand

Joined: Aug 10, 2006
Posts: 220
I was just curious to know is there is any other way to verify the key.

I do not understand what you mean by verify in this context. Every possible 24 byte key is accepted by the SunJCE DESede implementation. It dutifully ignores the low-order bit of each byte, so you can put anything you want there.
Pat Farrell
Rancher

Joined: Aug 11, 2007
Posts: 4646
    
    5

Are you sure you want to use 3DES? DES has been considered obsolete for years. Modern implementations should use AES with suitable key lengths.

The only reason that I can see using 3DES today is to connect to some legacy system. In that case, you should be able to get test vectors and keys from the legacy system.

DES is a pain to use, as the naive implementation will use 48 bits of the keys, not 56, and Java really doesn't support the unsigned bytes that you need. So it takes some effort to make it all work properly.

Does your 3DES spec say it wants E(E(E(m,k))) or E(D(E(m,k)))

Makes a big difference.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: 168 bit 3DES encryption and decryption....
 
Similar Threads
Triple DES encrytpion and decryption using 256 bit and 512 bit
Java Encrypt and decrypt using Open SSL
Triple DES with Cipher Block Chaining - Beginner que
Need Fast and Simple Text Encryption
Difference between DES and Blowfish algorithm