VAMPIRE

eBACS: ECRYPT Benchmarking of Cryptographic Systems

ECRYPT II

Call for public-key encryption software for benchmarking

There is a separate page listing the cryptosystems submitted so far, and another page reporting measurements of those cryptosystems. Note that the eBATS project also includes public-key signature systems and Diffie–Hellman systems.

Example for designers: submitting the Stinger system

The top-level directory name crypto_encrypt is required; it distinguishes public-key encryption from other operations benchmarked by SUPERCOP, such as crypto_hash and crypto_sign.

The second-level directory name stinger should be a lowercase version of your system's 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 cryptosystems must be placed into different second-level directories, even if they are part of the same "family" of systems. For example, crypto_encrypt/ronald2048 is separate from crypto_encrypt/ronald4096. One submission tarball can include several cryptosystems in separate directories. Directory names may be changed by the eBATS 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_encrypt/stinger/ref might be a reference implementation, crypto_encrypt/stinger/smith/little might be John Smith's little-endian implementation, and crypto_encrypt/stinger/smith/sse3 might be John Smith's SSE3-optimized implementation. One submission tarball can include several implementations.

After choosing the implementation name crypto_encrypt/stinger/ref, create a directory by that name. Inside the crypto_encrypt/stinger/ref directory, create a file named api.h with three lines

     #define CRYPTO_SECRETKEYBYTES 256
     #define CRYPTO_PUBLICKEYBYTES 64
     #define CRYPTO_BYTES 48

     #define CRYPTO_VERSION "3.01a"

Next, inside the crypto_encrypt/stinger/ref directory, create a file named encrypt.c that defines the following three functions:

     int crypto_encrypt_stinger_ref_keypair(
       unsigned char *pk,
       unsigned char *sk
     )
     {
       ... 
       ... the code for your Stinger implementation goes here,
       ... generating public key pk[0],pk[1],...
       ... and secret key sk[0],sk[1],...
       ...
       return 0;
     }
     
     int crypto_encrypt_stinger_ref(
       unsigned char *c,unsigned long long *clen,
       const unsigned char *m,unsigned long long mlen,
       const unsigned char *pk
     )
     {
       ... 
       ... the code for your Stinger implementation goes here,
       ... generating a ciphertext c[0],c[1],...,c[*clen-1]
       ... from a plaintext m[0],m[1],...,m[mlen-1]
       ... using public key pk[0],pk[1],...
       ...
       return 0;
     }

     int crypto_encrypt_stinger_ref_open(
       unsigned char *m,unsigned long long *mlen,
       const unsigned char *c,unsigned long long clen,
       const unsigned char *sk
     )
     {
       ... 
       ... the code for your Stinger implementation goes here,
       ... decrypting a ciphertxt c[0],c[1],...,c[clen-1]
       ... under secret key sk[0],sk[1],...
       ... and producing plaintext m[0],m[1],...,m[*mlen-1]
       ...
       return 0;
     }

You can instead define your functions as follows:

     #include "crypto_encrypt.h"

     int crypto_encrypt_keypair(
       unsigned char *pk,
       unsigned char *sk
     )
     {
       ... 
     }

     int crypto_encrypt(
       unsigned char *c,unsigned long long *clen,
       const unsigned char *m,unsigned long long mlen,
       const unsigned char *pk
     )
     {
       ...
     }

     int crypto_encrypt_open(
       unsigned char *m,unsigned long long *mlen,
       const unsigned char *c,unsigned long long clen,
       const unsigned char *sk
     )
     {
       ...
     }

     #define crypto_encrypt crypto_encrypt_stinger_ref
     #define crypto_encrypt_open crypto_encrypt_stinger_ref_open
     #define crypto_encrypt_keypair crypto_encrypt_stinger_ref_keypair
     #define crypto_encrypt_SECRETKEYBYTES crypto_encrypt_stinger_ref_SECRETKEYBYTES
     #define crypto_encrypt_PUBLICKEYBYTES crypto_encrypt_stinger_ref_PUBLICKEYBYTES
     #define crypto_encrypt_BYTES crypto_encrypt_stinger_ref_BYTES

You can use names other than encrypt.c. You can split your code across several files *.c defining various auxiliary functions; the files will be automatically compiled together. Instead of encrypt.c you can write encrypt.cc or encrypt.cpp in C++ or encrypt.s or encrypt.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 stinger-ref-3.01a.tar.gz that contains your crypto_encrypt/stinger/ref/api.h, crypto_encrypt/stinger/ref/encrypt.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 McEliece implementation

For example, SUPERCOP already includes crypto_encrypt/mceliece/ref, an implementation of a particular variant of the McEliece cryptosystem. You can submit another implementation such as crypto_encrypt/mceliece/smith/sse3 in the same way that the designer of Stinger can submit crypto_encrypt/stinger/ref; by using the existing name mceliece you indicate that your software implements exactly the same cryptosystem.

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