File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
The moose likes Security and the fly likes Triple DES with Cipher Block Chaining - Beginner que Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Engineering » Security
Bookmark "Triple DES with Cipher Block Chaining - Beginner que" Watch "Triple DES with Cipher Block Chaining - Beginner que" New topic
Author

Triple DES with Cipher Block Chaining - Beginner que

Nitin Dubey
Ranch Hand

Joined: Oct 30, 2000
Posts: 126

I have googled for this information but could not get specific example using 3 different keys and initialization vector. Can anybody help me pointing to a good java example implemented?
Ulf Dittmer
Marshal

Joined: Mar 22, 2005
Posts: 39548
    
  27
The http://faq.javaranch.com/java/SecurityFaq links to a complete example of encryption/decryption with JCE. You'll just need to adjust the Cipher and SecretKeyFactory instances as appropriate for your needs (e.g. "DESede" for TripleDES).

I'm not sure what you mean by "3 different keys" - TripleDES uses a single key.


Ping & DNS - updated with new look and Ping home screen widget
greg stark
Ranch Hand

Joined: Aug 10, 2006
Posts: 220
Ulf -- the OP is probably referring to the fact that Triple DES -- or "DESede" is actually composed of three instances of single DES, each with its own independent 56-bit DES key. Conceptually it is easier to think of this as just one key of size (3*56)=168 bits, which is how Java and every other reasonable API works. In fact, they usually use 64 bits to store the 56 bits DES key, so the keysize becomes (3*64)=192 bits = 24 bytes, although only 168 of the bits are actually used in the Triple-DES algorithm.


Nice to meet you.
Nitin Dubey
Ranch Hand

Joined: Oct 30, 2000
Posts: 126

Thanks Ulf and Greg. It really helped. I believe I had to change "DES" to "DESede" only but unfortunately it did not work for me. Following are some doubts

#1. What is the difference between the following two codes for generating keys?
This one worked for me:


and (the one that did not work)



Exception:
Exception in thread "main" java.security.spec.InvalidKeySpecException: Inappropriate key specification
at com.sun.crypto.provider.DESedeKeyFactory.engineGenerateSecret(DashoA12275)
at javax.crypto.SecretKeyFactory.generateSecret(DashoA12275)
at com.sungard.crypto.tripledes.example3.TestCipherTripleDES.main(TestCipherTripleDES.java:39)

Do I have to get some implementation of this algo? OR the key specified is wrong?

#2. I have to use Initialization vector with Triple DES. The vector will be in the form of a String like this "111222333AAADDFF" (exact length). I did modify some code like this but it is throwing an exception related to byte length:


Exception:
Exception in thread "main" java.security.InvalidAlgorithmParameterException: Wrong IV length: must be 8 bytes long
at com.sun.crypto.provider.SunJCE_h.a(DashoA12275)
at com.sun.crypto.provider.DESedeCipher.engineInit(DashoA12275)
at javax.crypto.Cipher.a(DashoA12275)
at javax.crypto.Cipher.a(DashoA12275)
at javax.crypto.Cipher.init(DashoA12275)
at javax.crypto.Cipher.init(DashoA12275)
at com.sungard.crypto.tripledes.example2.SimpleTripleDESVariant.main(SimpleTripleDESVariant.java:32)

It looks obvious that the length of init vector is more than 8 bytes. Just want to be sure that my understanding is correct or not.
Ulf Dittmer
Marshal

Joined: Mar 22, 2005
Posts: 39548
    
  27
Greg, thanks for the clarification.

the one that did not work

You're trying to use a DES key spec with Triple DES key factory. Try using a DESedeKeySpec instead.
Pat Farrell
Rancher

Joined: Aug 11, 2007
Posts: 4637
    
    5

Originally posted by greg stark:
Ulf -- the OP is probably referring to the fact that Triple DES -- or "DESede" is actually composed of three instances of single DES, each with its own independent 56-bit DES key


It depends. Some folks use 3DES with three keys, so you really are getting:


But a fair number of pro use use


which since the K2 key is used for cipher and decipher functions, it can be tested using k2 == k3

When working with DES, its critical to read the key spec carefully. They use the high order 7 bits of each key octet, not the low order 7 bits.

They the key "AaBbCcDd" is exactlty the same as the key "aabbccdd" or even
"aAbBcCdD"

You should not use ascii as a key to DES, you should run it through a hash such as SHA or MD5.

Of course, you really shouldn't be using DES anymore, you should use AES
Nicholas Jordan
Ranch Hand

Joined: Sep 17, 2006
Posts: 1282
Yes, but you have to read how exactly the 8 bytes for the init vector is obtained. Some string methods put zero's in the high-order octet. Possibly unkowingly if you are working at your skill limit and saturated mentally.

You can do this: byte[] byteArray = (byte)0x0000,(byte)0x0000,(byte)0x0000,... and get your eight byte IV, though much of things like this I find to have been done already in the libraries.

RE: Originally posted by Nitin Dubey:
It looks obvious that the length of init vector is more than 8 bytes. Just want to be sure that my understanding is correct or not.

[ May 31, 2008: Message edited by: Nicholas Jordan ]

"The differential equations that describe dynamic interactions of power generators are similar to that of the gravitational interplay among celestial bodies, which is chaotic in nature."
Pat Farrell
Rancher

Joined: Aug 11, 2007
Posts: 4637
    
    5

Originally posted by Nitin Dubey:
#2. I have to use Initialization vector with Triple DES. The vector will be in the form of a String like this "111222333AAADDFF" (exact length)


