VAMPIRE

eBACS: ECRYPT Benchmarking of Cryptographic Systems

ECRYPT II

Call for stream-cipher software for benchmarking

There is a separate page listing the stream ciphers submitted to eBASC so far (including some submitted to eSTREAM and imported to eBASC), and another page reporting measurements of those stream ciphers.

Example for designers: submitting the A5/7 stream cipher

The top-level directory name crypto_stream is required; it distinguishes stream generation from other operations benchmarked by SUPERCOP, such as crypto_hash and crypto_sign.

The second-level directory name a57 should be a lowercase version of your stream-cipher name. Please omit dashes, dots, slashes, and other punctuation marks; the directory name should consist solely of digits (0123456789) and lowercase ASCII letters (abcdefghijklmnopqrstuvwxyz).

Different stream ciphers must be placed into different second-level directories, even if they are part of the same "family" of stream ciphers. For example, crypto_stream/aes128estream is separate from crypto_stream/aes256estream. One submission tarball can include several stream ciphers. Directory names may be changed by the eBASC managers to resolve conflicts or confusion.

The third-level directory name ref is up to you. Different implementations must be placed into different third-level directories. You can use subdirectories here; for example, crypto_stream/a57/ref might be a reference implementation, crypto_stream/a57/smith/little might be John Smith's little-endian implementation, and crypto_stream/a57/smith/sse3 might be John Smith's SSE3-optimized implementation. One submission tarball can include several implementations.

After choosing the implementation name crypto_stream/a57/ref, create a directory by that name. Inside the crypto_stream/a57/ref directory, create a file named api.h with two lines

     #define CRYPTO_KEYBYTES 32
     #define CRYPTO_NONCEBYTES 8

     #define CRYPTO_VERSION "3.01a"

Next, inside the crypto_stream/a57/ref directory, create a file named stream.c that defines a crypto_stream_a57_ref function and a crypto_stream_a57_ref_xor function:

     int crypto_stream_a57_ref(
       unsigned char *out,
       unsigned long long outlen,
       const unsigned char *n,
       const unsigned char *k
     )
     {
       ... 
       ... the code for your A5/7 implementation goes here
       ... generating stream out[0],out[1],...,out[outlen-1]
       ... using nonce n and key k
       ...
       return 0;
     }

     int crypto_stream_a57_ref_xor(
       unsigned char *out,
       const unsigned char *in,
       unsigned long long inlen,
       const unsigned char *n,
       const unsigned char *k
     )
     {
       ... 
       ... the code for your A5/7 implementation goes here
       ... generating ciphertext out[0],out[1],...,out[inlen-1]
       ... from plaintext in[0],in[1],...,in[inlen-1]
       ... using nonce n and key k
       ...
       return 0;
     }

You can instead define your function as follows:

     #include "crypto_stream.h"

     int crypto_stream(
       unsigned char *out,
       unsigned long long outlen,
       const unsigned char *n,
       const unsigned char *k
     )
     {
       ... 
     }

     int crypto_stream_xor(
       unsigned char *out,
       const unsigned char *in,
       unsigned long long inlen,
       const unsigned char *n,
       const unsigned char *k
     )
     {
       ...
     }

     #define crypto_stream crypto_stream_a57_ref
     #define crypto_stream_xor crypto_stream_a57_ref_xor
     #define crypto_stream_KEYBYTES crypto_stream_a57_ref_KEYBYTES
     #define crypto_stream_NONCEBYTES crypto_stream_a57_ref_NONCEBYTES

You can use names other than stream.c. You can split your code across several files *.c defining various auxiliary functions; the files will be automatically compiled together. Instead of stream.c you can write stream.cc or stream.cpp in C++ or stream.s or stream.S in assembly language. Your implementation is allowed to be unportable; if it doesn't compile on a particular computer, SUPERCOP will skip it and select a different implementation for that computer.

Finally, create a tarball such as a57-ref-3.01a.tar.gz that contains your crypto_stream/a57/ref/api.h, crypto_stream/a57/ref/stream.c, etc. Put the tarball on the web, and send the URL to the eBACS/eBATS/eBASC/eBASH mailing list with a note requesting inclusion in SUPERCOP and subsequent benchmarking.

Example for implementors: submitting a new AES implementation

For example, SUPERCOP already includes several implementations of aes128estream (AES with a 128-bit key in a particular counter mode specified by eSTREAM). One implementation is crypto_stream/aes128estream/e/gladman; another implementation is crypto_stream/aes128estream/e/bernstein/amd64-2; etc. You can submit another implementation such as crypto_stream/aes128estream/smith/sse3 in the same way that the designer of A5/7 can submit crypto_stream/a57/ref; by using the existing name aes128estream you indicate that your software implements exactly the same stream cipher.

Additional documentation

In particular, submitters are encouraged to clearly specify one of the following levels of copyright protection:

• Level 0: There are no known present or future claims by a copyright holder that the distribution of this software infringes the copyright. In particular, the author of the software is not making such claims and does not intend to make such claims.
• Level 10: The author is aware of third parties making such claims, but the author disputes those claims.
• Level 20: The author is aware of third parties making such claims, and the author agrees with the claims, but the author has no financial connections to the copyright.
• Level 30: The author has financial connections to a copyright restricting distribution of this software.

• Level 0: There are no known present or future claims by a patent holder that the use of this software infringes the patent. In particular, the author of the software is not making such claims and does not intend to make such claims.
• Level 10: The author is aware of third parties making such claims, but the author disputes those claims.
• Level 20: The author is aware of third parties making such claims, and the author agrees with the claims, but the author has no financial connections to the patent.
• Level 30: The author has financial connections to a patent restricting use of this software.

Version