A complete written specification of the mode of operation should be provided, including all mathematical equations, tables, diagrams, and parameters that are needed to implement the mode. NIST encourages submitters to elaborate on the intended use(s) of the mode, the design rationale, the relevant properties, proofs (if any), the comparison with other modes, and the mode’s overall advantages/disadvantages.

To assist NIST and the public to draw comparisons and contrasts between the various candidate modes, the submissions should include a table or outline that identifies the following characteristics:

1. Security Function (encryption, authentication, authenticated encryption, hashing, pseudorandom bit generation, etc.)
2. Error Propagation (e.g., none, m bits, n blocks, infinite)
3. Synchronization
4. Parallelizability (e.g., sequential, interleaved, fully parallelizable)
5. Keying Material Requirements (e.g., 1 key, 2 keys)
6. Counter/IV/Nonce Requirements
7. Memory Requirements
8. Pre-processing Capability
9. Message Length Requirements (e.g., arbitrary length, padding necessary)
10. Ciphertext Expansion (e.g., none, m bits, n blocks)
11. Other Characteristics

Test vectors should be included in submissions to provide outside implementers with some indication that their implementations of the mode are valid; however, the test vectors need not systematically exercise every element of the mode. The test vectors should meet the following requirements:

1. At a minimum, test vectors should be given for implementations in which the underlying block cipher is the AES algorithm, for 128, 192, and 256 bit keys. A specification of AES is available.
2. All input values that are necessary to implement the mode, such as plaintext, keys, initialization vectors, random values, or counters, should be specified.
3. Each test should be submitted electronically in a separate file; the files may be compressed using PKZIP or GNUZIP to conserve disk space.
4. Each test file should be clearly labeled with header information that lists the algorithm name and a description of the test, including the sizes of keys and messages.
5. Within each test file, each input and output value should be clearly labeled.

Where possible, performance should be estimated in terms of the number of invocations of the underlying block cipher.  If the estimate depends on the underlying block cipher, then, at a minimum, estimates should be provided for the AES algorithm.

If actual performance data is given, the conditions of the implementation should be described in sufficient detail so that the estimates could be verified by the public.

Submitters should disclose any intellectual property that they hold on the modes in their submissions, and any other intellectual property that is relevant to any of the modes.  Submitters should also provide statements describing what, if any, licensing agreement will be required for the use of their mode.