blob: 026d180c24cdfdba002ed8b1ae2a73337fe18021 (
plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
|
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).
|
