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 stream aead dh kem encrypt sign
List of primitives measured: lwc sha3 hash stream lwc caesar aead dh kem encrypt sign
Measurements indexed by machine: lwc sha3 hash stream lwc caesar aead dh kem encrypt sign
List of subroutines: verify decode encode sort core hashblocks scalarmult

Call for public-key encryption software for benchmarking

Are you a designer or implementor of a public-key cryptosystem? Would you like your software professionally benchmarked on many computers, producing stable, reliable, verifiable timings that reflect the performance that cryptosystem 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 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

Let's say you're the designer of Stinger, a cryptosystem with a 2048-bit secret key and a 512-bit public key, and you want to submit your Stinger software to eBATS. Your submission can be as simple as two files, crypto_encrypt/stinger/ref/api.h and crypto_encrypt/stinger/ref/encrypt.c. Here is an explanation of what these files contain and what additional options you have.

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
indicating that your software uses a 256-byte (2048-bit) secret key, a 64-byte (512-bit) public key, and at most 48 bytes of overhead in a encrypted message compared to the original message.

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

     #include "crypto_encrypt.h"

     int crypto_encrypt_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(
       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_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;
     }
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 invalid ciphertexts, or other negative numbers to indicate other failures (e.g., out of memory).

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. You must include crypto_encrypt.h for any file referring to the crypto_encrypt_* functions. The file crypto_encrypt.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 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.

Version

This is version 2020.08.01 of the call-encrypt.html web page. This web page is in the public domain.