User Tools

Site Tools


zoo_guidelines

This is an old revision of the document!


Authenticated Encryption Zoo Guidelines

This wiki site specifies the guidelines for the AE Zoo. While everyone in the cryptographic community are encourated to participate and contribute to the Zoo, we, as zookeepers, hope that contributer will adhere to the guidelines posted on this page.

Guidelines: Features of AE Schemes

The guidelines in this section refer to the AE scheme overview table found on the Authenticated Encryption Zoo front page. In the following we specify the meaning of each column of the table and give what we consider valid options for each column. If you feel that a valid option is missing for a particular column, we encourage you to e-mail aezoo@compute.dtu.dk with your suggestions for changes.

Without a doubt, opinions vary as to what e.g. an online cipher is. With our valid options below, we try to capture all definitions or levels of which a certain property is obtained, allowing for a good comparison of the candidates.

For candidates containing several, say K, parameter sets, and where properties differ across these parameter sets, we suggest to comma-separate the properties for each set, such that the ith option in the comma-separated lists across all columns of the table correspond to the same parameter set of that particular candidate.

We would like to acknowledge the slides from Daghstuhl 2014 by Bart Preneel, from which we have drawn inspiration for these guidelines.

Type

Specify the type of the scheme(s). The format should be MAINTYPE/SUBTYPE, where MAINTYPE is one of

  • BC (when the scheme is based on a block cipher)
  • P (when the scheme is based on a permutation)
  • Other (when none of the first two apply)

and SUBTYPE is one of

  • AES-K (when the underlying block cipher is unmodified AES with key size K. Omit -K for AES-128)
  • AES-K[n] (when the underlying block cipher is n rounds of AES with key size K. Omit -K for AES-128)
  • AES-like (when based on some modified version of AES)
  • Named BC (e.g. LED-80, when some other named block cipher is used)
  • Sponge[p] (when based on a Sponge-like construction. Can replace p with a named permutation, which can either be part of the submission or existing permutation, e.g. Keccak)
  • FSR (based on feedback shift register(s))
  • ARX (modular addition, rotation and XOR)
  • LRX (logical operations, rotation and XOR)
  • Comp[f] (when based on a compression function. Can replace f with a named compression function, which can either be part of the submission or existing permutation, e.g. SHA256)

To specify several options for parameter sets, curly braces can be used, e.g. BC/{AES,LED-80} for a block cipher based scheme which uses AES-128 and LED-80.

Parallelizable (E/D)

Specify separately whether the scheme is parallelizable in encryption (E) and decryption (D). Valid options for both cases are:

  • Fully (if there is a separation of the data into b chunks, such that each of these chunks of data can be fully processed independently of the others, allowing for constant overhead)
  • Partly (if there is a separation of the data into b chunks, such that each of these chunks of data can partly be processed independently of the others, allowing for constant overhead)
  • No (if none of the above apply)

Online (E/D)

Specify separately whether the scheme is online in encryption (E) and decryption (D). Valid options for both cases are:

  • Fully (if the scheme can process data, and output processed data, on-the-fly, using only constant memory, and not needing to know the length of data)
  • Needs length (when the above applies, except one needs to know the length of data)
  • No

Nonce MR

State the schemes resistance towards nonce misuse. Here, the nonce is defined as the tuple consisting of private message number and public message number. Valid options are:

  • MAX (leaks only whether a plaintext is repeated)
  • MAX online (leaks only the LCP (longest common prefix) of plaintexts)
  • LCP+X (leaks LCP and XOR of next plaintext block)
  • A+N (when there is some level of security if all associated data + nonce pairs are unique)
  • None (when all security is lost if nonce is repeated)

Inverse free

State whether the scheme requires the inverse of the underlying primitive. ONLY applicable for block cipher- or permutation-based modes. Valid options are:

  • Yes
  • No
  • N/A (for when not applicable, see above)
zoo_guidelines.1412254510.txt.gz · Last modified: 02/10/2014 12:55:10 by damianv