TripleDES Mcrypt issue

[RiceBurner]

Anyone dealt with mcrypt and tripleDES before??

I'm having an issue where I'm trying to decrypt a cookie string that was created with TripleDES by another host (an ASP site I think). (I'm developing a sub-domain site)

I have the Key, it's a 16 character word.
The process that has been used is that the key is converted from ASCII to HEX before being used in the encrypt process.

The process of convertion means that the Key is now 32 characters long.

Unfortunately, it appears that a 32 character Key is too long for the MCRYPT_TRIPLEDES algorythm. I get an error message telling me so. Having done some research I've found that mcrypt_decrypt() 's maximum key length for MCRYPT_TRIPLEDES is 24 characters. Indeed, when I shorten the key to 24 characters I get the same result, but shorten to anything else and the output changes. So I assume the function just automatically uses the first 24 characters supplied to it as the key.

So - what I want to know is:
Does the TripleDES algorythm have this limitation across all coding systems?
If so - how on earth has this 16character Key been successfully used by other coders (which apparantly is the case - albeit non php)
How else can I attemtp to convert this 16 character Key into a 24 character string that wil match the other incarnations??

I seriously hope that someone can help, as I'm getting to the hair-tearing stage now!! :queasy::queasy:

[laserlight]

RiceBurner wrote:

Does the TripleDES algorythm have this limitation across all coding systems?

Search the Web for TripleDES to find out more about the algorithm. In particular, read up about its key size(s).

[RiceBurner]

laserlight;10980932 wrote:

Search the Web for TripleDES to find out more about the algorithm. In particular, read up about its key size(s).

Yes, have done that. The key size is 198bits, or 24 characters. (8bits per character, 198 / 8 = 24. in fact the algorythm ignores the parity bit in each byte/character and so references 168bits, although only 112 are effective - according to my research).

The issue I have is that the 16character key is hex-encoded prior to being used, this creates a 32 character key to be used. Obviously this is too long.

In PHP if a key greater thatn 24 characters is passed to mcrypt_decrypt(), the function throws a warning, and only uses the first 24 characters.

In .NET, the decrypt has been done successfully (as far as I am aware, this cookie is used on other websites, although no php sites), so I can only assume that .NETs implementation of the TripleDES algorythm is different in someway??

[Weedpacket]

RiceBurner wrote:

although only 112 are effective - according to my research).

Fewer than that in your implementation, because the hex-encoding. Each character codes for eight bits in which the first is always zero , the third and fourth are always equal to each other, and opposite to the second... and of course the pattern repeats throughout the key.

Does the TripleDES algorythm have this limitation across all coding systems?

There's only one TripleDES algorithm (specified in FIPS 46-3, but see also SP 800-67) - if two implementations produce two different results then at least one of them is wrong (which is not to say that there aren't different modes of operation - but using the same algorithm in the same mode should produce the same results even in different implementations).

If so - how on earth has this 16character Key been successfully used by other coders (which apparantly is the case - albeit non php)

I again refer to FIPS 46-3. The first keying option is to take twenty-four bytes of key are taken (the rest are discarded), and split them into three independent sixty-four-bit keys - one for each round of DES. The second option is to take sixteen bytes and split them into two independent 64-bit keys, and make the third a duplicate of the first - to put it another way, pad the sixteen bytes out to twenty four by repeating the first eight.

[RiceBurner]

Weedpacket;10980981 wrote:

Fewer than that in your implementation, because the hex-encoding. Each character codes for eight bits in which the first is always zero , the third and fourth are always equal to each other, and opposite to the second... and of course the pattern repeats throughout the key.

There's only one TripleDES algorithm (specified in FIPS 46-3, but see also SP 800-67) - if two implementations produce two different results then at least one of them is wrong (which is not to say that there aren't different modes of operation - but using the same algorithm in the same mode should produce the same results even in different implementations).

I again refer to FIPS 46-3. The first keying option is to take twenty-four bytes of key are taken (the rest are discarded), and split them into three independent sixty-four-bit keys - one for each round of DES. The second option is to take sixteen bytes and split them into two independent 64-bit keys, and make the third a duplicate of the first - to put it another way, pad the sixteen bytes out to twenty four by repeating the first eight.

ok, that's very informative stuff - but I'm not sure how it helps me when I've been supplied a key by the client (16character ASCII), and then told "this needs to be hex before use". I do that, and php throws back that the key is too long. 😕

I am befuddled. 🙁

[RiceBurner]

RiceBurner;10980985 wrote:

ok, that's very informative stuff - but I'm not sure how it helps me when I've been supplied a key by the client (16character ASCII), and then told "this needs to be hex before use". I do that, and php throws back that the key is too long. 😕

I am befuddled. 🙁

and obviously don't understand the differences between characters, bytes and bits (although I know that a byte consists of 8 bits), in this context.... 😕

