There were two bugs here that made the behavior unlike that of C
tor: we had swapped the MAC inputs, and we had forgotten to include
the public key X in the input.
I think that these Input structs had been defined so that we could
use hs_ntor interchangeably with other handshakes. The trouble is,
though, that it doesn't really work like any other handshakes we
have.
Note that some of the invocations for this function seem to put the
key and the message in a questionable order. But that's a thing to
figure out later, while debugging.
We'll want this because our hs_ntor handshake requires access to an
encoded version of the header independent from the actual encrypted
message.
part of #866.
This commit changes certain log messages to debug for recoverable errors
and a warn if all such attempts fail, in order to not clutter up the
info messages that end users get to see.
This function will be used to look up a relay by a set of LinkSpecs
given from an incoming HsDesc or INTRODUCE2 message. It differs
from other "lookup relay by IDs" functions in that it needs to be
able to return "here's a relay", "couldn't found a relay", or
"learned that this relay is impossible."
Closes#855: This is the only new API needed for ChanTarget
validation, I think.
Now ClientCirc is no longer `Clone`, and the things that need it
to be `Clone` instead return and use an Arc<ClientCirc>
We're doing this so that ClientCirc can participate in the RPC
system, and so that its semantics are more obvious.
Closes#846.
Thanks to the type system, this was a much simpler refactoring than
I had feared it would be.
This also moves the `extension` function out of `KeyType` because for
the C Tor key store, a key's file extension depends on the role/user of
the key, which isn't known by `KeyType` (`KeyType` is a tor-agnostic key
type such as `Ed25519Private`).
Signed-off-by: Gabriela Moldovan <gabi@torproject.org>
This renames `KeyIdentity` to `KeySpecifier` so it doesn't get confused
with the concept of an "identity key". `HsClientIdentity` is also
renamed for consistency.
Signed-off-by: Gabriela Moldovan <gabi@torproject.org>
We want each ID to have a unique form every time it is given out,
so that you can't use ID==ID to check whether Object==Object. (See
discussions leading to #848.)
We'd also like the form of object IDs to be a little annoying to
analyze, to discourage people from writing programs that depends on
their particular format. (We are reserving the right to change the
format whenever we want.)
We _don't_ want to use any cryptography here (yet), lest somebody
think that this is an actual security mechanism. (This isn't for
security; it's for encouraging developers to treat IDs as opaque.)
With that in mind, we now lightly obfuscate our generational indices
before returning them.
Per discussion referenced at #848, we want each operation that
returns a strong object ID to return a new, distinct strong ID.
Note that we no longer need to put strong and weak references in the
same arena; we can clean this code up a lot down the road.
Now we generate object IDs that we can parse. This is about to be
obsolete once we change how we generate objects and their IDs for #848,
but we may as well start from a working state.
This does the following:
- Gives every crate a `full`.
- Cause every `full` to depend on `full` from the lower-level
crates.
- Makes every feature listed _directly_ in `experimental` depend
on `__is_experimental`.
Nick Mathewson
gabi-250
Saksham Mittal