12345678910111213141516171819202122232425262728293031323334353637383940414243444546 |
- 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).
|