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.
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.)
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.
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.
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.
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.
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 ?..)...
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.
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.
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.
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.
Beware the other head of science - it bites! Nibble on this message: