via_ace.txt

AES高级加密标准的C代码

Support for the VIA Nehemiah Advanced Cryptography Engine (ACE)
---------------------------------------------------------------

A. Introduction

The AES code now supports the VIA ACE engine.  There are three possible
support files depending on what is known about the intended system
configuration:

1. When ACE is known to be absent the AES modes are provided by aes_modes.c;

2. If ACE might be present then ace_modes.c is used because it has tests to
   determine if it is available before it is used.  If it is not available
   it reverts to normal AES code; USE_VIA_ACE_IF_PRESENT must be defined;

3. This file can also be used when ACE is known to be available and the
   define ASSUME_VIA_ACE_PRESENT in aesopt.h can then be used to remove all C code
   that is not needed (USE_VIA_ACE_IF_PRESENT must also be defined) As an alternative, 
   the assembler code in ace_modes.asm (in NASM format) can be used and is 
   significantly faster.

To enable ACE support the appropriate defines in section 1 of the options in
aesopt.h must be set.

B. Using ACE

ACE is used in the code that implements the subroutines used for the multiple
block AES modes defined in aes_modes.h:

    // used to reset modes to their start point without entering a new key
	aes_rval aes_mode_reset(aes_encrypt_ctx cx[1]);
	
	aes_rval aes_ecb_encrypt(const unsigned char *ibuf, unsigned char *obuf,
                    int len, const aes_encrypt_ctx cx[1]);

	aes_rval aes_ecb_decrypt(const unsigned char *ibuf, unsigned char *obuf,
                    int len, const aes_decrypt_ctx cx[1]);

	aes_rval aes_cbc_encrypt(const unsigned char *ibuf, unsigned char *obuf,
                    int len, unsigned char *iv, const aes_encrypt_ctx cx[1]);

	aes_rval aes_cbc_decrypt(const unsigned char *ibuf, unsigned char *obuf,
                    int len, unsigned char *iv, const aes_decrypt_ctx cx[1]);

	aes_rval aes_cfb_encrypt(const unsigned char *ibuf, unsigned char *obuf,
                    int len, unsigned char *iv, aes_encrypt_ctx cx[1]);

	aes_rval aes_cfb_decrypt(const unsigned char *ibuf, unsigned char *obuf,
                    int len, unsigned char *iv, aes_encrypt_ctx cx[1]);

	#define aes_ofb_encrypt aes_ofb_crypt
	#define aes_ofb_decrypt aes_ofb_crypt

	aes_rval aes_ofb_crypt(const unsigned char *ibuf, unsigned char *obuf,
                    int len, unsigned char *iv, aes_encrypt_ctx cx[1]);

	typedef void cbuf_inc(unsigned char *cbuf);

	#define aes_ctr_encrypt aes_ctr_crypt
	#define aes_ctr_decrypt aes_ctr_crypt

	aes_rval aes_ctr_crypt(const unsigned char *ibuf, unsigned char *obuf,
            int len, unsigned char *cbuf, cbuf_inc ctr_inc, aes_encrypt_ctx cx[1]);

Note that the single block AES calls defined in aes.h:

    aes_rval aes_encrypt(const unsigned char *in, unsigned char *out,
                    const aes_encrypt_ctx cx[1]);

    aes_rval aes_decrypt(const unsigned char *in, unsigned char *out,
                    const aes_decrypt_ctx cx[1]);

do NOT provide ACE support and should not be used if the ACE engine is
available and ACE support is required.

C. Constraints and Optimisation

There are several constraints that have to be observed when ACE is used if
the best performance is to be achieved:

1. As usual the appropriate key set up subroutine must be called before any
   of the above subroutines are used.

2. The AES contexts - aes_encryption_ctx and aes_decryption_ctx - used with
   these subroutines MUST be 16 byte aligned.  Failure to align AES contexts
   will most often cause memory alignment exceptions.

3. The buffers used for inputs, outputs and IVs do not need to be aligned in
   this way but the speed that is achieved will be much higher if this can be
   arranged. In a flat address space (as now typical in 32-bit systems) this
   means that: (a) that the lower nibble of all buffer addresses must be
   zero, and (b) the compiler used must arrange to load the data and stack
   segments on 16 byte address boundaries.  The Microsoft VC++ compiler can
   align all variables in this way (see the example macros for doing this in
   via_ace.h). However it seems that the GCC compiler will only do this for
   static global variables but not for variables placed on the stack, that is
   local variables (a 'hack' for this in GCC is given in via_ace.h).