(by the by - why can't I edit my posts on this forum?)

[RiceBurner]

Ok - more info on this .....

I'm now attempting to replicate what's going on at the encryption end.... so I'm testing php's encrypt and decrypt system.

The client has pointed me at a encrypt/decrypt page on the web : http://www.riscure.com/tech-corner/online-crypto-tools/des.html. This is the site they use to double check their encryption/decryption is working ok.

So, with "Radix" set to ASCII, I put in a string "This is a test string", and a key "BlahBlahBlahBlah".
I alter Radix to HEX and get "546869732069732061207465737420737472696E67030303" (string), and "426C6168426C6168426C6168426C6168" (key)/
Then I press the "T-DES encrypt" button, and get a HEX output of : "08E1E0287E389F0D1D8B2F3633271CD6FC419926411EFE2B" .

Trying to replicate this in PHP I do this:

$string = "This is a test string";
$string = pkcs7_pad($string, mcrypt_get_block_size(MCRYPT_TRIPLEDES,MCRYPT_MODE_ECB) );
$string = bin2hex($string);
$string = strtoupper($string);

$key = "BlahBlahBlahBlah";
$key = strtoupper(bin2hex($key));

$iv_size = mcrypt_get_iv_size(MCRYPT_TRIPLEDES,MCRYPT_MODE_ECB);
$iv = mcrypt_create_iv( $iv_size , MCRYPT_RAND );

$encrypted = mcrypt_encrypt( MCRYPT_TRIPLEDES , $key , $string , MCRYPT_MODE_ECB , $iv );

(The ECB mode doesn't actually use the initialisation vector, as far as I can make out, but not putting it into the function call throws a warning).

The result output is : " �S�&#65533😉x(m�#y}���,A�t�/*sz�oYɘ���#28�Uo�٨� "

passing the above through bin2hex() gives : " 06fc5389ec2978286dea23797dd50ea7cc2c41f41e749c2f2a0f737acc6f59c998d4cbee23323886556ff39ad9a8df05 "

What am I doing wrong/not understanding here?? I've tried everything I can think of to mimic what's being done in the Riscure page, but can't get the same results - which I think is why I can't get the decryption to work.... 🙁

[Weedpacket]

I'm afraid I don't understand what "needs to be hex before use" is supposed to mean - but have you just tried the key as given? I don't see why converting the string into something like "426C6168426C6168426C6168426C6168", which is after all an ASCII string that happens to use a limited number of characters - especially if doing so makes the key too long.

Usually a hexadecimal representation is used for cosmetic purposes - because it's difficult for humans to read or write a string like "�S�&#65533😉x(m�#y}���,A�t�/*sz�oYɘ���#28�Uo�٨� "; I'd only expect it to appear as part of the process if it was used as a formatting aid while storing or transmitting the key (because "06fc5389ec297828" causes fewer complications than "�S�&#65533😉x(" might).

[RiceBurner]

Weedpacket;10981087 wrote:

I'm afraid I don't understand what "needs to be hex before use" is supposed to mean - but have you just tried the key as given? I don't see why converting the string into something like "426C6168426C6168426C6168426C6168", which is after all an ASCII string that happens to use a limited number of characters - especially if doing so makes the key too long.

Usually a hexadecimal representation is used for cosmetic purposes - because it's difficult for humans to read or write a string like "�S�&#65533😉x(m�#y}���,A�t�/*sz�oYɘ���#28�Uo�٨� "; I'd only expect it to appear as part of the process if it was used as a formatting aid while storing or transmitting the key (because "06fc5389ec297828" causes fewer complications than "�S�&#65533😉x(" might).

I've tried it every which way I can think of! 🙁

The instructions I've been given in order to test the decrypt are to use that link in the post above, enter the key in ASCII, then convert all the fields to Hex before hitting the "Decrypt" key.

[Weedpacket]

RiceBurner wrote:

The instructions I've been given in order to test the decrypt are to use that link in the post above, enter the key in ASCII, then convert all the fields to Hex before hitting the "Decrypt" key.

All that conversion does on that page is change the way the fields are represented: it's purely cosmetic. All three representations are of the same sequence of bytes. You could hit the "Decrypt" key and then change the representation if you felt like it.

But ignore the smelly red herring that is that page, because you won't be using it for real, will you?

Does the cookie string have to be converted from hex to binary? Is it encoded in some other way? What do the key and cookie actually look like? Is it something like [font=monospace]MyPassw0rd[/font] or [font=monospace]34ed90ab44[/font] or [font=monospace]sz�oYɘ�[/font] or [font=monospace]cGFzc3dvcmQ=[/font]?

[RiceBurner]

Weedpacket;10981333 wrote:

All that conversion does on that page is change the way the fields are represented: it's purely cosmetic. All three representations are of the same sequence of bytes. You could hit the "Decrypt" key and then change the representation if you felt like it.

But ignore the smelly red herring that is that page, because you won't be using it for real, will you?

Does the cookie string have to be converted from hex to binary? Is it encoded in some other way? What do the key and cookie actually look like? Is it something like [font=monospace]MyPassw0rd[/font] or [font=monospace]34ed90ab44[/font] or [font=monospace]sz�oYɘ�[/font] or [font=monospace]cGFzc3dvcmQ=[/font]?

The key is a 16 character alphanumeric string,

the cookie string is a 64 character alphanumeric string

I've tried padding the regular string (both regular php style and with .Net's "pkcs7" system (found after much researching), using it with and without encoding to hex, etc etc, nothing seems to be correct, all I ever get out of the decrypt is [font=monospace]sz�oYɘ�[/font] kind of gibberish.

[Weedpacket]

Well, the cookie would need to be converted to a binary representation (so that it looks like [font=monospace]�S�&#65533😉x(m�#y}���,A�t�/*sz�oYɘ���#28�Uo�٨�[/font]) before decrypting.