Triple Des decryption with hex key different values

[Jimmy Ice]

Hi guys,

i am new to encryption/decryption and i have to decrypt a hex value using a specific hex key. I found some decryption samples in java but my problems are that when i use a self made encryption the decryption is working correctly, but when i encrypt the value online, different websites give different values(ecb mode used) and of course my decryption gives wrong output for these encrypted values.

My questions are:

1) I know that the provider of the encrypted value will encrypt it with triple des, ecb mode with specific given hex key. Are there a lot of different ways to encrypt values with 3des so i need to know the encryption method to decrypt it, or if you have key and mode there is only one possible encrypted output?

2)I know that there as a difference in encryption with hex key and normal key, but does it matter that my encrypted value will be hex value or it will be treated as a string?

3)If there is only one way to decrypt hex values with 3des ecb using hex key and given key, is there a sample java code to do this?

Thanks!

[Campbell Ritchie]

Welcome to the Ranch

I shall try moving you to our security forum because that question is too difficult tor “beginning”.

[Stephan van Hulst]

Hi Jimmy.

You don't encrypt/decrypt strings. Encryption works with binary data. If you need to decrypt a hex string, you need to decode it first. After decoding, you decrypt the binary data. Finally, you encode the binary data to a string again. The same goes for a key. Keys are binary data, you need to decode the string first.

Furthermore, you need to know what padding scheme is used to create blocks and keys of the correct size for the algorithm. Just knowing the algorithm and the cipher mode isn't enough.

This is what it should look like roughly:

import javax.crypto.*;
import javax.crypto.spec.*;

final class HexDecrypter {

  private final Cipher cipher;
  private final Key key;
  
  HexDecrypter(String algorithm, String hexKey) throws NoSuchAlgorithmException, NoSuchPaddingException, InvalidKeyException {
    // TODO
  }

  String decrypt(String hex) throws IllegalBlockSizeException, BadPaddingException {
    byte[] cipherText = decode(hex);
    byte[] message = decrypt(cipherText);
    return encode(message);
  }

  ...

}

[Jimmy Ice]

Stephan van Hulst wrote:Hi Jimmy.

You don't encrypt/decrypt strings. Encryption works with binary data. If you need to decrypt a hex string, you need to decode it first. After decoding, you decrypt the binary data. Finally, you encode the binary data to a string again. The same goes for a key. Keys are binary data, you need to decode the string first.

Furthermore, you need to know what padding scheme is used to create blocks and keys of the correct size for the algorithm. Just knowing the algorithm and the cipher mode isn't enough.

This is what it should look like roughly:

import javax.crypto.*;
import javax.crypto.spec.*;

final class HexDecrypter {

  private final Cipher cipher;
  private final Key key;
  
  HexDecrypter(String algorithm, String hexKey) throws NoSuchAlgorithmException, NoSuchPaddingException, InvalidKeyException {
    // TODO
  }

  String decrypt(String hex) throws IllegalBlockSizeException, BadPaddingException {
    byte[] cipherText = decode(hex);
    byte[] message = decrypt(cipherText);
    return encode(message);
  }

  ...

}

Thanks for the answer Stephan. I know they encryption key that will be used, so i need to know only padding scheme right? Let's say that PKCS5Padding is going to be used. Does this code look right?

final byte[] keyBytes = hex2byte(hexKey);
	    	for (int j = 0, k = 16; j < 8;) {
	    		keyBytes[k++] = keyBytes[j++];
	    	}

	    	final SecretKey key = new SecretKeySpec(keyBytes, "DESede");
	    	final Cipher decipher = Cipher.getInstance("DESede/ECB/PKCS5Padding");
	    	decipher.init(Cipher.DECRYPT_MODE, key);

	    	final byte[] encData = new sun.misc.BASE64Decoder().decodeBuffer(hexToDecrypt);
	    	final byte[] plainText = decipher.doFinal(encData);

	    	return new String(plainText, "UTF-8");
	    }

[Stephan van Hulst]

Not really, I'm afraid. It looks like you're applying the padding scheme to the key material. This is a bad idea, because it's easy to get wrong, and the key probably already has the correct size for the algorithm.

You're also decoding the hex string using Base 64. Hex is not base 64.

Finally, I hope this is some sort of exercise, because you shouldn't be using cryptographic primitives, and certainly not an outdated one like triple-DES. For proper encryption, use AEAD.

[Stephan van Hulst]

Do you have an example of the key and encrypted message? Do you know what message was encrypted?

[Stephan van Hulst]

My apologies, my example showed operations working with Strings. Keys and secret messages should never be stored as Strings. The hexKey and hex parameters should be of type char[], and decrypt() should return char[].

The reason is that char arrays can be wiped after usage, while Strings are very hard to remove from memory.

[Jimmy Ice]

Stephan van Hulst wrote:Do you have an example of the key and encrypted message? Do you know what message was encrypted?

