| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| | | | |
| | | |
| | | |
| | | |
| | | | |
Onion services and onion clients need these to make connections to
HsDirs, Introduction points, and Rendezvous points.
|
| | | |/
| |/| |
|
| |\ \ \
| |_|/
|/| |
| | |
| | | |
Draft APIs for onion services in tor-proto
See merge request tpo/core/arti!970
|
| | | | |
|
| | | |
| | |
| | |
| | | |
Onion services (and later, exits and caches) will need this.
|
| | | |
| | |
| | |
| | |
| | |
| | | |
This is a little tricky, but I think that we're not actually
exposing too much here. I expect we'll need to tweak this stuff
between now and our final version.
|
| | | |
| | |
| | |
| | |
| | | |
We will need these for onion services, to send and receive messages
of types not handled directly by the tor-proto crate.
|
| | | |
| | |
| | |
| | | |
(For consistency with other crates)
|
| |\ \ \
| |_|/
|/| |
| | |
| | | |
Prop304: Add extended SOCKS result codes for onion services
See merge request tpo/core/arti!978
|
| | | | |
|
| |\ \ \
| | | |
| | | |
| | | |
| | | | |
Do not .gitignore crates/*/fuzz/corpus
See merge request tpo/core/arti!982
|
| | | | |
| | | |
| | | |
| | | |
| | | | |
These are symlinks which are actually checked in. They should not be
ignored. (This caused trouble for some of my privsep tooling...)
|
| | | | | |
|
| |/ / /
| | |
| | |
| | |
| | |
| | | |
Without this,
cargo +stable clippy -p tor-netdoc --all-features
produces warnings.
|
| | | | |
|
| | | |
| | |
| | |
| | |
| | | |
(We don't yet use the code that uses it, but we might as well have
our unused code be up-to-date.)
|
| | | | |
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
This is in lieu of upgrading to the latest base64 crate, which has
a different API from the old one. Since we have to migrate either
way, we might as well use base64ct everywhere.
I don't think that most of these cases _require_ constant-time
base64, but it won't hurt.
|
| |/ / |
|
| |/ |
|
| |
|
|
| |
Fortunately, it adds very little to the arti-client API surface.
|
| |\
| |
| |
| |
| | |
Add onion service APIs to tor-netdir
See merge request tpo/core/arti!966
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
* It is the NetDir's responsibility to tell the caller what the time
period is.
* There can be up to two secondary time periods.
* Each time period has a single SRV.
* Secondary time periods only apply for onion services, when they
publish.
* When publishing, the correct input is a time period.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| | |
These are a bit complex internally, but the API they present is
pretty simple. I've left some discussion of points where the design
isn't totally fleshed out, and where we need to look harder at the
spec.
Part of #716.
|
| | |
| |
| |
| |
| |
| |
| |
| | |
SharedRandVal now holds only the 32-byte random value itself; the
"number of commits" field is in SharedRandStatus.
This commit also makes the SharedRandVal be exactly 32 bytes, since
we've set it to that value in the spec.
|
| | |
| |
| |
| |
| | |
The important addition here is the Copy derives, which affect API
design. I'm applying them to the types that are 32 byte or smaller.
|
| | |
| |
| |
| |
| |
| |
| | |
These are available unconditionally, since they represent
comparatively little storage and processing effort.
See param-spec.txt section 8 for the original information here.
|
| |/ |
|
| |\
| |
| |
| |
| |
| |
| | |
llcrypto: Implement secret-key blinding.
Closes #719
See merge request tpo/core/arti!964
|
| | |
| |
| |
| |
| |
| |
| |
| | |
Closes #719.
Due to a difference between ed25519-dalek and ed25519-donna,
converting these secret keys directly to public keys does not work.
I've documented this in a "Limitations" section.
|
| |\ \
| | |
| | |
| | |
| | | |
Fix typos
See merge request tpo/core/arti!965
|
| | | | |
|
| |\ \ \
| |/ /
|/| |
| | |
| | |
| | |
| | | |
Temporary fix for #715 and #569
Closes #715
See merge request tpo/core/arti!958
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | | |
|
| |\ \ \
| | | |
| | | |
| | | |
| | | | |
Onion service APIs, part 1.
See merge request tpo/core/arti!959
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
This module has types and operations needed in multiple places
for an onion service implementation. There are a bunch of
TODO hs-crypto comments that we'll need to fill in.
|
| | | | | |
|
| | | | |
| | | |
| | | |
| | | | |
This described the wrong type of key.
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
The `Ed25519Identity` and `RsaIdentity` types are not precisely
always used as relay identifiers: they are more generally used as
_key_ identifiers.
This will become relevant as `RsaIdentity` is used for authority
keys (as in authorities' VoterInfo blocks), and as `Ed25519Identity`
is used as the identifier behind an onion service key.
|
| |\ \ \ \
| |/ / /
|/| | |
| | | |
| | | | |
tor-proto: Remove some sensitive info from errors
See merge request tpo/core/arti!934
|
| | | | |
| | | |
| | | |
| | | | |
Not sure why the tree didn't have this newline already. "Whatever".
|
| | | | |
| | | |
| | | |
| | | |
| | | | |
The debug impl prints the handshake challenge, which we should
probably treat as sensitive.
|
| | | | |
| | | |
| | | |
| | | | |
Don't print the handshake value, but do print the display reason.
|