Re: CryptEncrypt 3DES Encrypted Buffer Size
From: Mark_Pryor (marks.pryorCHENEY_at_SHRUBverizon.net)
Date: 03/17/04
- Next message: Haggai: "Syskey API"
- Previous message: henghuei: "zero knowledge"
- In reply to: j allen: "CryptEncrypt 3DES Encrypted Buffer Size"
- Next in thread: j allen: "Re: CryptEncrypt 3DES Encrypted Buffer Size"
- Reply: j allen: "Re: CryptEncrypt 3DES Encrypted Buffer Size"
- Reply: j allen: "Re: CryptEncrypt 3DES Encrypted Buffer Size"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Date: Tue, 16 Mar 2004 23:03:45 -0800
"j allen" <jallen_12342000@yahoo.com> wrote in message
news:a0048d52.0403161630.2a6df1f7@posting.google.com...
> I'm using CryptEncrypt to encrypt a buffer that's 16 bytes in length.
> I'm using CALG_3DES_112 for the Algorithm, I'm getting the exact same
> behavior using CALG_3DES.
>
> If in the example below ulBufferSize = 16, then after calling
> CryptEncrypt() dwEncryptedBufSize will be 24. I know since 3DES is a
> block cipher it will round up to the nearest multiple of the block
> size, but I thought if ulBufferSize is 16 and already a multiple of 8
> (the block size) then CryptEncrypt would not need to expand the
> encrypted buffer size to 24.
>
>
> CryptEncrypt(hKey, NULL, TRUE, 0, NULL, &dwEncryptedBufSize,
> ulBufferSize)
>
> I'm comparing the encrypted buffer results using the CryptoAPI with
> another hardware implementation that doesn't use the CryptoAPI.
> Interestingly the first 16 bytes of the Encrypted buffers are
> identical, but the CryptoAPI has another 8 bytes for some reason.
> Can anyone provide a clue as to what's going on.
You are seeing the effects of PKCS5 padding, which adds
8 bytes of 0x08 _before_encryption. To verify this
take this 16 byte plain text vector
"0102030405060708090A0B0C0D0E0F10"
with the 24 byte key
"0102030405060708090A0B0C0D0E0F101112131415161718"
with both of the above converted to binary from hex.
Do some md5-cbc-3des with the default IV of
00,00,00,00,00,00,00,00
You will get (b64 encoded):
zF1PBf2XoFkR+2zwlEfXDI6GZ1vt0Bm5
you can show that the last 8 chars are from the
pkcs5 by doing the above again, but change the
in vector to
"0102030405060708090A0B0C0D0E0F100808080808080808"
now you will get (b64 encoded)
zF1PBf2XoFkR+2zwlEfXDI6GZ1vt0Bm5KvsKAnNRNgc=
this time the last 12 char string,
KvsKAnNRNgc=
, comes from the pkcs5.
Using my VB DLL CryptoAPI wrap object, this kind of test can be done
in 10 minutes or less.
good luck,
msp
- Next message: Haggai: "Syskey API"
- Previous message: henghuei: "zero knowledge"
- In reply to: j allen: "CryptEncrypt 3DES Encrypted Buffer Size"
- Next in thread: j allen: "Re: CryptEncrypt 3DES Encrypted Buffer Size"
- Reply: j allen: "Re: CryptEncrypt 3DES Encrypted Buffer Size"
- Reply: j allen: "Re: CryptEncrypt 3DES Encrypted Buffer Size"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|