| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
| |
Denies 'mod.rs' files for consistency.
https://rust-lang.github.io/rust-clippy/master/index.html#mod_module_files
|
| |
|
|
|
|
|
|
| |
In 1.83, this warning triggers on many of our crates.
We're thinking of fixing them all, but for now,
we're going to disable the warning.
This is part of #1765.
|
| |
|
|
| |
(fmt)
|
| |
|
|
| |
It's not documented anywhere ATM. I will do that in a followup MR.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
FooKeypairSpecifier` instances
This adds the following trivial `From` instances:
- tor_hsservice: impl From<&HsIdPublicKeySpecifier> for HsIdKeypairSpecifier
- tor_hsservice: impl From<&BlindIdPublicKeySpecifier> for BlindIdKeypairSpecifier
- tor_hscrypto::pk: impl From<HsBlindIdKeypair> for HsBlindIdKey
- tor_llcrypto::pk::ed25519: impl From<ExpandedKeypair> for PublicKey
- tor_keymgr::mgr: impl From<TestKey> for TestPublicKey
- tor::hscrypto::pk: impl From<HsIdKeypair> for HsIdKey
|
| |
|
|
|
|
|
|
|
| |
Now it exists unconditionally so that we can have our assertion for
public key consistency happen unconditionally. (Blinding secret
keys is not remotely in the critical path, so I'm not concerned
about the critical path.)
From a suggestion from Gabi on !2341.
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
The `blind_keypair` function should only call `blind_pubkey` when it
is present.
Also, fix the documentation: blind_keypair is a hsv3-service function,
not a hsv3-client function.
Closes #1504.
|
| |
|
|
| |
This commit is automatically generated.
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
Resolves clippy complaints about needless fallible conversions.
|
| |
|
|
|
| |
FTR I don't think agree with clippy on this question, but then I often
don't.
|
| |
|
|
| |
Removes a TODO HSS, since this trait is generally useful.
|
| |\
| |
| |
| |
| | |
Followups from MSRV 1.70 upgrade
See merge request tpo/core/arti!1785
|
| | | |
|
| |/ |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
With this change, we no longer expose the ExpandedSecretKey
unescorted, which makes it harder to misuse the API.
|
| | |
|
| |
|
|
| |
(These types were all already re-exported from pk::ed25519.)
|
| |
|
|
|
|
|
| |
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.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
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 will be useful in preference to the regular Mac trait for the
places where we need to pass a Mac key around, but we don't need to
support incremental operation.
Part of arti#993, where we want to expose a MAC object without
exposing sensitive data.
|
| | |
|
| |
|
|
| |
This fixes a needless_vec lint on nightly.
|
| | |
|
| |
|
|
| |
Closes #950.
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
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.
|
| | |
|