This was being used to get at gcc/clang's __builtin_expect, but we don't
really need that: we can just avoid the check entirely when not in debug
mode which should be even faster.
These aren't needed: CMake already knows how to follow #includes and
rebuild when headers change as long as the headers are included
*somewhere*. The extra .cpp files here just require building a bunch of
.cpp files with just header content that we just end up throw away
during linking (since the same things will also be compiled in whatever
other compilation units include the same headers).
This makes PrivateKey store both the key followed by the hash. For
PrivateKeys based on SecretKeys this just means the second half of the
SHA-512 of the seed, and makes a PrivateKey constructed from a SecretKey
give an identical signature to signing directly with sodium.
For derived keys we use a ShortHash of the root key's signing hash
concatenated with the publicly known hash value, so that our derived key
signing hash will be different from the root signing hash and also
different for different derivation parameters.
This also changed one of the asserts in crypto_noop, but upon closer
inspection the copying of the secret key into the signature seems really
wrong, so just changed them to fill with 0s.
The reason things weren't working here is because libsodium does
something completely unintuitive and called the seed the "secret key"
when it isn't, it's the seed.
This adds a new PrivateKey class (alongside the existing SecretKey and
PubKey) that holds just a private key value but no seed -- which we need
to do because there is no way we can get a seed after calculating a
derived keypair.
With these changes, we now generate exactly the same keys and subkeys as
Tor (and a new test case uses values generated in Tor to verify this).
This is incomplete -- the subkey signing code is still not implemented;
it has to be adapted to create a signature from a PrivateKey rather than
a SecretKey which will probably requiring working around/reimplementing
some of what libsodium does for creating a signature since it expects
"secret keys" i.e. the seed.
Success case:
- the path endpoint creates and sends a LR_StatusMessage upon
successful path creation
Failure case:
- an intermediate hop creates and sends a LR_StatusMessage upon
failure to forward the path to the next hop for any reason
Both cases:
- transit hops receive LR_StatusMessages and add a frame
to them reflecting their "status" with respect to that path
- the path creator receives LR_StatusMessages and decrypts/parses
the LR_StatusRecord frames from the path hops. If all is good,
the Path does as it would when receiving a PathConfirmMessage.
If not, the Path marks the new path as failed.
LR_StatusMessage is now used/sent in place of PathConfirmMessage
