Implementation Experience with AES Candidate Algorithms Second AES Conference Implementation Experience with AES Candidate Algorithms by Dr Brian Gladman, UK Introduction necessary whereas others have gone to considerable lengths to explain how their algorithm can be This paper presents experience gained during the implemented efficiently within a range of processor implementation of each of the 15 AES candidate environments. algorithms and seeks to provide fair and accurate comparisons in respect of implementation and In some specifications, the way in which an performance issues. algorithm is described is quite different to the way in which it is most efficiently implemented. Moreover, This paper considers the following topics: there are AES specifications that omit important · the effectiveness of each of the specifications details of the mathematical constructions that they from an implementation perspective use. Whilst such omissions do not prevent implementation, they lead to significant extra work · the feasibility of implementing the algorithms that could easily be avoided by providing the details using these specifications alone concerned. · the effort involved in implementing each Byte Order algorithm to a reasonable level of efficiency An area of general difficulty in a number of the · The comparative performance of the AES specifications is in the conventions used for byte candidate algorithms when coded in C for order within multiple byte values (this will be Pentium Pro and Pentium II processors. referred to here as ‘endianness’). The Algorithm Specifications Several of the specifications contain errors caused by The Character of the Specifications confusion about byte order whilst others switch between different byte order conventions in a way The specifications of the 15 AES candidates vary that seems certain to lead to confusion. widely in form, with some using a formal mathematical style while others rely on a Byte order on input and output is a particular area of combination of text, diagrams and pseudo code. uncertainty. Quite a few AES candidates avoid the While each of these approaches can support correct endian issue by defining their inputs and outputs as implementation, they are significantly different in 32-bit (or 64-bit) quantities so that byte order and any their ease of use from an implementation perspective. associated conversion costs are external to the For example, although formality is often valuable in algorithm. Some algorithms don’t specify their security critical code, it is surprising how difficult it endianness and hence force prospective implementers is to avoid semantic ambiguities that can undermine to discover this using test vectors. Still others do precision and lead to implementation errors. On the specify an endian convention but then proceed to use other hand, it can also be extremely difficult to the opposite convention in some or all of their describe some features textually in an unambiguous specifications. way. In the authors experience this has been by far the Given these factors the most helpful approaches are most troublesome issue in implementing and testing those that involve descriptions using more than one the 15 AES candidate algorithms. In fact the form. Although descriptive redundancy introduces development process is compounded because the the opportunity for inconsistency, more importantly it standard test vectors for variable text and variable reduces the risk that errors will persist and provide a keys do not contain any ‘endian neutral’ vectors of basis for erroneous implementation. Consequently, the kind that are useful in resolving such ambiguities. specifications that employ a mixture of text, Although in an ideal world the specifications would diagrams and pseudo code will generally be be precise and unambiguous on their byte order preferable to those that rely on one form of conventions, experience suggests that this is unlikely description alone. to be achieved in practice. Consequently it is Provision of Guidance on Implementation recommended that the standard sets of test vectors for variable text and variable keys should be The AES algorithm specifications also vary widely is augmented with (at least) an ‘all 0’ vector as an aid in in their coverage of implementation options and resolving such difficulties. optimisation opportunities. Some design teams have clearly taken the view that such guidance is not It is not clear whether byte order on input and output is an internal or external issue from the viewpoint of Dr B. R. Gladman, 28th February 1999 page 1 Implementation Experience with AES Candidate Algorithms Second AES Conference the AES algorithms. However, in the following to be ‘little-endian’ conventions when, in fact, the commentary it will be assumed that the AES algorithm is ‘big-endian’. specifications are intended to provide a basis for This situation arises because section 1.1 numbers implementations that produce results that are the entities from ‘right to left’ whereas the main same on processors with different byte order specification uses ‘left to right’ numbering. This conventions. notational inconsistency is unfortunate and seems Comments on Specific Specifications certain to cause confusion. CAST-256 A supporting document provides very helpful implementation guidance. With one exception, this specification fully describes the algorithm and hence allows implementation FROG without reference to source code. The exception is A combination of text, diagrams and pseudo code is byte order on input/output, which is big-endian but used to describe FROG. This fully supports does not appear to be specified. implementation and the provision of extensive No implementation guidance is provided but the pseudo code makes implementation guidance largely algorithm is largely conventional and this makes this unnecessary. omission a relatively minor one. However, the pseudo code is confusing in parts CRYPTON because it specifies redundant code (in the makePermutation procedure the line ‘if index > last The CRYPTON specifications are all well presented then index <= 0’). and provide the details needed for implementation from scratch. The algorithm defines and uses little Byte order conventions are given. endian byte order. Rounds are numbered from 1, not HPC–Medium 0, and when this is combined with reference to ‘even’ and ‘odd’ rounds, there is a small amount of room for HPC is an algorithm that involves many constituent confusion. sub-algorithms, only one of which is needed to meet the AES requirement. The comments here only cover There is limited implementation guidance. The HPC-Medium, the AES compliant component. ‘version 1’ algorithm is an improvement on earlier versions from an implementation viewpoint because The HPC specification relies heavily on actual C the key-schedule is easier to understand. code sequences to describe its operation and this makes its implementation relatively easy. DEAL The input to HPC is defined in terms of 64 bit words The DEAL specification is sound but relies heavily and care is taken to define character order within on the separate specification of DES. Input/output these as ‘little-endian’. However input and output byte order is not specified but appears to be little byte order seems to be big-endian in practice (byte endian. There is almost no implementation guidance. order changes were needed to match the test vectors DFC on a little-endian processor). The DFC specification is complete but originally LOKI97 contained errors that prevented correct The LOKI specification supports implementation implementation from scratch. The corrected version except for input and output byte order. Internal byte fully supports this. order appears to be little endian but input and output Care is taken to specify big endian byte order. seem to use big-endian conventions. No Although the main specification document gives very implementation guidance is provided. little guidance on efficient implementation, an MAGENTA ancillary document giving some help has since become available. The specification is accurate and complete but is very compact and quite difficult to follow. There is no E2 implementation guidance. Byte ordering is implied to The E2 specification uses an effective combination of be little endian. formal text and diagrams to describe this algorithm. MARS Nevertheless, byte order conventions are confusing since section 1.1 of the document sets out what seem The MARS specification is excellent form an implementation viewpoint since it uses text, diagrams Dr B. R. Gladman, 28th February 1999 page 2 Implementation Experience with AES Candidate Algorithms Second AES Conference and pseudo code to give a very clear overall implement Serpent efficiently without reference to description of the algorithm. The input/output byte supplied source code since the specification does not order convention used is little endian and clearly provide any details of how the S boxes can be specified as such. implemented as Boolean functions. However, since this algorithm is of non-US origin the header files With the exception of an ambiguity in the ‘key containing these definitions are freely available. fixing’ step (now corrected) it was possible to fully implement MARS from its specification. Twofish The extensive pseudo code provided for MARS The Twofish specification is very comprehensive and makes implementation relatively easy. Although this contains all the information needed to implement the reduces the need for implementation