Share via

The Differences Between Rijndael and AES

  • Article

When you need to write managed code that encrypts or decrypts data according to the AES standard, most people just plug the RijndaelManaged class in and go on their way.  After all, Rijndael was the winner of the NIST competition to select the algorithm that would become AES.  However, there are some differences between Rijndael and the official FIPS-197 specification for AES.

Namely, Rijndael allows for both key and block sizes to be chosen independently from the set of { 128, 160, 192, 224,  256 } bits.  (And the key size does not in fact have to match the block size).  However, FIPS-197 specifies that the block size must always be 128 bits in AES, and that the key size may be either 128, 192, or 256 bits.  Therefore AES-128, AES-192, and AES-256 are actually:

Key Size (bits) Block Size (bits)
AES-128 128 128
AES-192 192 128
AES-256 256 128

Since RijndaelManaged is an implementation of Rijndael, it will allow you to select different block sizes (although both block and key sizes must be either 128, 192, or 256 bits.  160 and 224 bit are not supported).  By selecting a block size which is not 128 bits however, RijndaelManaged will not be able to interoperate with an AES implementation ... since the block sizes will not match on either end of the communication.

One other interesting quirk of the RijndaelManaged implementation is that it will adjust block size to match the feedback size in CFB mode.  This means that if you use CFB and a block size of 128 bits, but a feedback size which is not 128 bits you again will not be compatible with AES.  Generally this does not affect many people, since the most common cipher mode to use is CBC.

Essentially, if you want to use RijndaelManaged as AES you need to make sure that:

  1. The block size is set to 128 bits
  2. You are not using CFB mode, or if you are the feedback size is also 128 bits

Comments

  • Anonymous
    October 10, 2006
    You block size for AES-256 in your table should be 128 not 228.  Feel free to delete this if it no longer applies...

  • Anonymous
    October 10, 2006
    Yep, stupid typoo.  Thanks, I've fixed it now! -Shawn

  • Anonymous
    October 13, 2006
    Hi, I'm curious, why doesn't Rijndael work when the system cryptography FIPS compliance security setting is enabled? Since it's the successor to DES, and since FIPS 197 is the official standard for it, I guess I kind of expected it to work. Has it just not yet been through compliance testing, or is there some reason that it will never be compliant? David

  • Anonymous
    October 13, 2006
    The comment has been removed

  • Anonymous
    January 11, 2007
    Sorry AES crypto ignorant question here. What about cipher mode and initialization vector? As you said above like most people I just got RijnDaelManaged and went, when I got the request to encrypt using AES. Wouldn't you need to agree on a cipher mode and exchange init vectors with the deciphering party, in addition to exchanging keys? Or is CBC what people use when they say AES? And initVector is not used, or rather all 0? Thanks

  • Anonymous
    January 17, 2007
    The January CTP of Orcas is now available , and with it comes a total of 12 new cryptography algorithm

  • Anonymous
    January 17, 2007
    Hi Christian, You're correct that both sides of the encrypted conversation will need to agree on all of the parameters to successfully communicate.  AES does not restrict either IV or the cipher mode, however as I mention in the blog post there is a bug in RijndaelManaged which makes CFB and OFB dangerous to use if you need to work with AES.  In practice most people just default to CBC. As for the IV, that's not technically protected information, so one practice is to just send it in plaintext before the beginning of the encrypted conversation. -Shawn

  • Anonymous
    March 22, 2007
    Is it cryptographically dangerous to simply agree that the IV will be the first (or last) 128 bits of the key? (Is the answer the same for all key sizes?) I'm thinking there are plenty of other things that need to be agreed upon (mode, feedback, padding, block size, etc) so why not the IV too?

  • Anonymous
    April 23, 2007
    The best solution is to encrypt IV with a perminent (persistent) key previously agreed with the other party, so that only you (plural) know how to decode it. cf. The enigma machine during WWII which had day settings (keys)preknown and the message keys which were encrypted using the day keys. In CBC the PT is XORed with the previous CT, thus ensuring that any changes made to the CT stream will propagate in the decrypted PT. However, this otherwise gives no better security than ECB except for the matter that no repetitions of PT (and CT) can appear.