Problem with 3DES

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Problem with 3DES

Kosch
Hi,

maybe this is a very stupid problem, but i don't have a clue:

I want to decrypt some data with a key, which is a 16byte MD5 sum over the
human readable password. As IV is a block of 0-bytes used.

            String password="Foobar";
            Digest  digest = new org.bouncycastle.crypto.digests.MD5Digest();
            byte[]  keyData = new byte[16];
            digest.update(password.getBytes(), 0, password.getBytes().length);
            digest.doFinal(keyData, 0);

            key = new SecretKeySpec(keyData, "DESede/CBC/NoPadding");
            c.init(Cipher.DECRYPT_MODE, key,
                        new IvParameterSpec(new byte[]{0,0,0,0,0,0,0,0}));

            bOut = new ByteArrayOutputStream();
            cOut = new CipherOutputStream(bOut, c);
            cOut.write(encData);
            cOut.close();

So far, but if i decrypt the message from the customer, i get in front of the
decrypted message some superfluous bytes and when the customer decrypt my
encrypted message (processed in similar way above) his decrypted results
lacks of 8 bytes in front.

Any ideas what could happen?

Thanks and kind regards,
Thomas

Reply | Threaded
Open this post in threaded view
|

Re: Problem with 3DES

David Hook-4

It sounds like an in-line IV. The first block of the message is being
used as an IV as the actual IV has to be encoded as zeros - you should
ignore the first 8 bytes when you receive a message and add 8 bytes of
random data to the front of any message you send before encrypting it.

Regards,

David

On Wed, 2005-06-29 at 08:46 +0200, Thomas Fromm wrote:

> Hi,
>
> maybe this is a very stupid problem, but i don't have a clue:
>
> I want to decrypt some data with a key, which is a 16byte MD5 sum over the
> human readable password. As IV is a block of 0-bytes used.
>
>             String password="Foobar";
>             Digest  digest = new org.bouncycastle.crypto.digests.MD5Digest();
>             byte[]  keyData = new byte[16];
>             digest.update(password.getBytes(), 0, password.getBytes().length);
>             digest.doFinal(keyData, 0);
>
>             key = new SecretKeySpec(keyData, "DESede/CBC/NoPadding");
>             c.init(Cipher.DECRYPT_MODE, key,
> new IvParameterSpec(new byte[]{0,0,0,0,0,0,0,0}));
>
>             bOut = new ByteArrayOutputStream();
>             cOut = new CipherOutputStream(bOut, c);
>             cOut.write(encData);
>             cOut.close();
>
> So far, but if i decrypt the message from the customer, i get in front of the
> decrypted message some superfluous bytes and when the customer decrypt my
> encrypted message (processed in similar way above) his decrypted results
> lacks of 8 bytes in front.
>
> Any ideas what could happen?
>
> Thanks and kind regards,
> Thomas
>


Reply | Threaded
Open this post in threaded view
|

Re: Problem with 3DES

Kosch
On Wednesday 29 June 2005 09:39, David Hook wrote:
> It sounds like an in-line IV. The first block of the message is being
> used as an IV as the actual IV has to be encoded as zeros - you should
> ignore the first 8 bytes when you receive a message and add 8 bytes of
> random data to the front of any message you send before encrypting it.

That was also my first thought, but simply ignoring the first 8 bytes from the
input solves not my problem. :-|

I got additional informations. They use (6 year old) openssl library to
encrypt the message. As pad size is 16 bytes used.

--

inubit - integrating your business and IT http://www.inubit.com
Thomas Fromm, inubit AG [hidden email]
Lützowstraße 105-106, D-10785 Berlin
Freecall 0800-go inubit, Tel +49(30)726112-135, Fax -100

Reply | Threaded
Open this post in threaded view
|

Re: Problem with 3DES

Sidney Markowitz
Thomas Fromm wrote:
> That was also my first thought, but simply ignoring the first 8 bytes from the
> input solves not my problem. :-|

David is correct, but here is the full explanation to prove it and to advise
you on what to do about it.

8 bytes is the block length of 3DES.

The fact that you successfully decrypt the customer's message with no errors
except the extra block at the beginning shows exactly what is going on, as
anything else would not allow a chaining mode like CBC to get everything right.

To decrypt in CBC, your program will take the first block of ciphertext,
decrypt it with the key, then xor it with the encryption of the IV, which is
8 bytes of 0.

That is what ends up producing your first "garbage" block. It is supposed to
produce the first plaintext block.

To get the next block, your program will take the second block of
ciphertext, decrypt it with the key, then xor it with the previous (first)
block of cyphertext.

Those steps are giving you what you expect to be the first block of plaintext.

That first block of plaintext is what you are supposed to get when you
decrypt the first block of cypher text then xor it with the encrypted IV.

Therefore that first block of ciphertext you are receiving from the customer
must be the encrypted IV. It can't be anything else or you would not be
seeing the correct first block of plaintext in that second block position.

So the customer is sending you exactly what you expect, except preceded by
one block of encrypted IV.

If you want to handle it the same way he does, either ignore that first
block, or even better decrypt it and verify that it decrypts to a block of
all zeros. That lets you check if you have the right key and the message is
in the right format before you bother decrypting the entire message, which
is one benefit of using an inline encrypted fixed IV as a prefix to CBC.

When sending a message to that customer, precede it with one block of the IV
encrypted (in ECB mode) with the key. That's what his software expects.

 -- sidney markowitz
    http://www.sidney.com

Reply | Threaded
Open this post in threaded view
|

Re: Problem with 3DES

Kosch
On Wednesday 29 June 2005 11:45, you wrote:
> Thomas Fromm wrote:
> > That was also my first thought, but simply ignoring the first 8 bytes
> > from the input solves not my problem. :-|
>
> David is correct, but here is the full explanation to prove it and to
> advise you on what to do about it.

Thanks to all.

My fault was to cut off the 8 bytes before decrypt, not after.

Sorry :-)

kind regards,
Thomas

--

inubit - integrating your business and IT http://www.inubit.com
Thomas Fromm, inubit AG [hidden email]
Lützowstraße 105-106, D-10785 Berlin
Freecall 0800-go inubit, Tel +49(30)726112-135, Fax -100