diff options
| -rw-r--r-- | doc/abi.rst | 19 | ||||
| -rw-r--r-- | doc/license.txt | 15 | ||||
| -rw-r--r-- | doc/manual/aead.rst | 5 | ||||
| -rw-r--r-- | doc/manual/building.rst | 10 | ||||
| -rw-r--r-- | doc/manual/tls.rst | 7 | ||||
| -rw-r--r-- | doc/reading_list.txt | 70 | ||||
| -rw-r--r-- | doc/roadmap.rst | 3 | ||||
| -rw-r--r-- | doc/todo.rst | 2 | ||||
| -rw-r--r-- | readme.rst | 19 |
9 files changed, 103 insertions, 47 deletions
diff --git a/doc/abi.rst b/doc/abi.rst new file mode 100644 index 000000000..319c1fc81 --- /dev/null +++ b/doc/abi.rst @@ -0,0 +1,19 @@ + +API/ABI Stability +==================== + +The API and ABI in development branches (those with an odd number, such as 1.11 +or 2.1) is subject to change without notice. We don't go out of our way to break +client code, but if a possibility for serious improvement is seen it is taken. + +For stable branches (1.10, 2.0) API stability is considered important. +Coorespondingly they see mostly security and bug fixes, or improvements +backported from the devel tree when doing so would not cause problems for +existing code. Code written and working for .0 of a stable release should +continue to work with later releases from the same branch. + +However maintaining a consistent ABI while changing a complex C++ API is +exceedingly expensive in development time, and even in the stable branches ABI +breakage may be necessary to fix a security issue or other major bug. If ABI +breakage knowingly occurs in the stable tree it will be documented accordingly +in the release notes and the soname revision will be ticked up. diff --git a/doc/license.txt b/doc/license.txt index 2eb91b622..873e55e37 100644 --- a/doc/license.txt +++ b/doc/license.txt @@ -1,4 +1,4 @@ -Copyright (C) 1999-2013,2014,2015 Jack Lloyd +Copyright (C) 1999-2013,2014,2015,2016 Jack Lloyd 2001 Peter J Jones 2004-2007 Justin Karneges 2004 Vaclav Ovsik @@ -6,10 +6,10 @@ Copyright (C) 1999-2013,2014,2015 Jack Lloyd 2005-2006 Matt Johnston 2006 Luca Piccarreta 2007 Yves Jerschow - 2007-2008 FlexSecure GmbH - 2007-2008 Technische Universitat Darmstadt - 2007-2008,2010,2014 Falko Strenzke - 2007-2008 Martin Doering + 2007,2008 FlexSecure GmbH + 2007,2008 Technische Universitat Darmstadt + 2007,2008,2010,2014 Falko Strenzke + 2007,2008 Martin Doering 2007 Manuel Hartl 2007 Christoph Ludwig 2007 Patrick Sona @@ -18,13 +18,16 @@ Copyright (C) 1999-2013,2014,2015 Jack Lloyd 2008 Google Inc. 2010 Olivier de Gaalon 2012 Vojtech Kral - 2012-2014 Markus Wanner + 2012,2014 Markus Wanner 2013 Joel Low 2014 cryptosource GmbH 2014 Andrew Moon 2015 Daniel Seither (Kullo GmbH) 2015 Simon Warta (Kullo GmbH) 2015 Matej Kenda (TopIT d.o.o.) + 2015 René Korthaus + 2015 Daniel Neus + 2015 Uri Blumenthal All rights reserved. Redistribution and use in source and binary forms, with or without diff --git a/doc/manual/aead.rst b/doc/manual/aead.rst index 9798cac3b..5ab33c849 100644 --- a/doc/manual/aead.rst +++ b/doc/manual/aead.rst @@ -12,8 +12,9 @@ The AEAD interface can be used directly, or as part of the filter system by using :cpp:class:`AEAD_Filter` (a subclass of :cpp:class:`Keyed_Filter` which will be returned by :cpp:func:`get_cipher` if the named cipher is an AEAD mode). -AEAD modes currently available include GCM, OCB, and EAX. All three use a -128-bit block cipher such as AES. +AEAD modes currently available include GCM, OCB, EAX, SIV and CCM. All +support a 128-bit block cipher such as AES. EAX and SIV also support +256 and 512 bit block ciphers. .. cpp:class:: AEAD_Mode diff --git a/doc/manual/building.rst b/doc/manual/building.rst index dd5bebf0f..e4afb7e77 100644 --- a/doc/manual/building.rst +++ b/doc/manual/building.rst @@ -76,12 +76,12 @@ see :ref:`amalgamation`. For instance:: - $ ./configure.py --minimized-build --enable-modules=rsa,ecdsa,eme1,emsa1,emsa4 + $ ./configure.py --minimized-build --enable-modules=rsa,eme_oaep,emsa_pssr -will set up a build that only includes RSA, ECDSA, and some padding -modes, along with their dependencies. A small subset of core features, -including AES, SHA-2, HMAC, and the multiple precision integer -library, are always loaded. +will set up a build that only includes RSA, OAEP, PSS along with any +required dependencies. A small subset of core features, including AES, +SHA-2, HMAC, and the multiple precision integer library, are always +loaded. The script tries to guess what kind of makefile to generate, and it almost always guesses correctly (basically, Visual C++ uses NMAKE with diff --git a/doc/manual/tls.rst b/doc/manual/tls.rst index 5f96816a8..c5be39aaa 100644 --- a/doc/manual/tls.rst +++ b/doc/manual/tls.rst @@ -534,6 +534,13 @@ policy settings from a file. .. note:: + The current ChaCha20Poly1305 ciphersuites are non-standard but + as of 2015 were implemented and deployed by Google and + elsewhere. Support will be changed to using IETF standard + ChaCha20Poly1305 ciphersuites when those are defined. + + .. note:: + Support for the broken RC4 cipher was removed in 1.11.17 .. cpp:function:: std::vector<std::string> allowed_macs() const diff --git a/doc/reading_list.txt b/doc/reading_list.txt index 6d944d87f..f35ae6ed7 100644 --- a/doc/reading_list.txt +++ b/doc/reading_list.txt @@ -1,42 +1,35 @@ +These are papers, articles and books that are interesting or useful from the +perspective of crypto implementation. + +Papers +================== + Implementation Techniques ----------------------------------------- +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ * "Randomizing the Montgomery Powering Ladder" Le, Tan, Tunstall https://eprint.iacr.org/2015/657 + A variant of Algorithm 7 is used for GF(p) point multplications when + BOTAN_POINTGFP_BLINDED_MULTIPLY_USE_MONTGOMERY_LADDER is set * "Accelerating AES with vector permute instructions" - Hamburg https://shiftleft.org/papers/vector_aes/ + Mike Hamburg https://shiftleft.org/papers/vector_aes/ + His public doman assembly code was rewritten into SSS3 intrinsics + for aes_ssse3. * "Elliptic curves and their implementation" Langley http://www.imperialviolet.org/2010/12/04/ecc.html + Describes sparse representations for ECC math Random Number Generation ----------------------------------------- +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ * "On Extract-then-Expand Key Derivation Functions and an HMAC-based KDF" - Krawczyk http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.131.8254 + Hugo Krawczyk http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.131.8254 RNG design underlying HMAC_RNG -Standards ----------------------------------------- - -* ISO/IEC 18033-2 http://www.shoup.net/iso/std4.pdf - RSA-KEM, PSEC-KEM - -* NIST SP 800-108 - http://csrc.nist.gov/publications/nistpubs/800-108/sp800-108.pdf - KDF schemes - -* NIST SP 800-90A - http://csrc.nist.gov/publications/nistpubs/800-90A/SP800-90A.pdf - HMAC_DRBG, Hash_DRBG, CTR_DRBG, maybe one other thing? - - -Side Channel Attacks ----------------------------------------- - -AES +AES Side Channels ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ * "Software mitigations to hedge AES against cache-based software side @@ -48,7 +41,7 @@ AES * "Cache-Collision Timing Attacks Against AES" Bonneau, Mironov http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.88.4753 -Public Key +Public Key Side Channels ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ * "Fast Elliptic Curve Multiplications Resistant against Side Channel Attacks" @@ -67,3 +60,32 @@ Public Key * "Minimum Requirements for Evaluating Side-Channel Attack Resistance of Elliptic Curve Implementations" BSI https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Zertifizierung/Interpretationen/AIS_46_ECCGuide_e_pdf.pdf + +Books +======= + +* "Handbook of Elliptic and Hyperelliptic Curve Cryptography" + Cohen and Frey https://www.hyperelliptic.org/HEHCC/ + An excellent reference for ECC math, algorithms, and side channels + +* "Post-Quantum Cryptography" Bernstein, Buchmann, Dahmen + Covers code, lattice, and hash based cryptography + +Standards +============ + +* IEEE 1363 http://grouper.ieee.org/groups/1363/ + Very influential early in the library lifetime, so a lot of terminology used + in the public key (such as "EME" for message encoding) code comes from here. + +* ISO/IEC 18033-2 http://www.shoup.net/iso/std4.pdf + RSA-KEM, PSEC-KEM + +* NIST SP 800-108 + http://csrc.nist.gov/publications/nistpubs/800-108/sp800-108.pdf + KDF schemes + +* NIST SP 800-90A + http://csrc.nist.gov/publications/nistpubs/800-90A/SP800-90A.pdf + HMAC_DRBG, Hash_DRBG, CTR_DRBG, maybe one other thing? + diff --git a/doc/roadmap.rst b/doc/roadmap.rst index 76ab81f07..8f213b17f 100644 --- a/doc/roadmap.rst +++ b/doc/roadmap.rst @@ -32,8 +32,7 @@ compat. The C++11 transition makes it especially hard for the 1.10/1.11 split. So if 1.10 does what you want now it probably will next week, but it won't ever do much beyond that. If you want any feature or optimization or side channel resistance added in the last 4 years you have to use 1.11. 1.10 will -continue to be maintained at the current level for at least a year after 2.0 is -released. +continue to be maintained at the current level for 1 year after 2.0 is released. 1.8 and all older versions are no longer maintained. diff --git a/doc/todo.rst b/doc/todo.rst index 5ea142464..88996f1a2 100644 --- a/doc/todo.rst +++ b/doc/todo.rst @@ -40,7 +40,7 @@ New Protocols Accelerators / backends ---------------------------------------- -* Extend OpenSSL provider (cipher modes, ECDH, HMAC) +* Extend OpenSSL provider (cipher modes, HMAC) * /dev/crypto * Windows CryptoAPI * Apple CommonCrypto diff --git a/readme.rst b/readme.rst index 7afdf579a..8e39dafce 100644 --- a/readme.rst +++ b/readme.rst @@ -161,16 +161,21 @@ TLS/Public Key Infrastructure (TLS-PSK) and passwords (TLS-SRP) and most important extensions, such as session tickets, SNI, and ALPN. * X.509v3 certificates and CRLs -* PKIX certificate path validation with multiple test suites for same +* PKIX certificate path validation * OCSP requests * PKCS #10 certificate requests Public Key Cryptography ---------------------------------------- -* Encryption with RSA and ElGamal -* Signatures with RSA, DSA, ECDSA, GOST 34.10-2001, Nyberg-Rueppel, Rabin-Williams -* Key agreement with Diffie-Hellman, ECDH, Curve25519, and McEliece +* RSA signatures and encryption +* DH and ECDH key agreement +* DSA and ECDSA signatures +* Quantum computer resistant McEliece KEM scheme +* GOST-34.10-2001 +* ElGamal encryption +* Rabin-Williams signatures +* Nyberg-Rueppel signatures * Padding schemes OAEP, PSS, PKCS #1 v1.5, X9.31 Ciphers and cipher modes @@ -194,11 +199,11 @@ Hash functions and MACs * SHA-3 winner Keccak-1600 * SHA-3 candidate Skein-512 * Authentication codes HMAC, CMAC, Poly1305, SipHash -* RIPEMD-160, RIPEMD-128, Tiger, Whirlpool +* RIPEMD-160, Tiger, Whirlpool, GOST 34.11 * Hash function combiners (Parallel and Comb4P) -* National standard hashes HAS-160 and GOST 34.11 * Non-cryptographic checksums Adler32, CRC24, CRC32 -* Obsolete algorithms MD5, MD4, MD2, CBC-MAC, X9.19 DES-MAC +* Obsolete algorithms MD5, MD4, CBC-MAC, X9.19 DES-MAC +* Deprecated hashes MD2, HAS-160, RIPEMD-128 Other Useful Things ---------------------------------------- |