You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.

README.md 6.8 KiB

5 years ago
5 years ago
5 years ago
5 years ago
5 years ago
5 years ago
5 years ago
123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133
  1. # PQClean
  2. [![Build Status](https://travis-ci.com/PQClean/PQClean.svg?branch=master)](https://travis-ci.com/PQClean/PQClean)
  3. [![Build status](https://ci.appveyor.com/api/projects/status/186ky7yb9mlqj3io?svg=true)](https://ci.appveyor.com/project/PQClean/pqclean)
  4. **PQClean**, in short, is an effort to collect **clean** implementations of the post-quantum
  5. schemes that are in the
  6. [NIST post-quantum project](https://csrc.nist.gov/projects/post-quantum-cryptography).
  7. The goal of PQClean is to provide *standalone implementations* that
  8. * can easily be integrated into libraries such as [liboqs](https://openquantumsafe.org/#liboqs) or [libpqcrypto](https://libpqcrypto.org/);
  9. * can efficiently upstream into higher-level protocol integration efforts such as [Open Quantum Safe](https://openquantumsafe.org/#integrations);
  10. * can easily be integrated into benchmarking frameworks such as [SUPERCOP](https://bench.cr.yp.to/supercop.html);
  11. * can easily be integrated into frameworks targeting embedded platforms such as [pqm4](https://github.com/mupq/pqm4);
  12. * are suitable starting points for architecture-specific optimized implementations;
  13. * are suitable starting points for evaluation of implementation security; and
  14. * are suitable targets for formal verification.
  15. What PQClean is **not** aiming for is
  16. * a build system producing an integrated library of all schemes;
  17. * including benchmarking of implementations; and
  18. * including integration into higher-level applications or protocols.
  19. As a first main target, we are collecting C implementations that fulfill the requirements
  20. listed below.
  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] Compiles with `-Wall -Wextra -Wpedantic -Werror` with `gcc` and `clang`
  27. * [x] Consistent test vectors across runs
  28. * [ ] Consistent test vectors on big-endian and little-endian machines
  29. * [ ] Consistent test vectors on 32-bit and 64-bit machines
  30. * [x] No errors/warnings reported by valgrind
  31. * [x] No errors/warnings reported by address sanitizer
  32. * [ ] Only dependencies:
  33. * [x] `fips202.c`
  34. * [x] `sha2.c`
  35. * [ ] `aes.c`
  36. * [x] `randombytes.c`
  37. * [ ] API functions return `0` on success, negative on failure
  38. * [x] 0 on success
  39. * [ ] Negative on failure (within restrictions of FO transform).
  40. * [ ] No dynamic memory allocations
  41. * [ ] No branching on secret data (dynamically checked using valgrind)
  42. * [ ] No access to secret memory locations (dynamically checked using valgrind)
  43. * [ ] Separate subdirectories (without symlinks) for each parameter set of each scheme
  44. * [x] Builds under Linux, MacOS, and Windows
  45. * [x] Linux
  46. * [x] MacOS
  47. * [x] Windows
  48. * [x] Makefile-based build for each separate scheme
  49. * [x] Makefile-based build for Windows (`nmake`)
  50. * [x] All exported symbols are namespaced with `PQCLEAN_SCHEMENAME_`
  51. * [x] Each implementation comes with a `LICENSE` file (see below)
  52. * [x] Each scheme comes with a `META.yml` file giving details about version of the algorithm, designers
  53. * [x] Each individual implementation is specified in `META.yml`.
  54. ## Requirements on C implementations that are manually checked
  55. * Makefiles without explicit rules (rely on implicit, built-in rules)
  56. * `#ifdef`s only for header encapsulation
  57. * No stringification macros
  58. * Output-parameter pointers in functions are on the left
  59. * `const` arguments are labeled as `const`
  60. * All exported symbols are namespaced in place
  61. * All integer types are of fixed size, using `stdint.h` types (including `uint8_t` instead of `unsigned char`)
  62. * Integers used for indexing are of size `size_t`
  63. * variable declarations at the beginning (except in `for (size_t i=...`)
  64. ## Clean C implementations currently in PQClean
  65. Currently, the continuous-integration and testing environment of PQClean is still work in progress
  66. and as a consequence PQClean does not yet have many implementations.
  67. <!--
  68. Currently, PQClean includes clean C implementations of the following KEMs:
  69. * [Kyber-512](https://pq-crystals.org/kyber/)
  70. * [Kyber-768](https://pq-crystals.org/kyber/)
  71. * [Kyber-1024](https://pq-crystals.org/kyber/)
  72. Currently, PQClean includes clean C implementations of the following signature schemes:
  73. * [Dilithium-III](https://pq-crystals.org/dilithium/)
  74. -->
  75. ## API used by PQClean
  76. PQClean is essentially using the same API as required for the NIST reference implementations,
  77. which is also used by SUPERCOP and by libpqcrypto. The only two differences to that API are
  78. the following:
  79. * All lengths are passed as type `size_t` instead of `unsigned long long`; and
  80. * Signatures offer two additional functions that follow the "traditional" approach used
  81. in most software stacks of computing and verifying signatures instead of producing and
  82. recovering signed messages. Specifically, those functions have the following name and signature:
  83. ```
  84. int crypto_sign_signature(uint8_t *sig, size_t *siglen, const uint8_t *m, size_t mlen, const uint8_t *sk);
  85. int crypto_sign_verify(const uint8_t *sig, size_t siglen, const uint8_t *m, size_t mlen, const uint8_t *pk);
  86. ```
  87. ## Building PQClean
  88. 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.
  89. List of required dependencies: ``gcc or clang, make, python3, python-yaml library, valgrind``.
  90. ## Using source code from PQClean in your own project
  91. Each implementation directory in PQClean (e.g., crypto\_kem/kyber768\clean) can be extracted for use in your own project. You will need to:
  92. 1. Copy the source code from the implementation's directory into your project.
  93. 2. Add the files to your project's build system.
  94. 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).
  95. 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:
  96. - The file `Makefile` which can be used with GNU Make, BSD Make, and possibly others.
  97. - The file `Makefile.Microsoft_nmake` which can be used with Visual Studio's nmake.
  98. ## License
  99. Each subdirectory containing implementations contains a LICENSE file stating under what license
  100. that specific implementation is released. All other code for testing etc. in this repository
  101. is released under the conditions of [CC0](http://creativecommons.org/publicdomain/zero/1.0/).