CryptEncrypt AES128 problem thanks RRS feed

  • Question

  • hi , 

     create a AES_128 key from CryptGenKey ,and the returned AES handle is OK.I can export the AES key from this handle.

    As my knowledge, BLOCK size  which AES_128 can encrypt by once is 16byte.

    But ,the problem is when I use this handle to encrypt 16byte data using CryptEncrypt ,it always fails with ERROR msg "More Data avaible".And the returned len from CryptEncrypt is 32.

    I don't know why it return 32.CryptEncrypt should encrypt 16byte at once at this situation.

    can anyone help me??

     thanks very much.



    my code like this


        dwFlags = 0x80;         // Bit length: 128-bit AES.
        dwFlags <<= 16;               // Move this value to the upper 16 bits.
        dwFlags |= CRYPT_EXPORTABLE;  // We want to export the key.
           g_hCSP,           // Handle to the CSP.
           CALG_AES_128,   // Use 128-bit AES block encryption algorithm.
           &g_hAESKey      // Receives a handle to the AES key.
        DWORD cbData = 0;
        BYTE *pData = NULL;
        // Get the size of the blob.
        CryptExportKey(g_hAESKey, 0, PLAINTEXTKEYBLOB, 0, NULL, &cbData); 

        // Allocate the array and call again.
        pData = new BYTE[cbData];
        CryptExportKey(g_hAESKey, 0, PLAINTEXTKEYBLOB, 0, pData, &cbData);

        DWORD *pcbKey = (DWORD*)(pData + sizeof(BLOBHEADER));
        if (*pcbKey != 16)
           // my code doesn't go this path,*pcbKey is 16,it is oK 
            return FALSE;




    ///  len ==16

         {  //len ==32   ,error
                 ErrorMsg(TEXT("EnCrypt AES"));
                 return ;


    Monday, April 9, 2007 11:04 AM

All replies


    I am also having the same problem. It returns 32 bytes even though I am using the


    Key:  e6600fd8852ef5abe6600fd8852ef5ab
    IV:   810e528e1c5fda1a810e528e1c5fda1a
    Text:  000102030405060708090a0b88416506


    and I get the below encrypted output:




    Where as I should have been seeing only



    But If I give the above 32 byte encrypted Hex string as input to my Decrypt function

    it is returning the correct Text back.


    Please help me in case if I am missing something here with any of the algorithm settings.



    Monday, April 7, 2008 11:56 PM
  • hi

    i am also facing the same problem.
    is any one find any solution

    i identified a trend if buffer have "" NULL char in middle then it show wrong value.
    it's only an observation.

    if any one have any answer please 
    please please help me.

    Chandra Kant
    Wednesday, October 22, 2008 4:03 PM
  • The solution (if you have just 1 block) is a little "tricky"



    if(len & 0x0F)

        last = TRUE;




        last = FALSE;

    CryptEncrypt(g_hAESKey, NULL, last, 0, pDataOut, &len, size);


    -Decoding (trickier):

    memcpy(auxBuf, pDataOut, len);

    aux = len;

    iRet = CryptDecrypt(g_hAESKey, NULL, TRUE, 0, auxBuf, &aux);



    (iRet == 0) {



    (GetLastError() == NTE_BAD_DATA) {

            memcpy(auxBuf, pDataOut, len);

            aux = len;

            iRet = CryptDecrypt(g_hAESKey, NULL, FALSE, 0, auxBuf, &aux);




    Thursday, October 6, 2011 10:02 PM
  • This is an old thread, but I don't want to let that post go without comment.

    AES is a block cipher, and like all block ciphers it can be used in one of several modes, such as ECB, CBC, OCB, CTR.  Only the first of these modes - ECB, or electronic code book, which is the fundamental block encryption mode - allows a single block of output to result from the encryption of a single input block.  The others are geared towards encoding multiple blocks of input data, and involve additional data (the IV) which means the output is longer than the input. 

    CryptEncrypt() is using one of these (CBC by default - use CryptSetKeyParam 's KP_MODE parameter type to change it) so deliberately chopping off the second block of the data to force it to be a single block is not a safe thing to do; that's why you're seeing the NTE_BAD_DATA error on decode - in fact, the chances are all you have done is decrypted the IV and none of the original input data at all.

    Notice the text for dwBufLen in CryptEncrypt function which says

    "Note that, depending on the algorithm used, the encrypted text can be larger than the original plaintext. In this case, the pbData buffer needs to be large enough to contain the encrypted text and any padding.

    As a rule, if a stream cipher is used, the ciphertext is the same size as the plaintext. If a block cipher is used, the ciphertext is up to a block length larger than the plaintext."

    See also http://stackoverflow.com/questions/1220751/how-to-choose-an-aes-encryption-mode-cbc-ecb-ctr-ocb-cfb

    Answering policy: see profile.
    Tuesday, October 25, 2011 9:46 PM