![]() VAMPIRE |
eBACS: ECRYPT Benchmarking of Cryptographic Systems |
![]() ECRYPT II |
|---|
| General information: | Introduction | eBASH | eBASC | eBAEAD | eBATS | SUPERCOP | XBX | Computers | Arch |
|---|
| 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: | lwc | sha3 | hash | stream | lwc | caesar | aead | dh | kem | encrypt | sign |
|---|
| List of subroutines: | verify | decode | encode | sort | core | hashblocks | xof | scalarmult |
|---|
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.
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.