| Commit message (Collapse) | Author | Age | Files | Lines |
| | |
|
| |
|
|
|
| |
Nightly rustdoc now warns if you have a link that isn't necessary,
and if you have a link that might refer to two different things.
|
| |
|
|
| |
This fixes a needless_vec lint on nightly.
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
This removes the `# Availability` section from the
`convert_ed25519_to_curve25519_private` and
`convert_curve25519_to_ed25519_private` docs.
We don't generally have this sort of section anywhere else in the
codebase (we use unstable cargo-docs features to make sure items are
annotated correctly).
|
| |
|
|
|
|
| |
The `convert_curve25519_to_ed25519_private` and
`convert_ed25519_to_curve25519_private` functions are now exported by
`tor-llcrypto` if the `cvt-25519` feature is enabled.
|
| |
|
|
| |
convert_ed25519_to_curve25519_private.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
This adds a TODO explaining how convert_ed25519_to_curve25519_private
will need to be audited when we upgrade to the latest x25519-dalek.
This also adds a `debug_assertions` and a test that ensures
`StaticSecret::from` is clamping the input (when we bump x25519-dalek,
the assertions will fail, as the latest version doesn't do clamping in
StaticSecret::from).
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
In `ArtiNativeKeyStore`, private keys are stored in OpenSSH format.
However, `ssh-key` (the crate we use for parsing OpenSSH keys) doesn't
support x25519 keys. As a workaround, this type of key will stored
as ed25519 and converted to x25519 upon retrieval.
This commit implements the `convert_ed25519_to_curve25519_private`
conversion function (needed by `ArtiNativeKeyStore` to support x25519
keys).
Part of #900
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
=========================
Notes from nickm:
(This differs from pinkforest's original MR: It removes the
Cargo.lock changes and the version bump on tor-llcrypto.)
Minimal Cargo.lock changes from downgrade.
(These are exactly those changes generated by running "build" and
"test".)
There are several reasons to do this:
* It's best to bump all of our dalek dependencies at once to rc.3
or later, rather than the piecemeal approach we've been stuck
with so far.
* We don't want to do this bump right now, since there are some
tricky questions about clamping we need to figure out (see
#808), and we need to make sure we get them right, and we're in
a distracted this week.
* We _do_ need to move away from 2.0.0-rc.2 right now, since
it was causing a failure in `cargo install arti`, and then it
got yanked.
Thanks to pinkforest for helping us out here and explaining all of
this!
Fixes #926.
Commit-edited-by: Nick Mathewson <[email protected]>
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Per #798, we want to make sure that we never pass around an
`ed25519::SecretKey`; only an `ed25519::Keypair` (or
`ExpandedKeypair`). This is because, when you're computing an
ed25519 signature, you have to use the public key as one of your
inputs, and if you ever use a mismatched public key you are
vulnerable to a nonce reuse attack.
(For more info see
https://moderncrypto.org/mail-archive/curves/2020/001012.html )
|
| |
|
|
|
|
|
|
| |
This is like an `ed25519::Keypair`, except that instead of a
`SecretKey` it contains an `ExpandedSecretKey`.
We'll be using this to implement #798, where we impose a rule that
there must be no "unescorted" ed25519 secret keys.
|
| |
|
|
| |
The `new` function is deprecated in x25519-dalek 2.0.0-rc.2
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Unhelpfully, the spec uses the variable name `h` and the phrase
"blinding factor" for both the unclamped and clamped value. The
clamped value is internal to the algorithm.
In our code:
* Don't ever use the word "parameter" or variable name `param`.
This doesn't appear in the spec anywhere.
* Use `h` for the unclamped blinding factor, and `blinding_factor` for the
clamped blinding factor.
* Rename `blinding_factor` function to `clamp_blinding_factor`, since
in the spec's terminology it takes an (unclamped) "blinding factor"
and returns a (clamped) "blinding factor".
* State explicitly what thing in the spec the `h` parameters are.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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]>
|
| |
|
|
|
| |
Expose ED25519 signature length; make ValidatableEd25519Signature
implement Debug and Clone.
|
| | |
|
| | |
|
| |
|
|
|
|
| |
Without this,
cargo +stable clippy -p tor-netdoc --all-features
produces warnings.
|
| | |
|
| |
|
|
|
|
|
|
|
| |
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.
|
| |\
| |
| |
| |
| |
| |
| | |
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.
|
| | |
| |
| |
| | |
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.
|
| |/
|
|
|
|
| |
This type provides a common implementation for types that are
implemented as arrays of bytes that should only be compared
with constant-time comparisons.
|
| | |
|
| |
|
|
|
| |
It looks like, despite a few false starts, they've got this warning
right; there weren't any false positives.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
There are some places in the protocol where we have an all-zero RSA
identity that does not truly represent a key, but rather represents
an absent or unknown key. For these, it's better to use
`RsaIdentity::is_zero` instead of manually checking for a set of
zero bytes: it expresses the intent better, and ensures that the
operation is constant-time.
I am deliberately not introducing a more general IsZero trait here,
or implementing is_zero for anything else: This is the only one we
seem to need right now. We can generalize it later if we have to.
|
| |\
| |
| |
| | |
# Conflicts:
# crates/tor-netdir/semver.md
|
| | |
| |
| |
| | |
These are not secret.
|
| |/ |
|
| |\
| |
| |
| |
| |
| |
| | |
Implement functionality to construct signed Ed25519 certs.
Closes #511
See merge request tpo/core/arti!611
|
| | | |
|
| |/
|
|
|
|
|
|
|
|
|
|
|
|
| |
- arti#448 and arti!607 highlight an issue with upgrading `rsa`: namely,
the `x25519-dalek` version previously used has a hard dependency on
`zeroize` 1.3, which creates a dependency conflict.
- However, `x25519-dalek` version `2.0.0-pre.1` relaxes this dependency.
Reviewing the changelogs, it doesn't look like that version is
substantially different from the current one at all, so it should be
safe to use despite the "prerelease" tag.
- The new `x25519-dalek` version also bumps `rand_core`, which means we
don't have to use the RNG compat wrapper in `tor-llcrypto` as much.
closes arti#448
|
| |\ |
|
| | | |
|
| | | |
|
| | |
| |
| |
| |
| |
| | |
This only affects uses of thread_rng(), and affects them all more or
less indiscriminately. One test does not work with
ARTI_TEST_PRNG=deterministic; the next commit will fix it.
|
| | |
| |
| |
| |
| | |
Remove all `use` statements for `TryFrom` and `TryInto`. These are
now redundant in Rust 2021.
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
We perform this operation in a bunch of places, and most of them
use hex::decode(). That's not great, since hex::decode() has to do
heap allocation. This implementation uses hex::decode_to_slice(),
which should be faster.
(In the future we might choose to use one of the faster hex
implementations, but I'm hoping that this change will be sufficient
to get hex decoding out of our profiles.)
Part of #377.
|
| | |
| |
| |
| | |
No functional change.
|