Sample hex key: 3402711110CA93C96A2DCE4E3402711110CA93C96A2DCE4EA
Message that will be encrypted and then decrypted by me: 32 hex characters e.g FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF

If i the encrypt with no padding and i change to hex.decode will it be ok?

Thanks for the help Stephan you are very helpful.

[Stephan van Hulst]

PKCS#5 requires a multiple of 8 bytes, so the key isn't valid using that padding scheme. As a matter of fact, it can't unambiguously be decoded to a byte array at all, because the number of bytes is uneven. Is the final 'A' at the end a mistake?

[Jimmy Ice]

Stephan van Hulst wrote:PKCS#5 requires a multiple of 8 bytes, so the key isn't valid using that padding scheme. As a matter of fact, it can't unambiguously be decoded to a byte array at all, because the number of bytes is uneven. Is the final 'A' at the end a mistake?

Yes the final A is a mistake

[Stephan van Hulst]

I encrypt to:

"97dc8adaa616f58c97dc8adaa616f58c"

without padding and:

"97dc8adaa616f58c97dc8adaa616f58cacbb931e9406b125"

with padding.

[Stephan van Hulst]

Notice how in this example you can immediately see the disadvantage of ECB mode? The encrypted string contains "97dc8adaa616f58c" twice, which is a BIG no no in cryptography.

[Jimmy Ice]

I've changed my code and replaced Base64 decoding with:

final byte[] encData = Hex.decodeHex(message.toCharArray());
final byte[] plainText = decipher.doFinal(encData);

return new String(plainText, "UTF-8");

But now i get some some weird characters when i print out the result..

[Stephan van Hulst]

Because your encoding the binary data to UTF-8, and the original message probably wasn't UTF-8.

Are you trying to decrypt some message given to you, or are you trying to reverse your own encryption process?

[Jimmy Ice]

Stephan van Hulst wrote:Because your encoding the binary data to UTF-8, and the original message probably wasn't UTF-8.

Are you trying to decrypt some message given to you, or are you trying to reverse your own encryption process?

I've just replaced my "message" variable with the encrypted hex you gave me "97dc8adaa616f58c97dc8adaa616f58c". (I use ECB,NoPadding) Sorry if the questions are stupid but it's the first time i am doing something like this

[Jimmy Ice]

I don't use my own encryption. I will get an encrypted string value and decrypt it with my method. That's why i used your encryption result..

[Stephan van Hulst]

I understand.

The reason you're getting garbage with UTF-8 is because I interpreted "FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF" as hexadecimal, not as UTF-8. Again, hexadecimal is an encoding, and it's different from UTF-8, ASCII, or Base64.

Do you know what an encoding is? Please take a look at this article: http://www.joelonsoftware.com/articles/Unicode.html

First I decoded the hexadecimal to a binary message, encrypted it, and encoded it to hexadecimal again. In order to get the original message, you have to reverse this process by decoding the hexadecimal, decrypting the message, and then encoding it to hexadecimal again, not UTF-8.

[Jimmy Ice]

Stephan van Hulst wrote:I understand.

The reason you're getting garbage with UTF-8 is because I interpreted "FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF" as hexadecimal, not as UTF-8. Again, hexadecimal is an encoding, and it's different from UTF-8, ASCII, or Base64.

Do you know what an encoding is? Please take a look at this article: http://www.joelonsoftware.com/articles/Unicode.html

First I decoded the hexadecimal to a binary message, encrypted it, and encoded it to hexadecimal again. In order to get the original message, you have to reverse this process by decoding the hexadecimal, decrypting the message, and then encoding it to hexadecimal again, not UTF-8.

Thank you very much Stephan Now it works fine after doing correct decoding and encoding and deleting the line:

for (int j = 0, k = 16; j < 8;) 
{
    keyBytes[k++] = keyBytes[j++];
}

Now i guess they have to provide me 48 hex byte string encrypted with ECB/Nopadding for my decryption to work.

[Stephan van Hulst]

Good job. Can you show your full solution?

[Jimmy Ice]

Stephan van Hulst wrote:Good job. Can you show your full solution?

	    	final byte[] keyBytes = hex2byte(hexKey);
	    	final SecretKey key = new SecretKeySpec(keyBytes, "DESede");
	    	final Cipher decipher = Cipher.getInstance("DESede/ECB/NoPadding");
	    	decipher.init(Cipher.DECRYPT_MODE, key);

	    	final byte[] encData = hex2byte(valueToDecrypt);
	    	final byte[] plainText = decipher.doFinal(encData);
	    	String hexValue = byte2hex(plainText);
	    	return hexValue;

[Stephan van Hulst]

Alright. Please keep in mind that you should never use this for any form of proper encryption. ECB is a horrible broken block cipher mode, and encryption and decryption should not be done without authentication, so it's best to use an algorithm like AES-GCM.