AES
Analysis of the RefCode, OptCCode and AddCode submissions

Notes on implementation of API functions

(a)

The NIST API is not fair here... the parameter IV is a string that is translated into an array of BYTE and stored in the cipherInstance. This is not the same as the parameter keyMaterial for makeKey, that is stored unchanged in the keyInstance.

(b)

We make a library with all the API functionalities, that will be linked with our test programs.

(c)

We have to initialise cipher->verboseoutfile to NULL. We don't have this problem with OptCCode.

(d)

keyMaterial should be a string of keyLen/4 ASCII characters describing the hex value of the key. This function uses the binary encoding of keyLen/8 characters.

(e)

If you want to build some crypto library using the NIST API, you need to include the main file, which defines a main function that you may have to delete. To do some timings, this file uses the value of a constant CLOCKS_PER_SEC, that is not defined in some operating systems (e.g. SunOS 4.1.4)

(f)

As stated in deal.h, you have to allocate key->kss before calling makeKey.

(g)

The file names are not consistent : deal.c, dealref.c and dealkeys.c want to include DEAL.h when dealapi.c needs deal.h.

(h)

Segmentation fault if IV is NULL or non valid, even in ECB mode.

(i)

Here, the parameter inputLen is the size of input in bytes instead of bits (same behaviour as the Java API). Still the return value is the number of bits enciphered.

(j)

The function returns TRUE instead of the number of bits enciphered.

(k)

makeKey allocates three blocks of memory key->KS, key->hpc_kmbits and ((U64**)key->KS)[HPCM] that may never be freed, and cipherInit allocates one block of memory that cannot be freed.

(l)

We have to initialise cipher->blockSize to 128.

(m)

On success, makeKey and cipherInit return 0 instead of TRUE.

(n)

makeKey and cipherInit are defined with an additional argument : blockLen. This is not compatible with the API...

(o)

AES_SAFERPlus.h defines BAD_KEY_LEN without saying it is algorithm specific. This definition changes the values of BAD_KEY_INSTANCE, BAD_CIPHER_MODE and BAD_CIPHER_STATE.

(p)

The file serpent-api.h defines the macro r with value 32 ! This may cause conflicts with variable names or struct members. We don't have this problem with OptCCode.

(q)

Warning! the function returns BAD_KEY_MAT if it was compiled with the bad endian definition...

Notes

(a)

It is not clear in the NIST API if an encryption or decription should change cipher->IV. We note with a # the implementations that do change cipher->IV.

(b)

Note that the NIST API cannot be used to decrypt in CFB1 mode, since you need to use the DIR_ENCRYPT key schedule with the blockDecrypt function and that is forbidden (returns a BAD_KEY_MAT).
I changed the API to allow DIR_ENCRYPT and only this key schedule for blockDecrypt in CFB1 mode. I made the tests with this modified API.
DEAL and FROG implementors had already noticed this problem.

(c)

Only OptCCode decrypts well, but the NIST did not require RefCode implementations of CBC and CFB1.

(d)

Encryption : very weak ! only the first byte is changed for 16 bytes of input...

Decryption : missing a break in the C source to have a valid return value.

(e)

CFB1 mode is only implemented for 1 bit messages... and cannot be decrypted.

(f)

CFB1 mode is only implemented in OptCCode, since the NIST did not require RefCode implementations of CBC and CFB1.

(g)

Only RefCode decrypts well, but the NIST did require OptCCode implementation of CFB1.

Notes : ANSI conformance and portability of the C source

(a)

You have to change the file cast.h : there is a macro littleendian that allow portability.

(b)

You have to change the type uns32 in cast.h.

(c)

Everything is OK with the RefCode, but for the OptCCode running the tests makes a SIGSEGV...

(d)

In hpc-ansi.c there may be a SIGBUS due to a cast from BYTE* to U64* in makeKey.

(e)

hpc-ansi.c and hpc-gcc.c give wrong results, depending of the internal representation of integers.

(f)

There is a serious SIGBUS problem due to a cast from BYTE* to WORD* in cipherInit : that does not respect alignment.

(g)

You have a test for endianess in the definition of SWAP_BYTES in sbox.c, mars-ref.c and mars-opt.c, which you may have to enhance for other architectures.

(h)

You have to change the type WORD in aes.h.

(i)

It is OK with RefCode but give wrong results with OptCCode.

(j)

If you change all instance of long to some 32-bits integer type, it works for RefCode but not for OptCCode.

(k)

You have to change word32 in rijndael-alg-fst.h.

(l)

For OptCCode, you have to change every long in all the files.

(m)

You have to change the file platform.h which detects little-endian only if _M_IX86 is defined. But if you set _M_IX86 for some non-Windows environnment, there may be other problems... So the adaptation to non-Wintel architectures is a bit sophisticated.

(n)

You have to change the definition of DWORD in aes.h and the casts from pointer to int in twofish.c (those casts check the alignment, cf. the remark (f) for Mars).

(o)

You have to change every long in the files aestime.c, loki97.c and loki97.h to an int.

(*)

I don't accept 64-bits integer types (long long, or long for Alpha) because it is not ANSI. It should be allowed by C9X.

(a)

I use gcc -O9 version egcs-2.91.45 : encryption is much faster.

(b)

I use acc -fast version SWC-4.2 (Sun C compiler) : encryption is much faster.

(c)

I have changed the files crypton.h and cryptonsbox.c to set the type DWORD to unsigned int : the encryption speed gains 12%.

(d)

I have changed the files dfc.h to set the types u32 and s32 to (un)signed int : the encryption speed gains 6%.

(e)

This timings are done with RefCode, since OptCCode fails.

(f)

I use RefCode : encryption is faster.

(g)

Take care : these timings correspond to an encryption with bad endianess.