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 <gabi@torproject.org>
`NetdocText` is a wrapper around a `String` and a type marker. The type
annotation proved of limited use, and made the netdoc builder API
somewhat awkward to use.
Signed-off-by: Gabriela Moldovan <gabi@torproject.org>
Unlike `hsdesc::IntroPointDesc`, `hsdesc::build::IntroPointDesc`
represents link specifiers as `LinkSpec`s rather than
`UnparsedLinkSpec`s.
Since this is a general-purpose representation of an introduction point
and not merely an intermediate representation for decoding/encoding, it
will probably need to be factored out of `tor-netdoc` at some point.
Signed-off-by: Gabriela Moldovan <gabi@torproject.org>
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 <gabi@torproject.org>
These are used in multiple places (and will also be used by the HS
descriptor encoder later on), so let's make them named constants.
Signed-off-by: Gabriela Moldovan <gabi@torproject.org>
This makes some code a bit more concise, as it allows us to make
`Strings` into `ItemArgument`s without calling `.as_str()`.
Signed-off-by: Gabriela Moldovan <gabi@torproject.org>
This makes our implementation behave the same as the C tor
implementation, by validating all of the expiration and signatures
on the certificates in the inner document.
(It is still not semantically necessary to check these certs: the
document in which they appear is already signed by the key with
which they are allegedly signed.)
Closes#744
These crates have had small code changes, but no API additions:
tor-config
tor-socksproto
tor-cert
tor-chanmgr
tor-ptmgr
tor-guardmgr
tor-circmgr
tor-dirclient
tor-dirmgr
arti
tor-hsservice
tor-congestion
These crates have had API extensions:
fs-mistrust
tor-llcrypto
tor-bytes
tor-checkable
tor-linkspec
tor-netdoc
tor-persist
arti-client
These are API breaks, but the crates themselves are currently
100% experimental, so there's no need to bump the minor versions
according to our semver rules.
It said to check whether C enforces an absence of extraneous bytes
at the end of the link specifiers. It does, in
`hs_desc.c:decode_link_specifiers()`, where it says:
```
if (link_specifier_list_parse(&specs, decoded,
(size_t) decoded_len) < decoded_len) {
goto err;
}
```
The comparison with "decoded_len" checks whether all the bytes were
decoded.
There's a blanket impl of Itertor for &mut impl Iterator, so this
isn't necessary, and it prevents us passing iterators by value
producing syntactic vinegar.
We want to fuzz these parsers, but there's no currently way to get
at the parsers for inner documents without going through a lot of
encryption. (Coverage-guided fuzzers are powerful, but they
can't find SHA3 preimages.)