4. The data length in bytes (len) in calls to the ECB and CBC subroutines
   must be a multiple of the 16 byte block length. An error return will
   occur if this is not so.

5. The data length in all calls to the CFB, OFB and CTR subroutines must also
   be a multiple of 16 bytes if the VIA ACE engine is to be used. Otherwise
   these lengths can be of any value but the subroutines will only proceed at
   full speed for lengths that are multiples of 16 bytes. The CFB, OFB and 
   CTR subroutines are incremental, with subsequent calls continuing from 
   where previous calls finished.  The subroutine aes_mode_reset() can be used 
   to restart a mode without a key change but is not needed after a new key is 
   entered. Such a reset is not needed when the data lengths in all individual
   calls to the AES mode subroutines are multiples of 16 bytes.

6. Note that the AES context contains mode details so only one type of mode
   can be run from a context at any one time.  A reset is necessary if a new
   mode is used without a new context or a new key.

D. Expected Speeds

The speeds that have been obtained using a 1.2 GHz VIA C3 processor with
this code are given below (note that since CTR mode is not available in
the VIA hardware it is not present in the aligned timing figures):

AES Timing (Cycles/Byte) with the VIA ACE Engine (aligned in C)
Mode   Blocks:      1       10      100     1000    Peak Throughput
ecb encrypt      8.25     1.36     0.69     0.63  1.9 Gbytes/second
ecb decrypt      8.75     1.41     0.70     0.64  1.9 Gbytes/second
cbc encrypt     11.56     2.41     1.47     1.38  870 Mbytes/second
cbc decrypt     12.37     2.38     1.47     1.38  870 Mbytes/second
cfb encrypt     11.93     2.46     1.48     1.38  870 Mbytes/second
cfb decrypt     12.18     2.36     1.47     1.38  870 Mbytes/second
ofb encrypt     13.31     3.88     2.92     2.82  425 Mbytes/second
ofb decrypt     13.31     3.88     2.92     2.82  425 Mbytes/second

AES Timing (Cycles/Byte) with the VIA ACE Engine (unaligned in C)
Mode   Blocks:      1       10      100     1000    Peak Throughput
ecb encrypt     17.68     4.31     3.15     3.05  390 Mbytes/second
ecb decrypt     18.12     4.36     3.17     3.06  390 Mbytes/second
cbc encrypt     20.68     5.70     4.39     4.27  280 Mbytes/second
cbc decrypt     21.87     5.75     4.34     4.21  285 Mbytes/second
cfb encrypt     21.06     5.81     4.43     4.31  280 Mbytes/second
cfb decrypt     21.37     5.72     4.36     4.24  285 Mbytes/second
ofb encrypt     22.43     7.23     5.85     5.72  210 Mbytes/second
ofb decrypt     22.43     7.34     5.86     5.73  210 Mbytes/second
ctr encrypt     16.43     6.90     6.00     5.89  205 Mbytes/second
ctr decrypt     16.43     6.90     6.00     5.89  205 Mbytes/second

AES Timing (Cycles/Byte) with the VIA ACE Engine (unaligned assembler)
Mode   Blocks:      1       10      100     1000    Peak Throughput
ecb encrypt     11.87     2.89     1.91     1.83  660 Mbytes/second
ecb decrypt     12.18     2.83     1.97     1.87  640 Mbytes/second
cbc encrypt     14.87     4.13     3.11     3.01  400 Mbytes/second
cbc decrypt     14.43     3.87     2.89     2.80  430 Mbytes/second
cfb encrypt     14.75     4.12     3.10     3.01  400 Mbytes/second
cfb decrypt     14.12     4.10     2.88     2.79  430 Mbytes/second
ofb encrypt     15.25     5.36     4.37     4.27  280 Mbytes/second
ofb decrypt     15.25     5.36     4.36     4.27  280 Mbytes/second
ctr encrypt     13.31     4.79     4.01     3.94  305 Mbytes/second
ctr decrypt     13.31     4.79     4.01     3.94  305 Mbytes/second

    Brian Gladman, Worcester, UK, 23 Mrch 2004