I am exploring the use of Windows CNG to replace some OpenSSL-based code that takes advantage of AES in counter mode. From the outside, everything should look the same after the switch.

The section BCRYPT_CHAINING_MODE in this piece of CNG documentation gives me the impression that the only counter modes supported are BCRYPT_CHAIN_MODE_CCM, which sets the algorithm's chaining mode to counter with CBC-MAC mode (CCM) and BCRYPT_CHAIN_MODE_GCM, which sets the algorithm's chaining mode to Galois/counter mode (GCM)

I have no experience with CCM or GCM and would like to understand whether it is possible to use them in such a way that it can interoperate with CTR, by "disabling" the authentication part or in any other way. I did not find any indication that that is possible indeed, but on the other hand, I would be surprised if CNG does not support AES-CTR.

Maybe my question should have been "does Windows CNG support AES-CTR" to get a more direct answer :-)

Update: On another Microsoft webpage, in the section Cryptographic Algorithms, the table called "Table 12 – Advanced Encryption Standard (AES)" mentions "CTR( int only; 128 , 192 , 256 )", which I suppose means that it is internal functionality only.

I think this question is related: What is wrong with AES-CTR-HMAC-SHA256 - or why is it not in TLS?

  • $\begingroup$ Why don't you want authentication? Stream ciphers like AES-CTR are incredibly malleable without authentication (flipping a ciphertext bit flips the corresponding plaintext bit). $\endgroup$
    – cpast
    Jan 15, 2015 at 17:59
  • $\begingroup$ I already have authentication in place using an "encrypt-then-MAC" scheme with an HMAC $\endgroup$ Jan 15, 2015 at 18:35
  • 3
    $\begingroup$ Implementing CTR on top of ECB is probably easier than hacking GCM to become CTR. $\endgroup$ Jan 16, 2015 at 9:53

2 Answers 2


That might not be speed-efficient, but for educational purpose it is possible to implement the CTR internals manually, by using the ECB mode of CNG:

Set the Algorithm mode:


Encrypt all blocks the IV with counter with the key hKey:

              pbIV, // Feed the IV here
              cbIV, // block size (IV size)
              NULL, // padding not used
              NULL, // we do not need to pass IV here
              ptPlaintext,  //Output to plaintext buffer
              cbPlaintext,  //Blocksize here.

and finally, XOR the whole resulting array with Ciphertext.

P.S> I forgot to add - the IV should be incremented after each call to BCryptEncrypt, and it's big-endian, the increment procedure on the 128 (or 192 or 256) bit integer (which IV is) should be implemented manually as well.


A message encrypted with AES-GCM can be decrypted with an AES-CTR library IF the authentication tag is stripped from the message.

If you are encrypting with AES-GCM and then adding an HMAC tag, you need to strip the HMAC and the GTAG off the message in order to decrypt it, assuming the IV section of the message is in the correct location for each library to handle.


Thanks to Maarten Bodewes for pointing out that the initial counter value is used in GCM to create the Galois hash key, and thus would need to be incremented by 1 in order to read the message data properly.

  • $\begingroup$ How about the other way around, can a message encrypted with AES-CTR be decrypted with AES-GCM, by telling it to ignore the authentication tag maybe? $\endgroup$ Jan 16, 2015 at 14:24
  • $\begingroup$ @ReinierTorenbeek Likely not. If the authentication tag doesn't check out, GCM should be throwing an error. I'd consider CodesInChaos's idea of implementing CTR using ECB (or, for that matter, by not chaining at all). $\endgroup$
    – cpast
    Jan 16, 2015 at 16:21
  • $\begingroup$ @ReinierTorenbeek That would be weird. If GCM is available then CTR should be available. One rather weird method would be to recreate the key stream by encrypting all zero's and then XOR that with the received ciphertext. $\endgroup$
    – Maarten Bodewes
    Jan 16, 2015 at 21:35
  • $\begingroup$ This answer is missing the part where you have to advance the counter with 1 before decryption with AES-CTR (for GCM anyway). $\endgroup$
    – Maarten Bodewes
    Jan 16, 2015 at 21:37
  • $\begingroup$ AES-GCM libraries are required to FAIL a message that does not have a valid authentication tag, and @MaartenBodewes is correct in that the GTAG hash key gets the block counter of 0, and the message itself gets the block counter starting at 1. My implementation of CTR allows up to a 128-bit nonce input (MSB aligned), which will overwrite the 0 counter allowing it to decrypt at any block location specified, I assume others will do the same, but the GCM counter offset may not be obvious. $\endgroup$ Jan 17, 2015 at 0:31

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.