Plans for the Rijndael crypto system in Maxima/Lisp.
More...
Go to the source code of this file.
Detailed Description
Plans for the Rijndael crypto system in Maxima/Lisp.
 Todo:
 Tidy todos and update milestones

Otherwise, there are only minor issues, including basic documentation remaining, which should make up the todos for 0.0.11 and 0.0.12, after which point we should read 0.1.

Other todos which we do not intend to do in the immediate future should then be moved to after 0.1.

DONE Milestone 0.0.10 should be marked as done and remaining issues moved to 0.0.11.
 Todo:
 Improving tests

We need a list of test vectors for AES and smallscale AES.

For test vectors, see:

[The Design of Rijndael; Daemen and Rijmen].

[Algebraic Aspects of the Advanced Encryption Standard; Cid, Murphy and Robshaw].

NIST AES known answer test: http://csrc.nist.gov/groups/STM/cavp/documents/aes/KAT_AES.zip .

Comparing to the Sage system; see "Generating test vectors" in CryptoSystems/Rijndael/plans/SmallScaleAdvancedEncryptionStandard.hpp.

This list should be expanded, as we find more sources.

These vectors should be used throughout the AES test system.

These vectors and those already used must be cited!

We must also consider, for each test, how well we cover the space of possible inputs for our tests.
 Todo:
 natl vs nat_l

For the AES, we offer the possibility of using lists of natural numbers from 0 to 255 as input to the AES encryption and decryption.

These functions are:

rijn_natl2m;

rijn_m2natl;

ss_natl2m;

ss_m2natl;

ss_encrypt_natl;

ss_decrypt_natl;

aes_encrypt_nat_l;

aes_decrypt_nat_l;

ss_encrypt_natl;

ss_decrypt_natl.

Some functions use the suffix "natl", some "nat_l".

The use of either "natl" or "nat_l" should be standardised.

Should we use "int" instead of "nat", as we also have "aes2int"?

It seems best to use "intl" as we use "int" elsewhere in the library; "intl" is a type as a whole, and the "_" just makes the name unnecessarily longer.

At the same time, other datatypes should be documented, and standardised if necessary.
 Todo:
 Notions and notations

Introduce systematic notations and abbreviations for basic "data types".

At present there are several data types within the AES implementation, namely:

Byte (represented as a polynomial or as an integer).

Matrices of polynomials representing blocks.

List of integers representing blocks.

There are also other representations including:

Representing the whole AES block as an integer (see aes_int).

Representing the whole AES block as a hexidecimal string (see aes_encrypt_hex).

Given future generalisations, it seems best to consider

polynomials  signified by "_p".

integers  signified by "_i".

Matrices of polynomials  signified by "_pm" (i.e. polynomial matrix).

List of integers  signified by "_il" (i.e. integer list).

Hexidecimal strings  signified by "_hex".

There is still the issue of some functions that use different, more specific data types; either convenience functions etc (using the Rijndael byte field, for example), or many other fields or permutations, if later generalisations are considered.

For the Rijndael byte field, perhaps "_b" would be appropriate?

What is an appropriate convention for others? Some general scheme that can be used for all or most of such types?
 Todo:
 Modularising the Rijndaelimplementation

The following ideas need to be integrated into the plans (after milestone 0.1).

It would also be interesting to have an expressionbased implementation.

Based on the basic abstract operations (perhaps there are options).

Likely the whole creates an expression which is too big (since expression cannot reuse subterms).

But oneround expressions should be feasible.

It would be better to parameterise the AES functions using global variables which can then be overriden in blocks etc (simulating optional function parameters). Otherwise many options must be specified for which a default is usually the most appropriate.

DONE All fieldoperations should be abstracted away (most obvious, by using an Sbox function as parameter).

DONE And then we provide different implementations:

As now.

Via tablelookup (using arrays; this is then much faster).

Also trivial (other) functions, for easy "variations" of Rijndael.
 Todo:
 Docus and Demos

Demos are needed of the system.

Docus are needed of the system.
 Todo:
 Coding Standards

Most important: Follow the standard coding practice!

Use named constants.

Do not use abbreviated names except of wellestablished cases.

Add code documentation for the specification of functions.
Furthermore declarations of local variables are needed.

(DONE no longer an issue, as we don't use the gf package now) The finite field packages function names, along with maximas syntax make things a little verbose and perhaps a little longer than is really necessary although this is more of a nuisance than a real problem. OK : Why is there a nuisance? In general in the OKlibrary "full" names are appreciated; is this somewhat special here? MG : It only arose as an issue due to my wish to keep the code relatively short and concise and so while trying to keep to a fixed line length of say 80 characters, this meant that the code become much longer. The syntax when dealing with the binary operations as well doesn't seem to immediately make clear things such as associativity when reading, in my mind, potentially making simplification more difficult. I imagine that this is more my unfamiliarity with the language and more importantly problems occuring due to lack of design, as suggested below.
Definition in file general.hpp.