• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

168 bit 3DES encryption and decryption....

 
Ranch Hand
Posts: 393
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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

 
Rancher
Posts: 43081
77
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.)
 
james edwin
Ranch Hand
Posts: 393
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thanks i will have a look.
 
james edwin
Ranch Hand
Posts: 393
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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



 
Ranch Hand
Posts: 96
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 393
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Rancher
Posts: 43081
77
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 393
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Rancher
Posts: 43081
77
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Rancher
Posts: 43081
77
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 393
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Rancher
Posts: 43081
77
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 393
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Rancher
Posts: 43081
77
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 393
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Rancher
Posts: 43081
77
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
Ranch Hand
Posts: 220
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
james edwin
Ranch Hand
Posts: 393
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 220
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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.
 
Rancher
Posts: 4803
7
Mac OS X VI Editor Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
reply
    Bookmark Topic Watch Topic
  • New Topic