| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
| |
ExpandedKeypair already implements Ed25519SigningKey, so there is no
reason to not implement Ed25519PublicKey on it.
|
| |
|
|
| |
This eliminates some string slicing.
|
| |
|
|
|
|
|
|
| |
This commit adds #[allow(clippy::string_slice)] to all functions in the
code where string slices are used, alongside a TODO comment.
We do this add the function header to have it consistent, as things like
expression based allow's are still experimental.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
This commit executes maint/add_warning with the just added change to
deny string slices except in tests.
I recommend auditing this by checking out the previous commit followed
by running the script yourself and then verifying that the diff is
identical to this commit.
This commit makes cargo clippy fail. We will add exceptions in the next
commit.
|
| |
|
|
|
|
|
|
|
|
|
| |
When the circ-padding feature is enabled, we use maybenot, which does
not yet support rand 0.10. In the meantime, enabling this feature pulls
in rand 0.9. This is not ideal, but should be okay as a temporary
situation.
This also replaces the use of ReseedingRng (which was removed in 0.10)
with the reseeding_rng crate. This is somewhat less performant, but it
should be okay.
|
| |
|
|
|
|
|
|
| |
This is intended to be analogous to `RsaIdentity::from_hex()`.
I've found myself wanting this a few times, and it makes it easy to grab
a `master-key-ed25519` from the consensus and paste it into the code
without needing to do extra conversions.
|
| | |
|
| |
|
|
|
|
|
| |
I didn't even realize I was still conditionally using it on a feature.
That's what I get for always testing with all-features.
Signed-off-by: hashcatHitman <[email protected]>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is my initial attempt at deriving ConstantTimeEq and PartialEq.
This includes the previously missed HsSvcNtorKeypair and
HsClientDescEncKeypair types.
In tor-llcrypto, a few implementations still had to be done by hand, and
some types which previously derived normal PartialEq now derive it with
ConstantTimeEq.
I could not figure out how to properly set up the macros such that they
could be used both in the current crate and in others, so for the moment
they are duplicated. Just so I can get feedback. Ideally, this will be
replaced with a better solution before merge.
Signed-off-by: hashcatHitman <[email protected]>
|
| |
|
|
|
| |
`tor_llcrypto::pk::ed25519::PublicKey` is based on `ed25519_dalek::VerifyingKey`
and not `ed25519_dalek::SigningKey`.
|
| |
|
|
|
|
|
|
|
| |
dalek-cryptography is still on rand 0.8, so we need a compatibility
shim for the Rng.
Fortunately, since we merged interface-abstraction-of-the-daleks
(!2868), we no longer need to propagate this compatibility layer
throughout our codebase.
|
| |
|
|
|
|
|
|
|
|
|
| |
With this change, we'll no longer need to expose the types from
dalek-cryptography as part of our API, and we'll have more freedom
to switch ed25519 implementations, or to upgrade to a newer
`rand` ahead of their schedule.
Unlike with x25519-dalek, I had to tweak the API a bit: There's no
way to get a &PublicKey out of a Keypair now, and implementing the
old ed25519-dalek traits seemed unnecessary.
|
| |
|
|
| |
(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
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| | |
|
| |
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| | |
|
| |
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
| |
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.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
Remove all `use` statements for `TryFrom` and `TryInto`. These are
now redundant in Rust 2021.
|
| | |
|
| | |
|
|
|
This will cause some pain for now, but now is really the best time
to do this kind of thing.
|
