VAMPIRE

eBACS: ECRYPT Benchmarking of Cryptographic Systems


ECRYPT II
General information: Introduction eBASH eBASC eBAEAD eBATS SUPERCOP XBX Computers
How to submit new software: Tips Hash functions Stream ciphers Auth ciphers DH functions Public-key encryption Public-key signatures
List of primitives measured: SHA-3 finalists All hash functions Stream ciphers CAESAR candidates All auth ciphers DH functions Public-key encryption Public-key signatures
Measurements indexed by machine: SHA-3 finalists All hash functions Stream ciphers CAESAR candidates All auth ciphers DH functions Public-key encryption Public-key signatures

Call for public-key signature software for benchmarking

Are you a designer or implementor of a public-key signature system? Would you like your software professionally benchmarked on many computers, producing stable, reliable, verifiable timings that reflect the performance that signature-system users will see? This page explains how to submit your software to the eBATS project. Formal submission requirements have been kept to a minimum, but your software needs to follow a few naming conventions so that it can be benchmarked by SUPERCOP.

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

Example for designers: submitting the Square2048 system

Let's say you're the designer of Square2048, a signature system with a 2048-bit secret key and a 680-bit public key, and you want to submit your Square2048 software to eBATS. Your submission can be as simple as two files, crypto_sign/square2048/ref/api.h and crypto_sign/square2048/ref/sign.c. Here is an explanation of what these files contain and what additional options you have.

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

The second-level directory name square2048 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 signature systems must be placed into different second-level directories, even if they are part of the same "family" of systems. For example, crypto_sign/ecdonaldp224 is separate from crypto_sign/ecdonaldp256. One submission tarball can include several signature systems 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_sign/square2048/ref might be a reference implementation, crypto_sign/square2048/smith/little might be John Smith's little-endian implementation, and crypto_sign/square2048/smith/sse3 might be John Smith's SSE3-optimized implementation. One submission tarball can include several implementations.

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

     #define CRYPTO_SECRETKEYBYTES 256
     #define CRYPTO_PUBLICKEYBYTES 85
     #define CRYPTO_BYTES 128
indicating that your software uses a 256-byte (2048-bit) secret key, an 85-byte (680-bit) public key, and at most 128 bytes of overhead in a signed message compared to the original message. You can also add a line
     #define CRYPTO_VERSION "3.01a"
indicating that this is version 3.01a of your software; SUPERCOP will report this information in its database of measurements. You can also add further lines defining macros and declaring functions with names starting crypto_sign_square2048_ref_.

Next, inside the crypto_sign/square2048/ref directory, create a file named sign.c that defines the following three functions:

     int crypto_sign_square2048_ref_keypair(
       unsigned char *pk,
       unsigned char *sk
     )
     {
       ... 
       ... the code for your Square2048 implementation goes here,
       ... generating public key pk[0],pk[1],...
       ... and secret key sk[0],sk[1],...
       ...
       return 0;
     }
     
     int crypto_sign_square2048_ref(
       unsigned char *sm,unsigned long long *smlen,
       const unsigned char *m,unsigned long long mlen,
       const unsigned char *sk
     )
     {
       ... 
       ... the code for your Square2048 implementation goes here,
       ... generating a signed message sm[0],sm[1],...,sm[*smlen-1]
       ... from original message m[0],m[1],...,m[mlen-1]
       ... under secret key sk[0],sk[1],...
       ...
       return 0;
     }

     int crypto_sign_square2048_ref_open(
       unsigned char *m,unsigned long long *mlen,
       const unsigned char *sm,unsigned long long smlen,
       const unsigned char *pk
     )
     {
       ... 
       ... the code for your Square2048 implementation goes here,
       ... verifying a signed message sm[0],sm[1],...,sm[smlen-1]
       ... under public key pk[0],pk[1],...
       ... and producing original message m[0],m[1],...,m[*mlen-1]
       ...
       return 0;
     }
Your functions must have exactly the prototypes shown here. For example, the keypair function must have an unsigned char pointer for the public-key output and then an unsigned char pointer for the secret-key output. Your functions must return 0 to indicate success, -1 to indicate verification failure, or other negative numbers to indicate other failures (e.g., out of memory).

You can instead define your functions as follows:

     #include "crypto_sign.h"

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

     int crypto_sign(
       unsigned char *sm,unsigned long long *smlen,
       const unsigned char *m,unsigned long long mlen,
       const unsigned char *sk
     )
     {
       ...
     }

     int crypto_sign_open(
       unsigned char *m,unsigned long long *mlen,
       const unsigned char *sm,unsigned long long smlen,
       const unsigned char *pk
     )
     {
       ...
     }
The file crypto_sign.h is not something for you to write; it is created automatically by SUPERCOP. It contains various macros such as
     #define crypto_sign crypto_sign_square2048_ref
     #define crypto_sign_open crypto_sign_square2048_ref_open
     #define crypto_sign_keypair crypto_sign_square2048_ref_keypair
     #define crypto_sign_SECRETKEYBYTES crypto_sign_square2048_ref_SECRETKEYBYTES
     #define crypto_sign_PUBLICKEYBYTES crypto_sign_square2048_ref_PUBLICKEYBYTES
     #define crypto_sign_BYTES crypto_sign_square2048_ref_BYTES
and a function declaration that will catch errors in the prototypes of crypto_sign etc.

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

Submitting a new implementation of an existing signature system is just like submitting a new signature system. You simply have to put the new implementation into a new third-level directory under the same second-level directory.

For example, SUPERCOP already includes crypto_sign/ecdonaldp256/openssl, an implementation of NIST P-256 ECDSA. You can submit another implementation such as crypto_sign/ecdonaldp256/smith/sse3 in the same way that the designer of Square2048 can submit crypto_sign/square2048/ref; by using the existing name ecdonaldp256 you indicate that your software implements exactly the same signature system.

Version

This is version 2017.07.26 of the call-sign.html web page. This web page is in the public domain.