1
1
mirror of https://github.com/henrydcase/pqc.git synced 2024-11-22 15:39:07 +00:00
Go to file
Thom Wiggers 2b381e9a78
Merge pull request #54 from PQClean/no-dynamic-memory-allocations
Detect use of dynamic memory allocation functions
2019-02-27 14:24:11 +01:00
common Build functional tests and test vectors on Windows continuous integration 2019-02-25 21:40:43 -05:00
crypto_kem/kyber768 Include name of implementation in namespace 2019-02-27 09:18:38 +01:00
crypto_sign/dilithium-iii Include name of implementation in namespace 2019-02-27 09:18:38 +01:00
scripts_windows Build functional tests and test vectors on Windows continuous integration 2019-02-25 21:40:43 -05:00
test Merge pull request #54 from PQClean/no-dynamic-memory-allocations 2019-02-27 14:24:11 +01:00
.astylerc Some cleanup, expanded dependencies, removed two unnecessary files in kyber768 2019-02-14 15:30:55 +01:00
.clang-tidy Add travis config 2019-01-16 14:54:24 +01:00
.gitattributes Fix tidy for signing 2019-01-16 13:02:35 +01:00
.gitignore Reimplement Python tests using nose framework 2019-02-13 22:25:34 -05:00
.travis.yml Enable address and UB sanitizers 2019-02-19 10:39:44 +00:00
appveyor.yml First attempt at appveyor configuration 2019-02-07 10:01:06 +01:00
Makefile Also include implementation namespace in Makefiles 2019-02-27 09:18:38 +01:00
README.md Merge pull request #54 from PQClean/no-dynamic-memory-allocations 2019-02-27 14:24:11 +01:00
requirements.txt Colourise test output 2019-02-18 10:10:20 +01:00

PQClean

Build Status Build status

PQClean, in short, is an effort to collect clean implementations of the post-quantum schemes that are in the NIST post-quantum project. The goal of PQClean is to provide standalone implementations that

  • can easily be integrated into libraries such as liboqs or libpqcrypto;
  • can efficiently upstream into higher-level protocol integration efforts such as Open Quantum Safe;
  • can easily be integrated into benchmarking frameworks such as SUPERCOP;
  • can easily be integrated into frameworks targeting embedded platforms such as pqm4;
  • are suitable starting points for architecture-specific optimized implementations;
  • are suitable starting points for evaluation of implementation security; and
  • are suitable targets for formal verification.

What PQClean is not aiming for is

  • a build system producing an integrated library of all schemes;
  • including benchmarking of implementations; and
  • including integration into higher-level applications or protocols.

As a first main target, we are collecting C implementations that fulfill the requirements listed below.

Requirements on C implementations that are automatically checked

The checking of items on this list is still being developed. Checked items should be working.

  • Code is valid C99
  • Passes functional tests
  • API functions do not write outside provided buffers
  • Compiles with -Wall -Wextra -Wpedantic -Werror with gcc and clang
  • Consistent test vectors across runs
  • Consistent test vectors on big-endian and little-endian machines
  • Consistent test vectors on 32-bit and 64-bit machines
  • No errors/warnings reported by valgrind
  • No errors/warnings reported by address sanitizer
  • Only dependencies:
    • fips202.c
    • sha2.c
    • aes.c
    • randombytes.c
  • API functions return 0 on success, negative on failure
    • 0 on success
    • Negative on failure (within restrictions of FO transform).
  • No dynamic memory allocations
  • No branching on secret data (dynamically checked using valgrind)
  • No access to secret memory locations (dynamically checked using valgrind)
  • Separate subdirectories (without symlinks) for each parameter set of each scheme
  • Builds under Linux, MacOS, and Windows
    • Linux
    • MacOS
    • Windows
  • Makefile-based build for each separate scheme
  • Makefile-based build for Windows (nmake)
  • All exported symbols are namespaced with PQCLEAN_SCHEMENAME_
  • Each implementation comes with a LICENSE file (see below)
  • Each scheme comes with a META.yml file giving details about version of the algorithm, designers
    • Each individual implementation is specified in META.yml.

Requirements on C implementations that are manually checked

  • Makefiles without explicit rules (rely on implicit, built-in rules)
  • #ifdefs only for header encapsulation
  • No stringification macros
  • Output-parameter pointers in functions are on the left
  • const arguments are labeled as const
  • All exported symbols are namespaced in place
  • All integer types are of fixed size, using stdint.h types (including uint8_t instead of unsigned char)
  • Integers used for indexing are of size size_t
  • variable declarations at the beginning (except in for (size_t i=...)

Clean C implementations currently in PQClean

Currently, the continuous-integration and testing environment of PQClean is still work in progress and as a consequence PQClean does not yet have many implementations.

API used by PQClean

PQClean is essentially using the same API as required for the NIST reference implementations, which is also used by SUPERCOP and by libpqcrypto. The only two differences to that API are the following:

  • All lengths are passed as type size_t instead of unsigned long long; and
  • Signatures offer two additional functions that follow the "traditional" approach used in most software stacks of computing and verifying signatures instead of producing and recovering signed messages. Specifically, those functions have the following name and signature:
int crypto_sign_signature(uint8_t *sig, size_t *siglen, const uint8_t *m, size_t mlen, const uint8_t *sk);
int crypto_sign_verify(const uint8_t *sig, size_t siglen, const uint8_t *m, size_t mlen, const uint8_t *pk);

Building PQClean

As noted above, PQClean is not meant to be built as a single library: it is a collection of source code that can be easily integrated into other libraries. The PQClean repository includes various test programs which do build various files, but you should not use the resulting binaries for any purpose.

List of required dependencies: gcc or clang, make, python3, python-yaml library, valgrind, astyle (>= 3.0).

Using source code from PQClean in your own project

Each implementation directory in PQClean (e.g., crypto_kem/kyber768\clean) can be extracted for use in your own project. You will need to:

  1. Copy the source code from the implementation's directory into your project.
  2. Add the files to your project's build system.
  3. Provide instantiations of any of the common cryptographic algorithms used by the implementation. This likely includes common/randombytes.h (a cryptographic random number generator), and possibly common/sha2.h (the SHA-2 hash function family) and common/fips202.h (the SHA-3 hash function family).

Regarding #2, adding the files to your project's build system, each implementation in PQClean is accompanied by example two makefiles that show how one could build the files for that implementation:

  • The file Makefile which can be used with GNU Make, BSD Make, and possibly others.
  • The file Makefile.Microsoft_nmake which can be used with Visual Studio's nmake.

License

Each subdirectory containing implementations contains a LICENSE file stating under what license that specific implementation is released. All other code for testing etc. in this repository is released under the conditions of CC0.

Running tests locally

While we run extensive automatic testing on Travis CI and Appveyor, most tests can also be run locally. To do this, make sure the following is installed:

  • Python 3.5+
  • nosetests or nose2 (either for Python 3)

Run the Python-based tests by going into the test directory and running nosetests -v or nose2 -B -v, depending on what you installed. If you have the rednose plugin for nosetests installed, run nosetests --rednose to get colored output.

You may also run python <testmodule> where <testmodule> is any of the files starting with test_ in the test/ folder.