VAMPIRE |
eBACS: ECRYPT Benchmarking of Cryptographic Systems |
ECRYPT II |
General information: | Introduction | eBASH | eBASC | eBATS | SUPERCOP | XBX | Computers |
How to submit new software: | Hash functions | Stream ciphers | DH functions | Public-key encryption | Public-key signatures |
List of primitives measured: | SHA-3 finalists | All hash functions | Stream ciphers | DH functions | Public-key encryption | Public-key signatures |
Measurements indexed by machine: | SHA-3 finalists | All hash functions | Stream ciphers | DH functions | Public-key encryption | Public-key signatures |
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.
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 128indicating 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_BYTESand 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.
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.
In particular, submitters are encouraged to clearly specify one of the following levels of copyright protection: