| Commit message (Collapse) | Author | Age | Files | Lines |
| |\
| |
| |
| |
| | |
tor-key-forge: Add RSA key types.
See merge request tpo/core/arti!3236
|
| | | |
|
| | | |
|
| | |
| |
| |
| | |
As discussed with gabi on IRC today.
|
| | |
| |
| |
| |
| |
| |
| | |
Some things I'm still considering here:
* We may want to define a tor_llcrypto::pk::rsa::Signature newtype.
* We likely want to rename tor_llcrypto::pk::rsa::PrivateKey to RsaKeypair.
|
| | |
| |
| |
| | |
This feature has been removed from nightly, in favor of doc_cfg.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The macros to deftly derive `ConstantTimeEq` and `PartialEq` (for
`ConstantTimeEq`) are now only defined in `tor-llcrypto` and exported.
The macro to deftly derive `ConstantTimeEq` is now struct only and uses
`subtle::Choice::from(1)` for improved clarity.
Signed-off-by: hashcatHitman <[email protected]>
|
| | |
| |
| |
| |
| |
| |
| | |
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]>
|
| |/
|
|
|
|
|
| |
Exposed `as_bytes` on `curve25519::StaticSecret`, allowing a shared
reference to the secret bytes rather than needing to copy them.
Signed-off-by: hashcatHitman <[email protected]>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
First, run
```
git grep -l "^edition =" |
xargs perl -i -pe 's/^edition *=.*/edition = "2024"/;'
```
Second, manually verify that all Cargo.toml files have changed,
and nothing else has changed.
Third, run cargo fmt again.
|
| |
|
|
|
| |
`tor_llcrypto::pk::ed25519::PublicKey` is based on `ed25519_dalek::VerifyingKey`
and not `ed25519_dalek::SigningKey`.
|
| |
|
|
| |
See #2060.
|
| |
|
|
|
|
| |
- Replaced `once_cell::sync::Lazy` with `std::sync::LazyLock`.
Signed-off-by: hashcatHitman <[email protected]>
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
We want to require that whenever we generate a key that's persistent
(stored in KeyMgr), it's going to be made from a stronger-than-usual
Rng. This trait helps us enforce that.
We also add a FakeEntropicRng struct to use for testing.
Note that this turned up a case that we'd missed, which required
an internal change in tor-hsservice.
|
| | |
|
| |
|
|
|
|
| |
This Rng combines inputs from several sources,
including OsRng, to minimize the likelihood
of falling to a vulnerability in any particular one.
|
| |
|
|
| |
- The Rng::gen() functions have been renamed to Rng::random().
|
| |
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
| |
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 curve25519 implementations, or to upgrade to a newer
`rand` ahead of their schedule.
|
| |
|
|
|
|
| |
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.)
|