rindael with blocksize other than 128 uses some never initialized variables in both the encrypt and decrypt, and thus will lead to inconsistant results. We should either fix these routines or explicitly disable them. Also, as far as I can see, there are no AES test vectors for freebl (at least in the test vector directory. Ian, are they compiled in, or are we just missing them altogether. bob
You are right. I disabled the functions on the tip to avoid further confusion. One of the problems I had was that a year ago I could not find test vectors for blocks > 128 bits to test my implementation against. Perhaps they exist now. And yes, freebl is missing AES tests. That is one item I will try to fix soon.
Cool. One thing we could do is tempararily use the 'generic' code for 128 byte blocks to make sure it works (or more exactly for getting it to work). bob
Why is this targeted for 3.4? Are there any ciphersuites using AES for > 128-bit blocksizes?
Target 4.0, priority P2.
Maybe it's too obviuos but if test values are to be found, that's there: http://csrc.nist.gov/encryption/aes/rijndael/ =)
Changed the QA contact to Bishakha.
OpenSSL now supports 256b AES, so it's possible to test against that. Now that it's possible for a standard Apache/mod_ssl setup to support TLS with AES, it'd be nice to see it all working.
I assume you mean AES with 256 bit keys? That is different than AES with 256 bit blocks, which is the subject of this bug. AFAIK, no one is using AES for blocksizes other than 128 bits, the PKCS#11 mechanism doesn't even allow blocksize to be an option.
I believe this bug is no longer accurate. Alexei, did your SSL interoperability testing with OpenSSL and IIS include AES-256, and was it successful ? If so, that should be enough proof that this bug is invalid.
AES 256/128 interoperability tests for NSS 3.10 pass. We fail with IIS, but I believe it is so because installed version of crypto library on our machine does not have these ciphers.
Thanks, Alexei. Unfortunately, I read this bug a little too quickly. Comment #7 says this is an issue about block size rather than key size, and the SSL tests always use 128 bits block size .
The following excerpt from the AES spec (FIPS 197) explains the difference between AES and Rijndael: 1. Introduction This standard specifies the Rijndael algorithm ( and ), a symmetric block cipher that can process data blocks of 128 bits, using cipher keys with lengths of 128, 192, and 256 bits. Rijndael was designed to handle additional block sizes and key lengths, however they are not adopted in this standard. One thing we can do is to remove the 'blocksize' parameter from AES_CreateContext and AES_InitContext, so that when we say AES we really mean AES, not Rijndael. At least, those two functions should reject a block size not equal to 128 bits.
Wan-Teh, I like the suggestion of removing the blocksize parameter. Doing so might even yield some performance benefits. On the other hand, how confident are we that we will not need to support other blocksizes in the future ? Do we know the reason that FIPS 197 selected the particular 128 block size ? Is there any known problem with other block sizes ?
Rijndael is not the "same thing" as AES. Rijndael was a proposal to AES and had (128,192,256) sizes *both* for key and block. AES, the actual standard, only has 128 byte block size, it can only change in key size. So AES-256 can only mean "the same as Rijndael, with 128 block size and 256 key size" and never "256 block size".
We don't intend to support Rijndael other than the AES subset.