libaes-devel Mailing List for An AES/rijndael encryption library
Status: Pre-Alpha
Brought to you by:
nigel
You can subscribe to this list here.
2002 |
Jan
(3) |
Feb
(2) |
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
---|---|---|---|---|---|---|---|---|---|---|---|---|
2005 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: Colin O'K. <cok...@gm...> - 2005-01-02 23:30:47
|
Hi, Iam trying to encrypt the a string in variable global_vars OR file called PS(file) can someone show me how to do this in C using the library. My C isnt very good. Do i include aes.h ? or is there anythung else? also, how do i make a key to use? your help very much appricated regards -colin |
From: Sandy H. <sa...@st...> - 2002-05-02 02:59:46
|
Sourceforge appears to have two projects, libaes and aeslib. This mail goes to both in hopes some duplication of effort can be avoided. |
From: Nigel M. <Nig...@de...> - 2002-02-11 10:31:14
|
I'm just rehashing some bits aiming to get a reasonable base implementation out soon. However long term things have suddenly changed. The UK government, having no more intelligence than the US one, but a far less appropriate sense of timing appears to be sneaking out a set of export controls on crypto. I need to work out what these mean in practice. [Sandy, it might be worth putting a note of caution on UK originated code into freeswan at present] Nigel. -- [ Nigel Metheringham Nigel.Metheringham@InTechnology.co.uk ] [ Phone: +44 1423 850000 Fax +44 1423 858866 ] [ - Comments in this message are my own and not ITO opinion/policy - ] |
From: Rickard H. <Ric...@st...> - 2002-02-09 09:27:03
|
Hello everyone (still only Nigel and Sandy?) I have written a vector-based implementation of AES in PowerPC G4 assembler (there is an alpha version at http://home.student.uu.se/riho7361/aes.html). Since the PowerPC has pretty bad memory performance, I chose not to use any look-up tables other than the s-box and its inverse, and put that in registers (filling half of the available 32 x 128 bits vregs). This means that I have a quite high latency for loading the s-box, generating constants, etc. When that is done, encryption and decryption is quite fast. Thus, it is quite slow to encrypt a single block and much more efficient to encrypt more blocks in a single function call, since it only has to set up the constants once for each call. The PowerPC probably isn't the only processor where it would be beneficial to have an API that can process several blocks in one call. It could also be quite well-suited to wrap CBC and other modes of operation, if that should be included in the library. /Rickard Holmberg |
From: Nigel M. <Nig...@de...> - 2002-01-28 13:04:38
|
On Fri, 2002-01-25 at 22:44, Sandy Harris wrote: > Nigel Metheringham wrote: > > - 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). > > Why even consider it? Neither the original Rijndael nor the AES spec > have those, and you aren't doing research on cipher variations. You're > either implementing the cipher or providing a new interface for Brian > Gladwin's code. Either way, you have no business adding things. Actually the intermediate key sizes are from Brian Gladman's code. > The AES contest specified that all entries must use a 128-bit block > size. All the evaluation of Rijndael (security and speed) during the > AES process used that size, so much less is known about whether the > other sizes might have security weaknesses. The AES standard is for > a cipher with 128-bit block size, Rijndael minus the variable block > size feature. Last time I looked, that was all Brian Gladwin's code > supported as well. This had slipped past me but going back and looking at the AES spec (ie FIPS-197 - see http://csrc.nist.gov/publications/fips/fips197/fips-197.pdf ), you are exactly right. > I think you should do only the one block size, unless someone can > turn up a compelling reason that the others are quite useful. Yes - libaes should be AES (Rijndael 128 bit block size) with 128/192/256 bit key sizes only. Also since FIPS-197 refers to AES-128, AES-192 and AES-256 as being Rijndael 128 bit block size with differing key lengths, my use of aes128/aes192/aes256 denoting different *block* sizes is highly confusing. > If you really want to do them all, then I think the names should be: > > aes 128-bit block > #ifdef REST_OF_RIJNDAEL > rijndael any block size > rijndael_128blk 128-bit block > rijndael_192blk 192-bit block > rijndael_256blk 256-bit block > #endif > > You cannot call it AES if it uses any block size other than 128. > > You need rijndeal_128blk, not just rijndael_128, to make it clear I think I'll look at splitting the non-AES stuff out into a different library - maybe built from the same source package, but work with an rijndael.h and a librijndael for those. In general I don't think there is a good case in efficiency terms for having separate calls for AES-128, AES-192, AES-256 (ie different key sizes) since the avoidable cost for a version that does all 3 key lengths over a per keylength implementation is 1 test and jump (those real speed demons may find that a pure assembler AES-128 implementation with no error checking at all has a 2 or 3% speed increase over the current.... I'll try that just to ensure my figures are right. BTW anyone know somewhere providing sourceforge like facilities but based outside the US? Currently I'm only using sourceforge for distribution since I don't want to potentially risk losing some control of the CVS tree should current US crypto policy blow in the wind again. Nigel. -- [ Nigel Metheringham Nigel.Metheringham@InTechnology.co.uk ] [ Phone: +44 1423 850000 Fax +44 1423 858866 ] [ - Comments in this message are my own and not ITO opinion/policy - ] |
From: Sandy H. <sa...@st...> - 2002-01-25 22:43:16
|
Nigel Metheringham wrote: > 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 Those are all the sizes in the original Rijndael spec. That allows key and block sizes to vary independently over 128, 192, 256. However, AES as standardised is /not/ identical to that. See below. > - 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). Why even consider it? Neither the original Rijndael nor the AES spec have those, and you aren't doing research on cipher variations. You're either implementing the cipher or providing a new interface for Brian Gladwin's code. Either way, you have no business adding things. > 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. I think even this complexity is unnecessary. The AES contest specified that all entries must use a 128-bit block size. All the evaluation of Rijndael (security and speed) during the AES process used that size, so much less is known about whether the other sizes might have security weaknesses. The AES standard is for a cipher with 128-bit block size, Rijndael minus the variable block size feature. Last time I looked, that was all Brian Gladwin's code supported as well. I think you should do only the one block size, unless someone can turn up a compelling reason that the others are quite useful. If you really want to do them all, then I think the names should be: aes 128-bit block #ifdef REST_OF_RIJNDAEL rijndael any block size rijndael_128blk 128-bit block rijndael_192blk 192-bit block rijndael_256blk 256-bit block #endif You cannot call it AES if it uses any block size other than 128. You need rijndeal_128blk, not just rijndael_128, to make it clear |
From: Nigel M. <Nig...@de...> - 2002-01-25 14:38:32
|
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 Nigel.Metheringham@InTechnology.co.uk ] [ Phone: +44 1423 850000 Fax +44 1423 858866 ] [ - Comments in this message are my own and not ITO opinion/policy - ] |