VAMPIRE	eBACS: ECRYPT Benchmarking of Cryptographic Systems	ECRYPT II

Call for public-key Diffie–Hellman secret-sharing software for benchmarking

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

Example for designers: submitting the XTR-512 system

The top-level directory name crypto_dh is required; it distinguishes Diffie–Hellman functions from other operations benchmarked by SUPERCOP, such as crypto_hash and crypto_sign.

The second-level directory name xtr512 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 Diffie–Hellman functions must be placed into different second-level directories, even if they are part of the same "family" of functions. For example, crypto_dh/nistp256 is separate from crypto_dh/nistp224. One submission tarball can include several Diffie–Hellman functions 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_dh/xtr512/ref might be a reference implementation, crypto_dh/xtr512/smith/little might be John Smith's little-endian implementation, and crypto_dh/xtr512/smith/sse3 might be John Smith's SSE3-optimized implementation. One submission tarball can include several implementations.

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

     #define CRYPTO_SECRETKEYBYTES 192
     #define CRYPTO_PUBLICKEYBYTES 64
     #define CRYPTO_BYTES 64

Next, inside the crypto_dh/xtr512/ref directory, create a file named dh.c that defines a crypto_dh function and a crypto_dh_keypair function:

     #include "crypto_dh.h"

     int crypto_dh_keypair(
       unsigned char *pk,
       unsigned char *sk
     )
     {
       ... 
       ... the code for your XTR-512 implementation goes here,
       ... generating public key pk[0],pk[1],...
       ... and secret key sk[0],sk[1],...
       ...
       return 0;
     }
     
     int crypto_dh(
       unsigned char *out,
       const unsigned char *pk,
       const unsigned char *sk
     )
     {
       ... 
       ... the code for your XTR-512 implementation goes here,
       ... generating shared secret out[0],out[1],...
       ... from public key pk[0],pk[1],...
       ... and secret key sk[0],sk[1],...
       ...
       return 0;
     }

You can use names other than dh.c. You can split your code across several files *.c defining various auxiliary functions; the files will be automatically compiled together. You must include crypto_dh.h for any file referring to the crypto_dh_* functions. The file crypto_dh.h is not something for you to write or submit; it is created automatically by SUPERCOP. See the SUPERCOP tips for more advice and options.

Finally, create a tarball such as xtr512-ref-3.01a.tar.gz that contains your crypto_dh/xtr512/ref/api.h, crypto_dh/xtr512/ref/dh.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.

Version