| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
| |
These are in the spec and tor-hsclient is about to want them.
|
| | |
|
| |\
| |
| |
| |
| |
| |
| | |
Generate correct-ish socks5 errors for onion service errors.
Closes #736
See merge request tpo/core/arti!1279
|
| | |
| |
| |
| | |
Use this to emit HS_BAD_ADDRESS as appropriate.
|
| |/ |
|
| |
|
|
|
|
| |
* Return a more informative error type (instead of Option)
* Check that time periods are an integer number of seconds
* Decide not to change the semantics of an argument.
|
| |
|
|
|
| |
We updated and clarified the spec in arti!107, and noted the
remaining infelicities in proposal 342.
|
| | |
|
| |
|
|
|
|
|
|
| |
(I'm not removing it entirely since maybe we _should_ use it, and
maybe we _will_ as we do services. I've added a TODO HS for
removing it or using it, and removed the TODO HS at the head of
pk.rs about making sure that all the key types in the module really
belong there.)
|
| | |
|
| |
|
|
|
|
| |
I think it isn't actually a great idea for HsIdParseError to
implement ErrorKind, since the actual ErrorKind would depend
entirely on where the problematic ID came from.
|
| | |
|
| | |
|
| |
|
|
| |
We need to reuse this.
|
| |
|
|
|
| |
(It said that we want to deprecate all unescorted secret keys; in
fact, only unescorted EdDSA secrets are bad.)
|
| |
|
|
| |
Part of #798: We no longer use unescorted ed25519 secret keys.
|
| |
|
|
| |
Signed-off-by: Gabriela Moldovan <[email protected]>
|
| |
|
|
|
|
|
|
|
|
| |
The `HsClientSecretKeys` stored in the HS client connection context only
have the secret keys. Certain APIs (such as `HsDesc::parse`) expect a
keypair (both `HsClientDescEncKey` and `HsClientDescEncSecretKey`). This
`From` impl makes it possible to get a `HsClientDescEncKey` out of
`HsClientDescEncSecretKey`.
Signed-off-by: Gabriela Moldovan <[email protected]>
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
`AuthClient`s were originally meant to represent parsed `auth-client`
lines. In !1070, this struct was repurposed for representing individual
authorized clients in the HS descriptor encoder. However, hidden
services will likely use a list of public keys to represent the
authorized clients rather than a list of `AuthClient`s, as the
information from an `AuthClient` (`client_id`, `iv`, `encrypted_cookie`)
likely won't be immediately available to the hidden service.
This change updates the HS descriptor encoder to represent authorized
clients as a list of `curve25519::PublicKey`s. As such, it is now the
responsibility of the encoder to create the `client_id`, `iv`, and
`encrypted_cookie` using the available keys, the unencrypted descriptor
cookie, and HS subcredential.
Signed-off-by: Gabriela Moldovan <[email protected]>
|
| |
|
|
|
|
|
|
| |
* Don't ever use the words "parameter" or "param".
These doesn't appear in the spec anywhere.
* Use `h` as the variable name for the unclamped blinding factor,
and `blinding_factor` in function names.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Hidden services use blinded singing keys derived from the identity key
to sign descriptor signing keys.
Before this patch, the hidden descriptor builder represented its blinded
signing keys (`blinded_id`) as plain `ed25519::Keypair`s. This was not
ideal, as there was nothing preventing the caller from accidentally
initializing `blinded_id` with an unblinded keypair.
This introduces a new `HsBlindKeypair` type to represent blinded
keypairs.
Signed-off-by: Gabriela Moldovan <[email protected]>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
This introduces the `NetdocBuilder` trait described in
`netdoc-builder.md` and a new `tor-netdoc::doc::hsdesc::build` module,
which exports the `HsDescBuilder`. Hidden services will use
`HsDescBuilder` to build and encode hidden service descriptors.
There are several TODOs in the code that I'm planning to address
separately.
Partially addresses #745.
Signed-off-by: Gabriela Moldovan <[email protected]>
|
| |
|
|
| |
And add some clarity and todos about address errors.
|
| |
|
|
| |
This error is not great.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |\
| |
| |
| |
| | |
Implement HS state management
See merge request tpo/core/arti!1034
|
| | | |
|
| | |
| |
| |
| |
| | |
This is still not great, but it at least makes the output plausible to
read by eye.
|
| | |
| |
| |
| |
| |
| |
| |
| | |
Provide a more cookied "secret keys for use to connecting to a
particular HS" type, with a builder.
This wants to use config stuff, so oughtn't to be in tor-*crypto.
The individual types remain there.
|
| |/ |
|
| |
|
|
| |
Specifically, RendCookie, Subcredential, HsId, and HsBlindId.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Fixes an instance of #768.
The problem with the test vectors is that I used a random time
period number (1234) and the default-in-tor period length (1440)
without checking whether 1440 _meant_ minutes or seconds. I'll add
another test to Tor to make sure that the time period matches now.
With this change, I can test Tor-generated hsdescs with encryption,
so I'm fairly confident that the new behavior is correct.
|
| |
|
|
|
|
| |
Locally, the only functional effect is that now we refuse to handle
non-whole-number-of-minutes lengths - but since the consensus
parameter can't represent those, there's no overall functional change.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
| |
Generated with perl:
s/K([PS])_hs_intro_tid/K$1_hs_ipt_sid/g;
s/K([PS])_onion_ntor/K$1_ntor/g;
s/K([PS])_hs_intro_ntor/K$1_hss_ntor/g;
s/K([PS])_hs_desc_ephem/K$1_hss_desc_enc/g;
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
This logic is a bit tricky, so I've tried to document it and add
fairly good tests. The silver lining is that the external API for
all of this logic will make it invisible and hidden.
There are some cases where I added functions that I think might
eventually get lowered into MdConsensus: But I don't want to lower
too much right now, since the convention for our netdoc accessors is
that they are fairly unsophisticated, and they show you the document
as it is.
Closes #686
|
| |
|
|
|
| |
This panics on error, and we're fine with a panic on misbehavior in
tests.
|
| |
|
|
|
|
|
|
| |
This warning kind of snuck up on us! (See #748) For now, let's
disable it. (I've cleaned it up in a couple of examples, since
those are meant to be more idiomatic and user-facing.)
Closes #748.
|
| |
|
|
|
|
| |
It turns out that the credential is only calculated as an
intermediate result in order to blind keys and produce the
subcredential. As such, it has no need to leave the hscrypto module.
|
| | |
|
| | |
|
| | |
|