| Commit message (Collapse) | Author | Age | Files | Lines |
| |\
| |
| |
| |
| |
| |
| | |
tor-hscrypto: Return 0 if the timestamp is before the start of the TP.
Closes #1155
See merge request tpo/core/arti!1828
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
#1155 was happening because we couldn't compute the offset of the
current time from the start of the _next_ TP
(`TimePeriod::offset_within_period` expected `when` to come after the
start of the TP). `TimePeriod::offset_within_period` now returns an
offset of 0 for timestamps that come before the start of the TP, to
support computing revision counters for the descriptors uploaded to
the HsDirs from the ring associated with the next TP.
Fixes #1155
|
| |/ |
|
| |
|
|
|
| |
With this change, we no longer expose the ExpandedSecretKey
unescorted, which makes it harder to misuse the API.
|
| |
|
|
|
|
|
| |
This type was part of `hazmat`, and was no longer necessary anywhere
in our codebase. (It had one remaining user, which was easy enough
to remove.) By removing it, we remove the opportunity for using an
unescorted ed25519 private key.
|
| |
|
|
|
|
|
|
|
|
| |
This code was needed with the old version of dalek-cryptography,
which wasn't compatible with up-to-date versions of the `rand`
crate(s). But now that we've upgraded, we can drop this.
(We could have left it around and deprecated it, but we are already
making a breaking change to tor-llcrypto by upgrading
dalek-cryptography.)
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The main changes that we have to adjust for are as follows:
* In x25519-dalek:
* `StaticSecret` is now behind a feature.
* `StaticSecret::new` is deprecated in favor of
`StaticSecret::random_from_rng`.
* StaticSecret no longer does its own clamping.
* In ed25519-dalek:
* `SecretKey` has (in effect) been renamed to `SigningKey`. The name
`SecretKey` is now an alias for `[u8; 32]`.
* `SigningKey` is effectively a keypair, since it contains a
public key as well.
* `PublicKey` has been renamed to `VerifyingKey`.
* The functions to extract a signing key and verifying key have
been renamed as you might expect.
* `ExpandedSecretKey` has been moved to `hasmat` and no longer
implements `sign`.
* `ExpanededSecretKey` now has as its elements a scalar and a hash
prefix.
* Various functions that took `&[u8]` now take `&[u8; N]`.
* We no longer need a wrapper for older versions of rand.
There is a single test in tor-keymgr that does not pass. I've
marked it as ignore for now, in hopes that @gabi-250 can help me
figure it out.
This closes #808. There are several changes I want to make before
we merge, however. They are marked with TODO DALEK.
|
| |
|
|
|
|
| |
IMO it is quite undesirable to have multiple copies of "gen a secret
key and make a keypair out of it". Add a TODO HSS and and a ref to
arti#1137 which is related.
|
| | |
|
| |
|
|
|
|
|
|
|
| |
1. Move `impl From<SpecificKeypair> for curve25519::StaticKeypair`
(which was just a bespoke impl for HsClientDescEncKeypair)
into the define_pk_keypair macro, so everything has it.
Currently the only other user of the curve25519_pair feature is HsSvcNtorKey.
2. Provide the reverse conversion too.
|
| | |
|
| |
|
|
|
|
|
|
|
| |
We need to add a module-global `#[allow(deprecated)]` to silence the
deprecation warnings coming from the derived `derive_more` impls of the
2 newly deprecated structs. Since we don't want the `allow` to apply to
the entire `pk` module, let's put `HsClientIntroAuthKey` and
`HsClientIntroAuthKeypair` in a separate module and apply the
`#[allow(deprecated)]` there.
|
| |
|
|
| |
Part of #1037
|
| |
|
|
|
|
|
|
|
|
|
| |
periods.
Hidden services can have multiple "active" time periods for which they
generate descriptors. We need to be able to compute the offset of a
timestamp from the start of a given time period, even if that timestamp
falls within the "next" time period (for example, when publishing
descriptors for the "previous" time period, the `when` timestamp will
fall outside the `(start, end)` range of the "previous" time period).
|
| |
|
|
|
|
| |
This is the approach from appendix F.2 in rend-spec.
Part of #1053.
|
| |
|
|
|
|
|
|
| |
Sometimes it's useful to have the ability to derive the `HsIdKey` from
the keypair (for example, if we've just read the `HsIdKeypair` from the
keystore and also need the `HsIdKey`, this `From` impl enables us to
derive the public part of the key, instead of having to read it from the
keystore).
|
| | |
|
| |
|
|
|
|
| |
This renaming aims to make it clearer that this offset is _not_ the time
between start of the epoch and the start of this time period, but rather
the delta between our epoch and the Unix epoch, in seconds.
|
| | |
|
| |
|
|
| |
We need it to sign descriptors.
|
| | |
|
| |
|
|
| |
Needed to implement `PartialEq` for `AuthorizedClientConfig`.
|
| |
|
|
| |
This was missing the conventional spaces. Noticed in passing.
|
| |
|
|
|
| |
(Also, extend our macro so that we can wrap other curve25519 keys in
this way, if we want.)
|
| |
|
|
| |
This will be used by the descriptor publisher when building descriptors.
|
| |
|
|
|
|
| |
This function will be used by the descriptor publisher (it needs to
generate descriptors, and for that it needs the subcredential, which can
be derived from the `HsBlindIdKey` and `TimePeriod`).
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
Closes #950.
|
| |
|
|
| |
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]>
|
| | |
|