Re: Cryptographic Exception - Bad Data (DESCryptoServiceProvider)

Tech-Archive recommends: Repair Windows Errors & Optimize Windows Performance

From: Tyler (tyler_at_work.com)
Date: 02/13/04 

Date: Fri, 13 Feb 2004 09:46:28 -0500

Unfortunately, the changes you recommend do not address the problem I am
trying to work through. The changes you made accomplish the task of
encrypting and then decrypting a stream of data - assuming that I want to be
able to obtain the original result when decrypting.

However, that's not what I'm trying to do. To give you the whole picture,
what I'm trying to do is to mimic a hardware hash algorithm. I want to copy
the hardware algorithm in software so that I can output the intermediate
steps. The hash algorithm processes the stream in 8 byte pieces as follows
(assuming the stream provided has a length that is a multiple of 8 bytes):
1. Take the 1st 8 bytes as buffer
2. Encrypt the buffer (with an 8 byte DES key) and store the result in the
buffer
3. If all bytes have been processed, goto 6
4. XOR the buffer with the next 8 bytes and store the result in the buffer
5. Goto 2
6. Decrypt the buffer (with a different 8 byte DES key - this is
intentional) and store the result in the buffer
7. Encrypt the buffer (with the original DES key) and store the result in
the buffer
8. Buffer now contains the desired result

As you can see, I'm not interested in being able to decrypt the 8 bytes to
get my original 8 byte input. I simply want to decrypt 8 bytes and use the
result of that decryption. I didn't think it was really relevant to the
problem, but I hope it clarifies my intentions and explains why the code you
provided does not address my problem.

To address your 2nd point, I did not call FlushFinalBlock because the final
block of data is not relevant to the DES encryption result in which I am
interested. I take the following sample data from FIPS 113
(http://www.itl.nist.gov/fipspubs/fip113.htm) - it covers steps 1-5 I
identified above:
- key = 0123456789ABCDEF
- IV = 0000000000000000
- DATA = 3736353433323120 4E6F772069732074 68652074696D6520 666F7220
The FIPS result is: 21FB193693A16C28 6C463F0CB7167A6F 956EE891E889D91E
F1D30F6849312CA4.
The .NET result (when I change the key and input data in the sample I
provided previously) is: 21FB193693A16C28 6C463F0CB7167A6F 956EE891E889D91E
F1D30F6849312CA4 112633EB7B8D80AA.

Notice how the .NET result is 8 bytes longer - everything matches, except
for the final 8 bytes (112633EB7B8D80AA). I'm not sure why those bytes are
there, but they're not part of the DES result - do you know what they are
for? As far as I can tell, a DES encryption of a buffer that has a length
that is a multiple of 8 bytes should have an output that matches the size of
the input - the output should not be 8 bytes longer.

Obviously, the crypto stream is doing something that I do not want it to do
and I assume this is also the reason why I am having trouble decrypting
using the crypto stream. To do what I want to do, should I not use the
crypto streams and try to use the ICryptoTransform interface directly on the
data I want to transform?

Thanks, Tyler

"Jon Skeet [C# MVP]" <skeet@pobox.com> wrote in message
news:MPG.1a9611739c0a751598a10e@msnews.microsoft.com...
> Tyler <tyler@work.com> wrote:

<SNIP>

> 1) You don't need to pad the data - and the data will come back
> unpadded too. I don't know exactly how that works with the way DES
> itself is normally implemented - I suspect the padding and unpadding
> happens inside the implementation - but you don't need to do all the
> things you did. Just write the contents of atvyInput instead.

While I also thought that should be true, when I do not pad the data, the
output I get (when using FlushFinalBlock) is: 21FB193693A16C28
6C463F0CB7167A6F 956EE891E889D91E 7045EECDCDE48FF2. Notice how the last 8
bytes do not match those of the FIPS 113 and the output generated by .NET
when I pad the data (less the last 8 bytes which I questioned above)? It
must be doing something different than just padding the data with 0's to an
8 byte boundary.

> 2) You're calling Flush on the encryption, but not FlushFinalBlock.

Covered above.

> 3) (Most importantly) You're creating a different key to decrypt with -
> so it's hardly surprising that it failed!

Covered above.

Thanks, Tyler

Relevant Pages

  • Re: CryptEncrypt 3DES Encrypted Buffer Size
    ... > I'm using CryptEncrypt to encrypt a buffer that's 16 bytes in length. ... > another hardware implementation that doesn't use the CryptoAPI. ...
    (microsoft.public.platformsdk.security)
  • [PATCH 03/04] Add encryption ops to the keyctl syscall
    ... +asmlinkage long sys_keyctl(int cmd, unsigned long arg2, ... + be encrypted/signed using the key payload. ... + to encrypt or sign the data and to return the result in outputbuf. ... + userspace if the buffer pointer is not NULL. ...
    (Linux-Kernel)
  • Re: how can i encrypt/decrypt binary data?
    ... > that tries to encrypt a serialized integer. ... encrypting the buffer. ... You never close the writing cryptostream. ... it easier to use another "writing" CryptoStream, but a decrypting one, ...
    (microsoft.public.dotnet.framework)
  • Re: alternatives to streamsec ?
    ... Now...you can't pass in a memory stream directly..it is not a buffer, ... Copy the data to be encrypted to this block, encrypt, and read ... These, I believe, are replacement TMemoryStream ...
    (borland.public.delphi.thirdpartytools.general)