Cryptographic competitions |
|
CAESAR call for submissions, draft 1 (2013.04.16)This document is draft 1 of a call for CAESAR public submissions. Please check http://competitions.cr.yp.to for newer drafts. CallCAESAR (Competition for Authenticated Encryption: Security, Applicability, and Robustness) will identify a portfolio of authenticated ciphers that offer advantages over AES-GCM and that are suitable for widespread adoption. Cryptographic algorithm designers are invited to submit public proposals of authenticated ciphers to CAESAR. DeadlinesFirst-round submission PDF files must be received by the caesar-submissions email address between 2013.12.01 and 2014.01.15 23:59 GMT. This email must have subject line precisely round 1 submission: NAME where NAME is replaced by the cipher name. After 2014.01.15 the CAESAR secretary will publish all first-round submissions received, except that the CAESAR secretary may exclude submissions that do not meet the requirements below. Reference software implementations must be received by the caesar-submissions email address between 2013.12.01 and 2014.02.15 23:59 GMT. This email must have subject line precisely round 1 software: NAME where NAME is replaced by the cipher name. Functional requirementsAn authenticated cipher is a function with five byte-string inputs and one byte-string output. The five inputs are a variable-length plaintext, variable-length additional data, a fixed-length (possibly 0-bit) private message number, a fixed-length (possibly 0-bit) public message number, and a fixed-length key. The output is a variable-length ciphertext. The first four inputs have different security purposes, as indicated in the following table:
Bytes are integers between 0 and 255 inclusive. Authenticated ciphers defined in terms of higher-level objects must specify the relationship between those objects and byte strings: for example, little-endian encoding of 32-bit integers. Submitters are advised that many existing applications use 80-bit, 128-bit, or 256-bit keys; 96-bit or 104-bit public message numbers; 0-bit private message numbers; and 32, 64, 96, 128, or 160 extra bits (used for authentication) in ciphertext compared to plaintext. However, submissions are not required to support these sizes, and are not limited to these sizes. Each submission specifies a family of authenticated ciphers. Family members may vary in external parameters such as key length, and may vary in submission-defined parameters such as the number of "rounds". However, a submission is also permitted to specify a family containing just 1 authenticated cipher. Each submission must include a list of at most 10 recommended parameter sets. Software requirementsEach first-round submission must be accompanied by a portable reference software implementation to support public understanding of the cipher, cryptanalysis, verification of subsequent implementations, etc. This implementation must cover all recommended parameter sets. This implementation is expected to be optimized for clarity, not for performance; the official CAESAR benchmarks will report the fastest implementation on each platform, and will thus disregard the reference implementation on any platform where it is superseded by faster implementations. Submissions without working reference software implementations will not be selected for the second round. A minimal reference implementation of (e.g.) AES-128-GCM consists of two files: crypto_aead/aes128gcm/ref/api.h and crypto_aead/aes128gcm/ref/encrypt.c. There are three levels of directory names:
The file api.h has four lines: #define CRYPTO_KEYBYTES 16 #define CRYPTO_NPRIVBYTES 0 #define CRYPTO_NPUBBYTES 12 #define CRYPTO_ABYTES 16 This indicates that the AES-128-GCM key has 16 bytes, that the private message number has 0 bytes, that the public message number has 12 bytes, and that the ciphertext is at most 16 bytes longer than the plaintext. (A typical authenticated cipher has a constant gap between plaintext length and ciphertext length, but the requirement here is to have a constant limit on the gap.) The file encrypt.c has the following structure: #include "crypto_aead.h" int crypto_aead( unsigned char *c,unsigned long long *clen, const unsigned char *m,unsigned long long mlen, const unsigned char *ad,unsigned long long adlen, const unsigned char *npriv, const unsigned char *npub, const unsigned char *k ) { ... ... the code for the cipher implementation goes here, ... generating a ciphertext c[0],c[1],...,c[*clen-1] ... from a plaintext m[0],m[1],...,m[mlen-1] ... and additional data ad[0],ad[1],...,ad[adlen-1] ... and private message number npriv[0],npriv[1],... ... and public message number npub[0],npub[1],... ... and secret key k[0],k[1],... ... return 0; } int crypto_aead_open( unsigned char *m,unsigned long long *mlen, unsigned char *npriv, const unsigned char *c,unsigned long long clen, const unsigned char *ad,unsigned long long adlen, const unsigned char *npub, const unsigned char *k ) { ... ... the code for the cipher implementation goes here, ... generating a plaintext m[0],m[1],...,m[*mlen-1] ... and private message number npriv[0],npriv[1],... ... from a ciphertext c[0],c[1],...,c[clen-1] ... and additional data ad[0],ad[1],...,ad[adlen-1] ... and public message number npub[0],npub[1],... ... and secret key k[0],k[1],... ... return 0; } The crypto_aead_open function must return -1 if the ciphertext is not valid, i.e., if the ciphertext does not equal the encryption of any (plaintext,private message number) pair with this additional data, public message number, and secret key. The crypto_aead and crypto_aead_open functions may return other negative numbers to indicate other failures (e.g., memory-allocation failures). The file crypto_aead.h is not included in the reference implementation; it is created automatically by the benchmarking framework. A reference implementation can use names other than encrypt.c. It can split its code across several files *.c defining various auxiliary functions; the files will be automatically compiled together. Instead of encrypt.c it can include encrypt.cc or encrypt.cpp in C++. The reference implementation is packaged into a tarball, such as aes128gcm.tar.gz for AES-128-GCM. Hardware requirementsEach submission selected for the second round will also be required to include a reference hardware design (i.e., a reference implementation in the VHDL or Verilog languages) by 2015.03.15. Details of the hardware API have not yet been specified. Submission requirementsEach submission consists of a single PDF file with the following sections:
Version: This is version 2014.01.27 of the caesar-call-1.html web page. |