Guidelines for Submissions of Modes of Operation

Submissions should specify a mode of operation for a symmetric (secret) key block cipher algorithm.  At a minimum, the mode should support underlying block ciphers with key-block combinations of 128-128, 192-128, and 256-128 bits.  However, the specification should be generic – i.e., written to handle other key-block combinations, if they can be supported.  Example modes include, but are not limited to, techniques for performing encryption, message authentication, hashing, and random bit generation.  It will be helpful to receive variations of Counter mode arising from alternative methods/guidelines for prescribing the generation of counters.

NIST requests that submissions of modes of operation include the following six items:

• Cover Sheet
• Mode Specification
• Summary of Properties
• Test Vectors
• Performance Estimates
• Intellectual Property Statements/Agreements/Sisclosures

These items are discussed below.

Cover Sheet

The cover sheet shall contain the following information:

• name of submitted mode of operation;
• principal submitter’s name, telephone, fax, organization, postal address, e-mail address;
• name(s) of auxiliary submitter(s);
• name of mode’s inventor(s)/developer(s);
• name of owner, if any, of the mode (typically, the owner will be the same as the submitter).

Back to Top

Mode Specification

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.

Back to Top

Summary of Properties

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

Back to Top

Test Vectors

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 here.
   
   
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.

Back to Top

Performance Estimates

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.

Back to Top

Intellectual Property Statements/Agreements/Disclosures

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.