The initialization vector (IV) is an octet array, not a string array. And it really should be random, just pass it along with the cipher text to the intended recipient.

String are not good here. US ASCII string are worse.
Nicholas Jordan
Ranch Hand

Joined: Sep 17, 2006
Posts: 1282
Originally posted by Pat Farrell:
(..snip..)String are not good here. US ASCII string are worse.


Good, I counted on you following up. I did not know the nomenclature and tried to steer Nitin away from becoming swamped in Unihan - that would waste a bunch of time and the whole translation is largely out of reach in Java anyway - it is bytes ~ more correctly byte[8] that is the datatype of IV ( at least that's what it sounds like ) and if I could steer Original Poster away from Strings and so on long enough we could get Math.random() to overcome tempation to manual intervention ( such as hard-code ) to obtain an IV

I am assuming IV does not have to be crypto-grade random, and that poster will ask how to transmit raw bytes - since that may be why string datatype was chosen.
Pat Farrell
Rancher

Joined: Aug 11, 2007
Posts: 4637
    
    5

Originally posted by Nicholas Jordan:
I did not know the nomenclature

I am assuming IV does not have to be crypto-grade random, and that poster will ask how to transmit raw bytes - since that may be why string datatype was chosen.


You would not believe how long the standards folks argued over what the nomenclature should be. Most folks these days think of them as an array of C language unsigned bytes. But Java doesn't have unsigned bytes. And some very important systems in Internet history (Multics and Tenex as two big ones) did not have the concept of a fixed size byte. While IBM systems from the mid 1960s on used eight bit == a byte, in Tenex and Multics, you could have six bit bytes (handy for case insensitive file names, wonder where Windows got that idea), seven bit bytes (sufficient for US-ASCII), plus many more, 8, 9, 12, and 18 bit lengths were used when needed.

octet is a compromise, but at least it signals "8 bits" to anyone fammiliar with Romance languages.

The IV is not that important, if it was important, the specs would require it to be protected, say by RSA in the initial session key exchange). But since the DES keys need to be crypto quality, and you can call the very same generator for the IV, there is little reason not to use a good generator. In Java, java.security.SecureRandom works fine
Nicholas Jordan
Ranch Hand

Joined: Sep 17, 2006
Posts: 1282
You should go look at the CDC-7700 under the water fountain on the UT East Mall, it is right under the stairwell. I can get a jpeg of the stairwell if you want but I do not wish to ascertain if the equipment is still operational and in place: Yesterday when I purchased some fire ant bait at ( major retailer ) it became apparent that several security issues will come to the fore soon. Non of them will be the human mind as a primary pry-bar,... people can be really nice when there is money on the table.

octet is a compromise, but at least it signals "8 bits" to anyone familiar with Romance languages.

You can get romance novels by the armload at any grocery store. Without looking, can you tell me how many bits the CDC-7700 runs on? (Hint: look at the name)

You would not believe how long the standards folks argued over what the nomenclature should be.

The longer they argue, the more stable their tenure.


Most folks these days think of them as an array of C language unsigned bytes. But Java doesn't have unsigned bytes. And some very important systems in Internet history (Multics and Tenex as two big ones) did not have the concept of a fixed size byte. While IBM systems from the mid 1960s on used eight bit == a byte, in Tenex and Multics, you could have six bit bytes (handy for case insensitive file names, wonder where Windows got that idea), seven bit bytes (sufficient for US-ASCII), plus many more, 8, 9, 12, and 18 bit lengths were used when needed.
Have not heard of 9-12 & eighteen. Was that the basis of your post about the Roman Numeral conversion? I spotted that as probably advanced studies standard material and waited for something I could do something with. My hashing routine has unresolved issues that a master cryptographer nailed me on before I was ready to resolve them. All of the issues havet to do with workarounds for the stored-key problem and I had already resolved to rely on radio-active decay rather than Partial Difference Equations.

The IV is not that important, if it was important, the specs would require it to be protected, say by RSA in the initial session key exchange). But since the DES keys need to be crypto quality, and you can call the very same generator for the IV, there is little reason not to use a good generator. In Java, java.security.SecureRandom works fine

Well I did some testing and the Win::java.security.SecureRandom takes probably fifteen or twenty seconds to respond,... where I work we should be talking about fifteen or twenty milliseconds vs fiteen hundred or twenty five hundred milliseconds. I give two Sigma that the original poster finds a 'generator' that takes twenty seconds to be stronger than one that takes two seconds. Read Phil's User's Guide, I will cite the page if you need it.

That's the same place Win came up with the Pretty Printed File Name Convention. There is a disparity here, I know that you know what it is and where it is - we have already resolved that in pm's and emails.
[ June 02, 2008: Message edited by: Nicholas Jordan ]
Pat Farrell
Rancher

Joined: Aug 11, 2007
Posts: 4637
    
    5

If you need good random numbers in under 10 milliseconds, you should have a separate thread, call it the randomNumberStore(). When you run out of bits, just ask it for more.

let it run in the background, calculating numbers, and storing them in a queue. One rarely needs lots of random numbers quickly. So if you need them quick get them from the Store.

If you use a radioactive decay, you still can only get the number of bits out that it generates. So do it in background.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Triple DES with Cipher Block Chaining - Beginner que
 
Similar Threads
Running Struts Applications on JBoss
JPA hands on
A question about XML/Java Type Mappings
why overriden method can not throw Check exception?
Logging - entering method