| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
| |
(The u8 code was written before RelayCellFormat::V1 was introduced.)
|
| | |
|
| |
|
|
|
|
| |
See discussion at torspec#328: it's important that our
SENDME authentication tag always be taken based on the
_encrypted_ cell.
|
| | |
|
| |
|
|
|
|
|
|
| |
This provides all the operations from proposal 359,
along with the necessary integration and unit tests to make sure
that they are behaving properly.
Closes #1943
|
| | |
|
| |
|
|
|
|
|
| |
These are a tweakable block cipher, and a pseudorandom byte stream.
This commit includes test vectors, which were generated from the
Python reference implementation and confirmed with a less optimized
Rust implementation.
|
| | |
|
| | |
|
| |
|
|
|
|
| |
(We'll need these tags both to implement authenticated SENDMES
at the relay side, and also to make sure that cgo is generating them
correctly.)
|
| |
|
|
|
|
| |
CGO will need this argument so that it can authenticate
the command as part of its crypto operations.
(Trying to meddle with RELAY vs RELAY_EARLY will no longer work!)
|
| |
|
|
|
|
| |
It seems very likely that, as with client crypto,
we'll want relay crypto to separable into "forward" and "reverse"
objects, so that the two can be used more or less independently.
|
| |
|
|
|
|
|
|
|
|
| |
This makes the behavior of "originate" match the behavior of
OutboundClientLayer::originate_for, which creates the message
_and_ encrypts it. This will be necessary for CGO, where
"originate" and "encrypt" are not easily separated operations.
(Nothing uses this trait yet, since relay circuits aren't yet a thing,
so it's a good time to get it right.)
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
Since we're about to have a second kind of relay cell crypto,
it makes sense to move this module.
This change is pure code movement.
|
| |
|
|
| |
(Also note a couple of other CGO-related issues)
|
| |
|
|
| |
ntor v3 is now always enabled.
|
| |
|
|
| |
- `try_fill_bytes()` is no longer a member of RngCore.
|
| |
|
|
| |
- `rand::thread_rng()` has been deprecated and renamed to `rand::rng()`
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We introduce the new constructor and call it at the error generation
sites. But there is still not yet any functional change.
Change the type of Truncated's field to be Sensitive.
The original reason for not doing this no longer applies, since we
don't generally want to open-code construction of this variant.
Conveniently, changing the type means we get to find all the sites
where one *is* constructed and adjust them.
In reader.rs and tor-proto we can just call incomplete_error.
In tor-cell, there's a call site where we previously provided an
underestimate, and where the Reader isn't available. We adjust that
ad-hoc but this is fine because the error variant will
change. (relaycell is using a Reader from from_slice.)
|
| | |
|
| |
|
|
| |
This will allow us to fix #1592, but it doesn't do so yet.
|
| |
|
|
|
|
|
| |
I'm not sure how to resolve these. See #1467.
We ought to fix them before they propagate to +stable, particularly
since after !2242 they'll break CI.
|
| | |
|
| |
|
|
|
|
| |
The old code produced a warning from clippy nightly; we may as well
update to use the new associated consts. (They've been there since
Rust 1.4x.)
|
| | |
|
| |
|
|
|
|
| |
This lets us paramaterize types and functions by a particular relay cell
format. We use this e.g. to statically parameterize the cell crypto
functions, thereby removing some run-time branching in the hot path.
|
| | |
|
| | |
|
| |
|
|
|
| |
Different formats will use different ranges for the `recognized` and
`digest` fields.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
Resolves clippy complaints about needless fallible conversions.
|
| |
|
|
|
|
|
|
|
|
| |
An encoded set of extensions in the ntorv3 handshake includes a header
with the number of extensions. This change adds that header.
It also changes `write_many_onto` to take a slice instead of an
iterator, since we need to know the number of extensions up-front. In
principle we could take a clonable iterator instead and use
Iterator::count, but it's probably not worth the extra complexity.
|
| |
|
|
|
|
|
|
|
|
| |
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.
|
| | |
|
| | |
|
| | |
|
| | |
|
