Thom Wiggers 2108bdcdb5 | 5年前 | |
---|---|---|
.circleci | 5年前 | |
.github | 5年前 | |
common | 5年前 | |
crypto_kem | 5年前 | |
crypto_sign | 5年前 | |
test | 5年前 | |
.astylerc | 5年前 | |
.clang-tidy | 5年前 | |
.gitattributes | 5年前 | |
.gitignore | 5年前 | |
.gitmodules | 5年前 | |
.travis.yml | 5年前 | |
CONTRIBUTING.md | 5年前 | |
README.md | 5年前 | |
appveyor.yml | 5年前 | |
requirements.txt | 5年前 |
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
What PQClean is not aiming for is
As a first main target, we are collecting C implementations that fulfill the requirements listed below. Please also review our guidelines for contributors if you are interested in adding a scheme to PQClean.
The checking of items on this list is still being developed. Checked items should be working.
nmake
)PQCLEAN_SCHEMENAME_
LICENSE
file (see below)META.yml
file giving details about version of the algorithm, designers
META.yml
.const
arguments are labeled as const
stdint.h
typessize_t
for (size_t i=...
)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.
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:
size_t
instead of unsigned long long
; andint 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);
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)
.
Each implementation directory in PQClean (e.g., crypto_kem/kyber768\clean) can be extracted for use in your own project. You will need to:
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:
Makefile
which can be used with GNU Make, BSD Make, and possibly others.Makefile.Microsoft_nmake
which can be used with Visual Studio’s nmake.The following projects consume implementations from PQClean and provide their own wrappers around the implementations. Their integration strategies may serve as examples for your own projects.
Each subdirectory containing implementations contains a LICENSE
file stating under what license that specific implementation is released.
The files in common
contain licensing information at the top of the file (and are currently either public domain or MIT).
All other code in this repository is released under the conditions of CC0.
See https://github.com/PQClean/PQClean/wiki/Test-framework for details about the PQClean test framework.
While we run extensive automatic testing on Circle CI (Linux builds), Travis CI (OS X builds) and Appveyor (Windows builds), most tests can also be run locally. To do this, make sure the following is installed:
nosetests
or nose2
(either for Python 3)You will also need to make sure the submodules are initialized by running:
git submodule update --init
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 python3 <testmodule>
where <testmodule>
is any of the files starting with test_
in the test/
folder.