Log Message:
Update to Botan 2.1.0, the new stable branch.

Some of the more important changes:

- Fix incorrect truncation in Bcrypt. Passwords in length between 56 and
  72 characters were truncated at 56 characters. Found and reported by
  Solar Designer. (CVE-2017-7252) (GH #938)
- Fix a bug in X509 DN string comparisons that could result in out of
  bound reads. This could result in information leakage, denial of
  service, or potentially incorrect certificate validation results.
  Found independently by Cisco Talos team and OSS-Fuzz. (CVE-2017-2801)
- Correct minimum work factor for Bcrypt password hashes. All other
  implementations require the work factor be at least 4. Previously
  Botan simply required it be greater than zero. (GH #938)
- Converge on a single side channel silent EC blinded multiply
  algorithm. Uses Montgomery ladder with order/2 bits scalar blinding
  and point randomization now by default. (GH #893)
- Add ability to search for certificates using the SHA-256 of the
  distinguished name. (GH #900)
- Support a 0-length IV in ChaCha stream cipher. Such an IV is treated
  identically to an 8-byte IV of all zeros.
- Previously Botan forbid any use of times past 2037 to avoid Y2038
  issues. Now this restriction is only in place on systems which have a
  32-bit time_t. (GH #933 fixing #917)
- Fix a longstanding bug in modular exponentiation which caused most
  exponentiations modulo an even number to have an incorrect result;
  such moduli occur only rarely in cryptographic contexts. (GH #754)
- Fix a bug in BigInt multiply operation, introduced in 1.11.30, which
  could cause incorrect results. Found by OSS-Fuzz fuzzing the ressol
  function, where the bug manifested as an incorrect modular
  exponentiation. OSS-Fuzz bug #287
- Fix a bug that meant the “ietf/modp/6144” and “ietf/modp/8192”
  discrete log groups used an incorrect value for the generator,
  specifically the value (p-1)/2 was used instead of the correct value
  of 2.
- DL_Group strong generation previously set the generator to 2. However
  sometimes 2 generates the entire group mod p, rather than the subgroup
  mod q. This is invalid by X9.42 standard, and exposes incautious
  applications to small subgroup attacks. Now DL_Group uses the smallest
  g which is a quadratic residue. (GH #818)
- The default TLS policy now requires 2048 or larger DH groups by
  default.
- The default Path_Validation_Restrictions constructor has changed to
  require at least 110 bit signature strength. This means 1024 bit RSA
  certificates and also SHA-1 certificates are rejected by default. Both
  settings were already the default for certificate validation in TLS
  handshake, but this changes it for applications also.
- Fix integer overflow during BER decoding, found by Falko Strenzke.
  This bug is not thought to be directly exploitable but upgrading ASAP
  is advised. (CVE-2016-9132)
- Add post-quantum signature scheme XMSS. Provides either 128 or 256 bit
  (post-quantum) security, with small public and private keys, fast
  verification, and reasonably small signatures (2500 bytes for 128-bit
  security). Signature generation is very slow, on the order of seconds.
  And very importantly the signature scheme is stateful: each leaf index
  must only be used once, or all security is lost. In the appropriate
  system where signatures are rarely generated (such as code signing)
  XMSS makes an excellent choice. (GH #717 #736)
- Add support for client-side OCSP stapling to TLS. (GH #738)
- Previously both public and private keys performed automatic self
  testing after generation or loading. However this often caused
  unexpected application performance problems, and so has been removed.
  Instead applications must call check_key explicitly. (GH #704)
- Fix TLS session resumption bugs which caused resumption failures if an
  application used a single session cache for both TLS and DTLS. (GH
  #688)
- The default TLS policy now disables static RSA ciphersuites, all DSA
  ciphersuites, and the AES CCM-8 ciphersuites. Disabling static RSA by
  default protects servers from oracle attacks, as well as enforcing a
  forward secure ciphersuite. Some applications may be forced to
  re-enable RSA for interop reasons. DSA and CCM-8 are rarely used, and
  likely should not be negotiated outside of special circumstances.
- The default TLS policy now prefers ChaCha20Poly1305 cipher over any
  AES mode.
- The default TLS policy now orders ECC curve preferences in order by
  performance, with x25519 first, then P-256, then P-521, then the rest.