Re: Using 128 bit AES (CALG AES 128) to generate session keys - problem

From: Dale R (daler1_at_rediffmail.com)
Date: 05/26/04 

Date: 26 May 2004 13:12:29 -0700

Hi msviewer,

Thanks for the detailed and insightful post. Although Remus had given
me the answer to my basic problem, your post did give me a better
understanding of what is going on. I setup the provider as described,
and it worked fine :)

I do have a follow up question though. For some reason, the same thing
is failing on Windows Server 2003 and (atleast one) Windows 2000
machine with the High encryption pack installed. Im wondering, is
there anything I need to do vis-a-vis the building to get it working ?

Thanks!
Dale
"tlviewer" <tlviewerSHRUB@yahoo.CHENEY.com> wrote in message news:<#lXwbOtQEHA.3616@TK2MSFTNGP09.phx.gbl>...
> Hello Dale,
> "Dale R" <daler1@rediffmail.com> wrote in message
> news:ba6cc5ed.0405251857.368f6798@posting.google.com...
> > Hi,
> >
> > Im using Visual Studio 6, Ive installed the latest version (or close
> > enough) of the Microsoft Platform SDK. Im running this on Windows XP.
> >
> > My problem arose when trying to use CryptGenKey to generate a 128 bit
> > session key using the AES algorithm. What happens is that the context
> > acquiring, container, all the standard calls go through fine. But only
> > in the case of CALG AES 128, the CryptGenKey() call fail with
> > NTE BAD ALGID. With CALG RC4 it goes through just fine (and works!).
> >
> > So my question is, what could I be doing wrong? What might I need to
> > do to get this to work? Is it perhaps a problem with the way I
> > installed PSDK?
> >
> > My call to CryptGenKey is as follows
> > CryptGenKey(hProv, ENCRYPT ALGORITHM, CRYPT EXPORTABLE, &hSessionKey)
> > where ENCRYPT ALGORITHM is #defined to be CALG AES 128.
> >
> > Any assistance is greatly appreciated! Ive gone through MSDN very
> > heavily and it was very useful to do the basic coding, but handling
> > these odd cases is something I just couldnt do from what I got there.
> >
> > Thanks!
>
> I've recently done some broad testing of the CryptoAPI suite
> that comes default with WinXP Pro (Corp), sp1.
>
> Look at the arguments to CryptAquireContext().
> If you are passing in NULL for pszProvider and dwProvType
> then you are using the default provider, which probably is
> "Microsoft Strong Cryptographic Provider".
>
> This is an RSA provider type, not an RSA AES provider type. You
> need to pass something other than NULL to CryptAquireContext for
> pszProvider and/or dwProviderType.
>
> You can see all the providers there by looking at the subkeys of
> HKLM\SOFTWARE\Microsoft\Cryptography\Defaults\Provider
>
> On WinXP sp1, only the (Prototype) RSA AES provider is available.
> While I go to the trouble of passing in the full provider name, you
> can probably get away with NULL for that and give
> PROV RSA AES for the dwProvType.
>
> Another new toy in the WinXP CryptoAPI is the
> PLAINTEXTKEYBLOB. This can be used to directly get a session key
> from cleartext with minimal sweat. The signature of this blob is
>
> (thanks to Ryan Menezes [MSFT])
> {
> BLOBHEADER // 08 02 00 00 0E 66 00 00 8 bytes (CALG AES 128)
> DWORD lenKey // 10 00 00 00 (16 bytes)
> BYTE key[lenKey]
> }
>
> You can pack this blob with your AlgID (CALG AES 128), key length, and
> finally your key (as MSB). This is much easier than in the past
> where the Exponent of One key (trick) had to be used.
>
> good luck,
> msp

Relevant Pages