[Libaes-devel] Proposed API for libaes

[Nigel M. <Nig...@de...>]

Folks (I have no idea how many people are on this list - or whether it
includes more than just me :-) ),

Here's a basic proposal for how I aim to do the next libaes release. 
There are some changes, some of which come from changes to Brian
Gladman's latest code drops, and some of which are my grand master
plan...umm(!).

In general aes.h is getting less complex, and is losing its block size
dependancy.  libaes is going to support the 3 main block sizes - 128,
192 and 256 bits.   Key sizes supported will be the same - I am not
currently intending to do anything to support weird intermediate key
sizes (OK thats pejorative language, but are there any reasonable
requirements for intermediate keysizes especially as it really hits
efficiency at present).

There will be 4 sets of function entries:-
  aes_...	- any block size handling code
  aes128_...	- 128 bit block size code
  aes192_...	- 192 bit block size code
  aes256_...	- 256 bit block size code

Ideally all of the aes<nnn>_ entries will use a highly optimised version
of the code - assembler if we have it.

aes_crypt/aes_decrypt will be a stub routine that selects the
appropriate aes<nnn> function which is likely to be the fastest
implementation of a generalised function with the downside that it
bloats the code size.  

The other big change is from Brian's upstream code.
The aes context is now valid for encryption *or* decryption - to do both
you need 2 separate contexts.   There are also 2 different set key
functions - one for encryption, one for decryption.

The base context declaration is big enough for aes256.  However I'm
going to add a context declarations for smaller block lengths, but they
will need to be cast-ed into place when used.

I've attached a version of the latest aes.h which should give you the
idea of how the user visible API looks.

	Nigel.


-- 
[ Nigel Metheringham           Nig...@In... ]
[ Phone: +44 1423 850000                         Fax +44 1423 858866 ]
[ - Comments in this message are my own and not ITO opinion/policy - ]