Reference implementations of PQC
Vous ne pouvez pas sélectionner plus de 25 sujets Les noms de sujets doivent commencer par une lettre ou un nombre, peuvent contenir des tirets ('-') et peuvent comporter jusqu'à 35 caractères.

il y a 5 ans
il y a 5 ans
il y a 5 ans
123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180
  1. # PQClean
  2. _[See the build status for each component here](.github/workflows/BADGES.md)_
  3. **PQClean**, in short, is an effort to collect **clean** implementations of the post-quantum
  4. schemes that are in the
  5. [NIST post-quantum project](https://csrc.nist.gov/projects/post-quantum-cryptography).
  6. The goal of PQClean is to provide *standalone implementations* that
  7. * can easily be integrated into libraries such as [liboqs](https://openquantumsafe.org/#liboqs).
  8. * can efficiently upstream into higher-level protocol integration efforts such as [Open Quantum Safe](https://openquantumsafe.org/#integrations);
  9. * can easily be integrated into benchmarking frameworks such as [SUPERCOP](https://bench.cr.yp.to/supercop.html);
  10. * can easily be integrated into frameworks targeting embedded platforms such as [pqm4](https://github.com/mupq/pqm4);
  11. * are suitable starting points for architecture-specific optimized implementations;
  12. * are suitable starting points for evaluation of implementation security; and
  13. * are suitable targets for formal verification.
  14. What PQClean is **not** aiming for is
  15. * a build system producing an integrated library of all schemes;
  16. * including benchmarking of implementations; and
  17. * including integration into higher-level applications or protocols.
  18. As a first main target, we are collecting C implementations that fulfill the requirements
  19. listed below. We also accept optimised implementations, but still requiring high-quality, tested code.
  20. Please also review our [guidelines for contributors](CONTRIBUTING.md) if you are interested in adding a scheme to PQClean.
  21. ## Requirements on C implementations that are automatically checked
  22. _The checking of items on this list is still being developed. Checked items should be working._
  23. * [x] Code is valid C99
  24. * [x] Passes functional tests
  25. * [x] API functions do not write outside provided buffers
  26. * [x] `api.h` cannot include external files
  27. * [x] Compiles with `-Wall -Wextra -Wpedantic -Werror -Wmissing-prototypes` with `gcc` and `clang`
  28. * [x] `#if`/`#ifdef`s only for header encapsulation
  29. * [x] Consistent test vectors across runs
  30. * [x] Consistent test vectors on big-endian and little-endian machines
  31. * [x] Consistent test vectors on 32-bit and 64-bit machines
  32. * [x] `const` arguments are labeled as `const`
  33. * [x] No errors/warnings reported by valgrind
  34. * [x] No errors/warnings reported by address sanitizer
  35. * [x] Only dependencies: `fips202.c`, `sha2.c`, `aes.c`, `randombytes.c`
  36. * [x] API functions return `0` on success
  37. * [x] No dynamic memory allocations (including variable-length arrays)
  38. * [ ] No branching on secret data (dynamically checked using valgrind)
  39. * [ ] No access to secret memory locations (dynamically checked using valgrind)
  40. * [x] Separate subdirectories (without symlinks) for each parameter set of each scheme
  41. * [x] Builds under Linux, MacOS, and Windows
  42. * [x] Linux
  43. * [x] MacOS
  44. * [x] Windows
  45. * [x] Makefile-based build for each separate scheme
  46. * [x] Makefile-based build for Windows (`nmake`)
  47. * [x] All exported symbols are namespaced with `PQCLEAN_SCHEMENAME_`
  48. * [x] Each implementation comes with a `LICENSE` file (see below)
  49. * [x] Each scheme comes with a `META.yml` file giving details about version of the algorithm, designers
  50. * [x] Each individual implementation is specified in `META.yml`.
  51. ## Requirements on C implementations that are manually checked
  52. * Minimalist Makefiles
  53. * No stringification macros
  54. * Output-parameter pointers in functions are on the left
  55. * All exported symbols are namespaced in place
  56. * Integer types are of fixed size where relevant, using `stdint.h` types (optional, recommended)
  57. * Integers used for indexing memory are of size `size_t` (optional, recommended)
  58. * Variable declarations at the beginning (except in `for (size_t i=...`) (optional, recommended)
  59. ## Schemes currently in PQClean
  60. For the following schemes we have implementations of one or more of their parameter sets.
  61. For all of these schemes we have clean C code, but for some we also have optimised code.
  62. ### Key Encapsulation Mechanisms
  63. **Finalists:**
  64. * Classic McEliece
  65. * Kyber
  66. * NTRU
  67. * SABER
  68. **Alternate candidates:**
  69. * FrodoKEM
  70. * HQC
  71. ### Signature schemes
  72. **Finalists:**
  73. * Dilithium
  74. * Falcon
  75. * Rainbow
  76. **Alternate candidates:**
  77. * SPHINCS+
  78. Implementations previously available in PQClean and dropped in Round 3 of the NIST standardization effort are available in the [`round2` tag](https://github.com/PQClean/PQClean/releases/tag/round2).
  79. ## API used by PQClean
  80. PQClean is essentially using the same API as required for the NIST reference implementations,
  81. which is also used by SUPERCOP and by libpqcrypto. The only differences to that API are
  82. the following:
  83. * All functions are namespaced;
  84. * All lengths are passed as type `size_t` instead of `unsigned long long`; and
  85. * Signatures offer two additional functions that follow the "traditional" approach used
  86. in most software stacks of computing and verifying signatures instead of producing and
  87. recovering signed messages. Specifically, those functions have the following name and signature:
  88. ```c
  89. int PQCLEAN_SCHEME_IMPL_crypto_sign_signature(
  90. uint8_t *sig, size_t *siglen,
  91. const uint8_t *m, size_t mlen,
  92. const uint8_t *sk);
  93. int PQCLEAN_SCHEME_IMPL_crypto_sign_verify(
  94. const uint8_t *sig, size_t siglen,
  95. const uint8_t *m, size_t mlen,
  96. const uint8_t *pk);
  97. ```
  98. ## Building PQClean
  99. 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.
  100. List of required dependencies: ``gcc or clang, make, python3, python-yaml library, valgrind, astyle (>= 3.0)``.
  101. ## Using source code from PQClean in your own project
  102. Each implementation directory in PQClean (e.g., crypto\_kem/kyber768\clean) can be extracted for use in your own project. You will need to:
  103. 1. Copy the source code from the implementation's directory into your project.
  104. 2. Add the files to your project's build system.
  105. 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), `common/aes.h` (AES implementations), `common/fips202.h` (the SHA-3 hash function family) and `common/sp800-185.h` (the cSHAKE family).
  106. 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:
  107. - The file `Makefile` which can be used with GNU Make, BSD Make, and possibly others.
  108. - The file `Makefile.Microsoft_nmake` which can be used with Visual Studio's nmake.
  109. ## Projects integrating PQClean-distributed source code
  110. The following projects consume implementations from PQClean and provide their own wrappers around the implementations.
  111. Their integration strategies may serve as examples for your own projects.
  112. - **[pqcrypto crate](https://github.com/rustpq/pqcrypto)**: Rust integration that automatically generates wrappers from PQClean source code.
  113. - **[mupq](https://github.com/mupq/)**: Runs the implementations from PQClean as reference implementations to compare with microcontroller-optimized code.
  114. - **[Open Quantum Safe](https://github.com/open-quantum-safe/)**: The Open Quantum Safe project integrates implementations from PQClean into their [liboqs](https://github.com/open-quantum-safe/liboqs/) C library, which then exposes them via [C++](https://github.com/open-quantum-safe/liboqs-cpp), [C# / .NET](https://github.com/open-quantum-safe/liboqs-dotnet), and [Python](https://github.com/open-quantum-safe/liboqs-python) wrappers, as well as to forks of [OpenSSL](https://github.com/open-quantum-safe/openssl) and [OpenSSH](https://github.com/open-quantum-safe/openssh-portable).
  115. ## License
  116. Each subdirectory containing implementations contains a `LICENSE` file stating under what license that specific implementation is released.
  117. The files in `common` contain licensing information at the top of the file (and are currently either public domain or MIT).
  118. All other code in this repository is released under the conditions of [CC0](http://creativecommons.org/publicdomain/zero/1.0/).
  119. ## Running tests locally
  120. See https://github.com/PQClean/PQClean/wiki/Test-framework for details about the PQClean test framework.
  121. While we run extensive automatic testing on Github Actions ((emulated) Linux builds, MacOS and Windows builds) and [Travis CI][travis-pqc] (Aarch64 builds), and most tests can also be run locally.
  122. To do this, make sure the following is installed:
  123. * Python 3.6+
  124. * `pytest` for python 3.
  125. We also recommend installing ``pytest-xdist`` to allow running tests in parallel.
  126. You will also need to make sure the submodules are initialized by running:
  127. ```
  128. git submodule update --init
  129. ```
  130. Run the Python-based tests by going into the `test` directory and running `pytest -v` or (recommended) `pytest -n=auto` for parallel testing.
  131. You may also run `python3 <testmodule>` where `<testmodule>` is any of the files starting with `test_` in the `test/` folder.
  132. [travis-pqc]: https://travis-ci.com/PQClean/PQClean/