tor/src/ext/ed25519/donna/README.tor

We've made the following changes to the stock ed25519-donna from
as of 8757bd4cd209cb032853ece0ce413f122eef212c.

 * Tor uses copies of `ed25519-donna.h` and `ed25519.c`, named
   `ed25519_donna_tor.h` and `ed25591_tor.c`.

   The main functional differences between the standard ed25519-donna
   and the Tor specific version are:

    * The external interface has been reworked to match that provided
       by Tor's copy of the SUPERCOP `ref10` code.

    * The secret (aka private) key is now stored/used in expanded form.

    * The internal math tests from `test-internals.c` have been wrapped
      in a function and the entire file is included to allow for
      runtime validation.

    * There's an implementation of multiplicative key blinding so we
      can use it for next-gen hidden service descriptors.

    * There's an implementation of 'convert a curve25519 key to an
      ed25519 key' so we can do cross-certification with curve25519
      keys.

 * `ED25519_FN(ed25519_randombytes_unsafe)` is now static.

 * `ed25519-randombytes-custom.h` has the appropriate code to call
    Tor's `crypto_rand()` routine, instead of directly using OpenSSL's
    CSPRNG.

 * OSX pollutes the global namespace with an `ALIGN` macro, which is
   undef-ed right before the donna `ALIGN` macro is defined.

 * If building with Clang's AddressSanitizer, disable inline assembly
   since the compilation will fail in `ge25519_scalarmult_base_choose_niels`
   on x86_64 targets due to running out of registers.

 * On non-x86 targets, GCC's Stack Protector dislikes variables that have
   alignment constraints greater than that of other primitive types.
   The `ALIGN` macro is thus no-oped for all non-SSE2 builds.

 * On 32 bit x86 targets that the compiler thinks supports SSE2, always
   enable SSE2 support by force defining ED25519_SSE2 (x86_64 would also
   always support this, but that code path is slower).