| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| |\ \ \
| |_|/
|/| |
| | |
| | |
| | |
| | | |
tor-proto: Add support for extending circuits through virtual hops.
Closes #726
See merge request tpo/core/arti!1191
|
| | | |
| | |
| | |
| | | |
Based on text from @diziet
|
| | | | |
|
| | | |
| | |
| | |
| | |
| | | |
Sadly, this adds a few more `TODO HS` entries, but I think we can
clean them up later after a bit of discussion.
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | | |
There are a few new TODO hs comments, though, and an XXXX I'll need
to fix up in the next commit.
Implements #726.
|
| | | |
| | |
| | |
| | |
| | | |
This is fairly straightforward, thanks to our existing design work
on this code.
|
| |\ \ \
| |_|/
|/| |
| | |
| | | |
tor-guardmgr, tor-proto: minor logging tweaks
See merge request tpo/core/arti!1190
|
| |/ /
| |
| |
| |
| |
| |
| |
| | |
- We make the tor-guardmgr "We have found that {} is usable" line
include the word "guard", otherwise it doesn't appear very useful to a
user in safe logging mode, since the guard gets replaced with
[scrubbed].
- The "Actually got an end cell..." message is downgraded to DEBUG.
|
| |\ \
| | |
| | |
| | |
| | |
| | |
| | | |
Clean up hs_ntor.rs, add test vectors generated by C tor, and fix some bugs
Closes #865
See merge request tpo/core/arti!1189
|
| | | | |
|
| | | |
| | |
| | |
| | | |
This is still not the most beautiful interface, but it'll do for now.
|
| | | | |
|
| | | | |
|
| | | |
| | |
| | |
| | |
| | |
| | | |
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.
|
| | | |
| | |
| | |
| | | |
We'll want these so we can implement some test vectors.
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | | |
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.
|
| | | | |
|
| | |/ |
|
| |\ \
| |/
|/|
| |
| |
| |
| | |
Refactor Introduce messages to support looking at encoded headers
Closes #866
See merge request tpo/core/arti!1188
|
| | |
| |
| |
| |
| |
| | |
We never want to create one of these from its parts except when we
are testing it; we only want to forward an Introduce1 message with a
new command on it.
|
| | |
| |
| |
| |
| | |
We'll need to store this so that it can later on be used to complete
the hs_ntor handshake.
|
| |/
|
|
|
|
|
|
| |
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.
|
| |\
| |
| |
| |
| |
| |
| | |
Change log levels of messages from INFO to others
Closes #854
See merge request tpo/core/arti!1172
|
| | |
| |
| |
| |
| |
| | |
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.
|
| |\ \
| | |
| | |
| | |
| | |
| | |
| | | |
Refactor ClientCirc APIs to use Arc<ClientCirc>.
Closes #846
See merge request tpo/core/arti!1187
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
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.
|
| |\ \ \
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
tor-cert: Replace the KeyUnknownCert::check_key API
Closes #759
See merge request tpo/core/arti!1184
|
| | | | |
| | | |
| | | |
| | | | |
Closes #759
|
| | | | | |
|
| | | |/
| |/|
| | |
| | |
| | |
| | |
| | | |
These should have a cleaner API than check_key, and be easier to
understand.
Part of #759
|
| |\ \ \
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
netdir: New function to check consistency of a HasRelayIds
Closes #855
See merge request tpo/core/arti!1186
|
| | |/ /
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
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.
|
| |\ \ \
| | | |
| | | |
| | | |
| | | | |
dev docs: key-management.md updates and clarifications
See merge request tpo/core/arti!1185
|
| | | | |
| | | |
| | | |
| | | | |
Signed-off-by: Gabriela Moldovan <[email protected]>
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
There are several places where he `KeyType` isn't needed anymore.
Signed-off-by: Gabriela Moldovan <[email protected]>
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
dirs.
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 <[email protected]>
|
| | | | |
| | | |
| | | |
| | | | |
Signed-off-by: Gabriela Moldovan <[email protected]>
|
| | | | |
| | | |
| | | |
| | | | |
Signed-off-by: Gabriela Moldovan <[email protected]>
|
| | | | |
| | | |
| | | |
| | | | |
Signed-off-by: Gabriela Moldovan <[email protected]>
|
| | | | |
| | | |
| | | |
| | | | |
Signed-off-by: Gabriela Moldovan <[email protected]>
|
| | | | |
| | | |
| | | |
| | | | |
Signed-off-by: Gabriela Moldovan <[email protected]>
|
| | | | |
| | | |
| | | |
| | | | |
Signed-off-by: Gabriela Moldovan <[email protected]>
|
| | |/ /
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
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 <[email protected]>
|
| |\ \ \
| |_|/
|/| |
| | |
| | |
| | |
| | | |
RPC: revise semantics for weak references and object IDs
Closes #848
See merge request tpo/core/arti!1183
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | |
| | |
| | |
| | | |
This lets us simplify our logic a bit for strong references.
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
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.
|