Re: How good an encryption algorithm is this?

From: Igor Tandetnik (itandetnik_at_mvps.org)
Date: 11/22/04 

Date: Mon, 22 Nov 2004 18:53:11 -0500

"Bonj" <benjtaylor at hotpop d0t com> wrote in message
news:OuHf3lM0EHA.2716@TK2MSFTNGP14.phx.gbl
> My (unsuccessful) attempt to use the Win32 API is as follows:
> BOOL GetData(_TCHAR* datain, long lendatain)
> {
> DWORD bytelen = (lendatain + 10) * sizeof(_TCHAR), databack = 0,
> bytesback = 0;
> BYTE* bData = new BYTE[bytelen];
>
> memcpy(bData, datain, bytelen);

Note that you are reading 10*sizeof(TCHAR) bytes past the end of datain
buffer here. In the worst case, your program can crash. If it does not,
you will have garbage at the end of bData.

> bSuccess &= CryptEncrypt(hCryptKey, hCryptHash, TRUE, 0, bData,
> &bytesback, bytelen);

Here's your problem. bytesback is an [in, out] parameter. On input, it's
the number of bytes to encrypt. On output, it's the number of encrypted
bytes successfully written. You are passing 0 on input, asking to
encrypt zero bytes.

Oh, and you don't need to pass hCryptHash. It does not do what you seem
to think it does. It's harmless, but makes the API do the unnecessary
work.

> memcpy(cryptdata, bData, bytesback);
> _tprintf(_T("The encrypted data is \"%s\"\n"), cryptdata);

Encrypted data may very well contain NUL bytes inside, or it may not
contain any, not even at the end. Your printf output will either be
shortened, or will result in a buffer overrun and possibly a crash.
Encryption produces a binary byte stream, not a nice NUL-terminated
string.

> bSuccess &= CryptDecrypt(hCryptKey, hCryptHash, TRUE, 0, bData,
> &bytesback);

Again, you don't need to pass hCryptHash.

> memcpy(decryptdata, bData, bytesback);
> databack = (DWORD)(bytelen / sizeof(_TCHAR));

Note that you never change bytelen after it was initially calculated
from lendatain. You can simply write databack = lendatain + 10 (what is
this +10 doing here anyway? )

> _tprintf(_T("The decrypted data is \"%s\"\n"), decryptdata);

When encrypting, you didn't include the terminating NUL character. So
decrypted data is not NUL-terminated either (if only accidentally). 

-- 
With best wishes,
    Igor Tandetnik
With sufficient thrust, pigs fly just fine. However, this is not 
necessarily a good idea. It is hard to be sure where they are going to 
land, and it could be dangerous sitting under them as they fly 
overhead. -- RFC 1925

Relevant Pages

  • Re: How good an encryption algorithm is this?
    ... Note that you are reading 10*sizeofbytes past the end of datain ... the number of bytes to encrypt. ... or will result in a buffer overrun and possibly a crash. ... you didn't include the terminating NUL character. ...
    (microsoft.public.vc.language)
  • Re: Cryptographic Exception - Bad Data (DESCryptoServiceProvider)
    ... Encrypt the buffer (with an 8 byte DES key) and store the result in the ... the crypto stream is doing something that I do not want it to do ...
    (microsoft.public.dotnet.framework)
  • 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)