general.hpp File Reference

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.

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.
Improving tests
  • We need a list of test vectors for AES and small-scale 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 through-out 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.
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.
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?
Modularising the Rijndael-implementation
  • The following ideas need to be integrated into the plans (after milestone 0.1).
  • It would also be interesting to have an expression-based implementation.
    1. Based on the basic abstract operations (perhaps there are options).
    2. Likely the whole creates an expression which is too big (since expression cannot re-use subterms).
    3. But one-round 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 field-operations should be abstracted away (most obvious, by using an S-box function as parameter).
  • DONE And then we provide different implementations:
    1. As now.
    2. Via table-lookup (using arrays; this is then much faster).
    3. Also trivial (other) functions, for easy "variations" of Rijndael.
Docus and Demos
  • Demos are needed of the system.
  • Docus are needed of the system.
Coding Standards
  • Most important: Follow the standard coding practice!
    1. Use named constants.
    2. Do not use abbreviated names except of well-established cases.
    3. 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.