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


Win a copy of Java 8 in Action this week in the Java 8 forum!
JavaRanch » Java Forums » Java » Java in General
Bookmark "3DES output size" Watch "3DES output size" New topic
Author

3DES output size

Andre Chevchenko
Greenhorn

Joined: Jan 09, 2013
Posts: 3
I want to encrypt data HEX 16 characters + HEX 16 characters KEY with 3DES algorithm and expect encrypted out put HEX 16 characters, has any one suggest me?

My code gen more 16 characters.


//------------------------------------------------------------


//------------------------------------------------------------
Ivan Jozsef Balazs
Rancher

Joined: May 22, 2012
Posts: 865
    
    5
You seem to apply convertToHex.
Campbell Ritchie
Sheriff

Joined: Oct 13, 2005
Posts: 36575
    
  16
Welcome to the Ranch
I am afraid that question is too difficult for us “beginners”, so I shall move it. You should always use the code button; I have applied it to your code and you can see how much better it looks.
Andre Chevchenko
Greenhorn

Joined: Jan 09, 2013
Posts: 3
How to fix length of out put character?
Richard Tookey
Ranch Hand

Joined: Aug 27, 2012
Posts: 971
    
  10

For 3DES using PKCS5Padding the encrypted length for N hex characters is calculated along the lines of

1) Converting the cleartext characters to bytes. Since you decode the Hex cleartext characters using utf-8 and don't Hex decode them your N hex characters will convert to N bytes and not N/2. For your example this will be 16 bytes.

2) The PKCS5Padding will add between 1 and 8 padding bytes so the cleartext length after padding will be ((N+8)/8)*8 bytes (integer division that ignores the remainder). For your example this will result in 24 bytes.

3) The ciphertext length will be the same as the padded cleartext length i.e. ((N+8)/8)*8 bytes.

4) Hex encoding of the raw ciphertext will produce 2 characters for every one byte of ciphertext so you will end up with 2*((N+8)/8)*8 characters. For your 16 hex character cleartext example this will result in 48 characters.

It seems to me that before encrypting you should first hex decode the hex bytes of the cleartext. This will then result in just 32 Hex characters of ciphertext.

You can get a further saving if you Base64 encode the ciphertext rather than Hex encode it and an even bigger saving use ASCII85 encoding.

Note - it is normally better to leave ciphertext as bytes and not turn them into text at all. Do not even think about just converting them to a String without some form of encoding; String is not a suitable container for binary data and raw ciphertext is most definitely binary data.

Note 1 - you use a fixed IV of 8 zero bytes. This has security implications since it allows an observer to tell whether or not two ciphertext have the same first 8 bytes of cleartext. To get round this it is normal to use a random IV and either include the IV as a prefix to the ciphertext or store it separately.

Andre Chevchenko
Greenhorn

Joined: Jan 09, 2013
Posts: 3
Thanks Richard.

But my cleartext is Hex format (i.e. "015674FFAAAEBAFC") and I expect to get ciphertext in Hex format 16 characters for sending to another system.

What I should to do?
Richard Tookey
Ranch Hand

Joined: Aug 27, 2012
Posts: 971
    
  10

Andre Chevchenko wrote:
But my cleartext is Hex format (i.e. "015674FFAAAEBAFC") and I expect to get ciphertext in Hex format 16 characters for sending to another system.

What I should to do?


Who has imposed this constraint on the ciphertext and why is there this constraint on the ciphertext? Are you trying to match an existing system? If so you must find out exactly what the existing system is doing or you are just wasting your time.

The obvious approach to meet your requirements is :-

1) Hex decode the Hex encoded cleartext to get 8 bytes.
2) 3DES encrypt the resulting 8 bytes usng ECB block mode with no padding.
3) Hex encode the resulting 8 bytes to get your 16 hex characters of ciphertext.

Note - ECB is used because there is no point in using CBC for a single block of data when you are just using an IV of all zeros; you would get the same ciphertext anyway. Padding is not used because you always have exactly one block of raw cleartext so no padding is needed.





 
jQuery in Action, 2nd edition
 
subject: 3DES output size
 
Similar Threads
Encrypting Strings
Characters jumbled pls help
Please explain to me a line of code in a method that converts bytes to Hex-Values?
AES decryption problem
AES decryption - InvalidKeyException: Parameters missing