The runtime sanity checking is slightly different from the optimized
basepoint stuff in that it uses a given implementation's self tests if
available, and checks if signing/verification works with a test vector
from the IETF EdDSA draft.
The unit tests include a new testcase that will fuzz donna against ref0,
including the blinding and curve25519 key conversion routines. If this
is something that should be done at runtime (No?), the code can be
stolen from there.
Note: Integrating batch verification is not done yet.
Integration work scavanged from nickm's `ticket8897_9663_v2` branch,
with minor modifications. Tor will still sanity check the output but
now also attempts to catch extreme breakage by spot checking the
optimized implementation vs known values from the NaCl documentation.
Implements feature 9663.
Integrate ed25519-donna into the build process, and provide an
interface that matches the `ref10` code. Apart from the blinding and
Curve25519 key conversion, this functions as a drop-in replacement for
ref10 (verified by modifying crypto_ed25519.c).
Tests pass, and the benchmarks claim it is quite a bit faster, however
actually using the code requires additional integration work.
RFC 952 is approximately 30 years old, and people are failing to comply,
by serving A records with '_' as part of the hostname. Since relaxing
the check is a QOL improvement for our userbase, relax the check to
allow such abominations as destinations, especially since there are
likely to be other similarly misconfigured domains out there.
clang complains that the address of struct member in an assert in
SSL_SESSION_get_master_key is always non-NULL.
Instead, check each pointer argument is non-NULL before using it.
Fix on f90a704f12 from 27 May 2015, not in any released version of tor.
Unused variable warnings were still generated under some versions of OpenSSL.
Instead, make sure all variables are used under all versions.
Fix on 496df21c89, not in any released version of tor.
An earlier version of these tests was broken; now they're a nicer,
more robust, more black-box set of tests. The key is to have each
test check a handshake message that is wrong in _one_ way.
When there are annotations on a router descriptor, the
ed25519-identity element won't be at position 0 or 1; it will be at
router+1 or router-1.
This patch also adds a missing smartlist function to search a list for
an item with a particular pointer.
Routers now use TAP and ntor onion keys to sign their identity keys,
and put these signatures in their descriptors. That allows other
parties to be confident that the onion keys are indeed controlled by
the router that generated the descriptor.
For prop220, we have a new ed25519 certificate type. This patch
implements the code to create, parse, and validate those, along with
code for routers to maintain their own sets of certificates and
keys. (Some parts of master identity key encryption are done, but
the implementation of that isn't finished)
If the OpenSSL team accepts my patch to add an
SSL_get_client_ciphers function, this patch will make Tor use it
when available, thereby working better with openssl 1.1.
We previously used this function instead of SSL_set_cipher_list() to
set up a stack of client SSL_CIPHERs for these reasons:
A) In order to force a particular order of the results.
B) In order to be able to include dummy entries for ciphers that
this build of openssl did not support, so we could impersonate
Firefox harder.
But we no longer do B, since we merged proposal 198 and stopped
lying about what ciphers we know.
And A was actually pointless, since I had misread the implementation
of SSL_set_cipher_list(). It _does_ do some internal sorting, but
that is pre-sorting on the master list of ciphers, not sorting on
the user's preferred order.
As OpenSSL >= 1.0.0 is now required, ECDHE is now mandatory. The group
has to be validated at runtime, because of RedHat lawyers (P224 support
is entirely missing in the OpenSSL RPM, but P256 is present and is the
default).
Resolves ticket #16140.
