summaryrefslogtreecommitdiff
path: root/crates/tor-hscrypto/src
Commit message (Collapse)AuthorAgeFilesLines
* clippy: deny `mod_module_files`Steven Engler2025-01-061-0/+1
| | | | | | Denies 'mod.rs' files for consistency. https://rust-lang.github.io/rust-clippy/master/index.html#mod_module_files
* tor-hscrypto: Move encodable key trait impls from tor-key-forge.Gabriela Moldovan2024-12-111-0/+111
| | | | | | | | | This enables us to get rid of the tor-key-forge -> tor-hscrypto dependency, partially addressing the TODO from `tor_key_forge::traits`. This commit is mostly code motion. Best reviewed with `--color-moved`. See also #1778
* add_warnings, *: Allow clippy::needless_lifetimesNick Mathewson2024-12-031-0/+1
| | | | | | | | 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.
* PoW: Consolidate feature flags into a single flag.Wesley Aptekar-Cassels2024-11-251-5/+1
| | | | | | | | | | | | | | | | | This replaces the hs-pow, hs-pow-full, hs-pow-v1, pow-v1, and pow-full features with a single hs-pow-full feature. It's possible that in the future we will want to split different schemes into different features, but we can do that when it comes up. For now, having this as a single flag makes it clearer what's going on, since the previous thing was not actually expressive enough to capture some things we care about (like "at least one pow scheme is enabled" that works in a future-compatible way). This change is not semver breaking since it's a experimental feature. Related: #1751
* tor-hscrypto: Add Verifier::seed() helper function.Wesley Aptekar-Cassels2024-11-251-0/+7
|
* tor-hscrypto: Add Seed::new.Wesley Aptekar-Cassels2024-11-251-0/+43
| | | | | This includes the ability to generate a seed that does not share a head with the previously used seed, which is generally what we want to do.
* tor-netdoc: Support writing pow-params line.Wesley Aptekar-Cassels2024-11-251-1/+1
| | | | | | | I'm not particularly happy with the code that does the actual writing out of the pow-params line, in particular the error handling there seems very verbose. However, I don't know of a better way to structure it given that APIs I'm working with.
* tor-hscrypto: Abolish the HasKind impl of HsIdParseError.Gabriela Moldovan2024-11-041-15/+0
| | | | | | | | | | Also changes the `ErrorKind` of `BadOnionAddress` to `ForbbiddenStreamTarget`. See context in https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/2246#note_3045683 Closes #1483
* Rename "memquota" feature to "memquota-memcost" when it's just HasMemoryCostIan Jackson2024-10-161-2/+2
| | | | It's not documented anywhere ATM. I will do that in a followup MR.
* hs-pow: Effort type improvements.Wesley Aptekar-Cassels2024-10-091-1/+35
| | | | | | | | The Effort type didn't have any const constructor and we had to disassemble it to do any arithmetic. This adds a const constructor and int/float saturating arithmetic methods. Co-authored-by: Micah Elizabeth Scott <[email protected]>
* tor-hscrypto: Fixup broken doc links.Wesley Aptekar-Cassels2024-10-093-4/+4
| | | | Co-authored-by: Micah Elizabeth Scott <[email protected]>
* hs-pow: Refactor to prefer stub types rather than cfg sprawl.Wesley Aptekar-Cassels2024-10-094-9/+17
| | | | | | | | | | | | | | | | | | | | | | In this design, the thin multiplexing layer between PoW types is always available when onion services are in use, but the specific pow schemes (and their dependency libraries) are gated by crate features everywhere. There are now no new cfg() gates. When the pow-v1 scheme is disabled, we can parse `pow-params v1` lines into an empty type (so clients know a PoW scheme exists that might be supported if they were configured differently). We currently don't save the contents of unknown hsdesc items. On the relaycell side, the hs ext module already sets a strong precedent for keeping unrecognized data as a byte vec, and it doesn't provide a good way to signal soft parse errors like unrecognized optional extensions. There, the `v1` type is completely optional, and services lacking a pow scheme suggested by a client would see one of these 'unrecognized' blobs. This isn't necessarily helpful but it fits the rest of the design. Co-authored-by: Micah Elizabeth Scott <[email protected]>
* tor-hspow: Big refactor, dissolve this crateWesley Aptekar-Cassels2024-10-099-0/+663
| | | | | | | | | | | | | | | | | My previous strategy here was to try and centralize hspow in one crate, writing it like a self-contained feature. That introduced friction in the data types, prompting the use of simplistic types at the netdoc/cell layers and full-featured types in the optional modules. This changes tactics, dissolving the low-level parts of tor-hspow into tor-hscrypto and the high-level parts into hsclient/hsservice. Full featured types are used everywhere now, but the tradeoff is that compile-time configurability is a lot more pervasive. Anything that knows about PoW types at all needs to be fully configured out. I took this opportunity to try a more complete set of crate features, allowing users to configure individual PoW schemes. Co-authored-by: Micah Elizabeth Scott <[email protected]>
* tor-hscrypto: Use the new "restricted discovery" terminology.Gabriela Moldovan2024-10-031-1/+1
| | | | Part of #1476
* Some HasMemoryCost impls in tor-hscryptoIan Jackson2024-10-021-0/+8
|
* tor_hsservice: add `impl From<&FooPublicKeySpecifier> for ↵Adam Joseph F0B74D717CDE8412A3E0D4D5F29AC8080DA8E1E02024-09-091-0/+12
| | | | | | | | | | | | | 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
* tor-hscrypto: Implement Eq for HsClientDescEncKey.Gabriela Moldovan2024-08-051-0/+2
| | | | Needed because such keys will be stored in the `OnionServiceConfig`.
* tor-hscrypto: Use collect_tuple to avoid unnecessary Vec allocation.Gabriela Moldovan2024-07-081-6/+3
|
* tor-hscrypto: Remove HsClientDescKeyParseError's HasKind impl.Gabriela Moldovan2024-07-081-12/+0
| | | | Prompted by https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/2246#note_3045656
* tor-hscrypto: Implement FromStr for HsClientDescEncKey.Gabriela Moldovan2024-07-081-3/+149
| | | | | | | | | | | | | | We will use this impl for parsing the authorized clients of a hidden service running in "restricted discovery" mode. NB: "Restricted discovery" is the new terminology for "services that require client authorization", i.e. services that implement "client authorization" as described in rend-spec HS-DESC-ENC[0]. Note we haven't fully transitioned to the new terminology yet (see #1476). Part of #1292 [0]: https://spec.torproject.org/rend-spec/hsdesc-encrypt.html#HS-DESC-SECOND-LAYER
* tor-hscrypto: Remove unnecessary Display wrapper.Gabriela Moldovan2024-07-081-17/+5
| | | | | | | | | | | I don't think we need a separate wrapper type for displaying `HsClientDescEncKey` keys in the "C Tor format" (`<auth-type>:<key-type>:<base32-encoded-public-key>`). I think this should be the canonical string representation of `HsClientDescEncKey`, so I'm removing the `display_authorized_client` function and corresponding `DisplayAuthorizedHsClientDescEncKey` wrapper type.
* tor-hscrypto: Add helper for encoding client auth keys in C Tor format.Gabriela Moldovan2024-06-271-0/+23
| | | | | | | This will enable us to implement the `arti hsc` client subcommand for generating client auth keys (#1281). Closes #1291
* Re-run maint/add_warning.Nick Mathewson2024-05-061-2/+2
| | | | This commit is automatically generated.
* Run maint/add_warning.Nick Mathewson2024-03-133-0/+3
|
* deny clippy::unchecked_duration_subtractiontrinity-1686a2024-02-291-0/+1
|
* tor-netdir: Add a unit test for HsDirParams::offset_within_srv_period.Gabriela Moldovan2024-01-241-1/+1
|
* tor-netdir, tor-hscrypto: Add function for computing SRV period offset.Gabriela Moldovan2024-01-241-2/+11
| | | | Part of #1166
* tor-hscrypto: Remove TimePeriodOffset, offset_within_period().Gabriela Moldovan2024-01-242-27/+2
| | | | | | These are now unused. Part of #1166
* tor-hsservice: Generate revision counter using the start of SRV period.Gabriela Moldovan2024-01-241-4/+2
| | | | Closes #1166
* hscrypto: Downgrade a TODO HSS comment.Nick Mathewson2024-01-141-1/+1
| | | | | This is not a blocker; it's just a code movement or duplication issue IIUC.
* Merge branch 'wallclock-time' into 'main'gabi-2502023-12-131-1/+3
|\ | | | | | | | | | | | | tor-hscrypto: Return 0 if the timestamp is before the start of the TP. Closes #1155 See merge request tpo/core/arti!1828
| * tor-hscrypto: Return 0 if the timestamp is before the start of the TP.Gabriela Moldovan2023-12-131-1/+3
| | | | | | | | | | | | | | | | | | | | | | | | #1155 was happening because we couldn't compute the offset of the current time from the start of the _next_ TP (`TimePeriod::offset_within_period` expected `when` to come after the start of the TP). `TimePeriod::offset_within_period` now returns an offset of 0 for timestamps that come before the start of the TP, to support computing revision counters for the descriptors uploaded to the HsDirs from the ring associated with the next TP. Fixes #1155
* | hscrypto: Remove a "TODO HSS" about a no-longer-unused type.Nick Mathewson2023-12-121-4/+0
|/
* llcrypto: Hide the members of ExpandedKeypair.Nick Mathewson2023-11-291-10/+9
| | | | | With this change, we no longer expose the ExpandedSecretKey unescorted, which makes it harder to misuse the API.
* llcrypto: Remove ExpandedSecretKey export.Nick Mathewson2023-11-291-5/+5
| | | | | | | 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.
* Remove RngCompatExt.Nick Mathewson2023-11-291-2/+1
| | | | | | | | | | 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.)
* Convert to the latest versions of dalek-cryptographyNick Mathewson2023-11-292-15/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* tor-hscrypto: Add a TODO re re-implementation of x25519 keypair genIan Jackson2023-11-231-0/+5
| | | | | | IMO it is quite undesirable to have multiple copies of "gen a secret key and make a keypair out of it". Add a TODO HSS and and a ref to arti#1137 which is related.
* tor-hscrypto: Add a docs TODO re the define_pk_keypair macroIan Jackson2023-11-231-0/+3
|
* tor-hscrypto: Define Keypair conversions for all curve25519 newtypesIan Jackson2023-11-232-9/+16
| | | | | | | | | 1. Move `impl From<SpecificKeypair> for curve25519::StaticKeypair` (which was just a bespoke impl for HsClientDescEncKeypair) into the define_pk_keypair macro, so everything has it. Currently the only other user of the curve25519_pair feature is HsSvcNtorKey. 2. Provide the reverse conversion too.
* tor-hscrypto: Move HsClientIntroAuthKey to a separate module (fmt).Gabriela Moldovan2023-11-201-16/+15
|
* tor-hscrypto: Move HsClientIntroAuthKey to a separate module.Gabriela Moldovan2023-11-201-0/+13
| | | | | | | | | We need to add a module-global `#[allow(deprecated)]` to silence the deprecation warnings coming from the derived `derive_more` impls of the 2 newly deprecated structs. Since we don't want the `allow` to apply to the entire `pk` module, let's put `HsClientIntroAuthKey` and `HsClientIntroAuthKeypair` in a separate module and apply the `#[allow(deprecated)]` there.
* tor-hscrypto: Deprecate HsClientIntroAuth{Key, Keypair}.Gabriela Moldovan2023-11-201-1/+4
| | | | Part of #1037
* tor-hscrypto: Make offset_within_period() work with timestamps from later ↵Gabriela Moldovan2023-11-161-2/+2
| | | | | | | | | | | periods. Hidden services can have multiple "active" time periods for which they generate descriptors. We need to be able to compute the offset of a timestamp from the start of a given time period, even if that timestamp falls within the "next" time period (for example, when publishing descriptors for the "previous" time period, the `when` timestamp will fall outside the `(start, end)` range of the "previous" time period).
* Implementation for AES-based Order-preserving encryptionNick Mathewson2023-11-163-0/+217
| | | | | | This is the approach from appendix F.2 in rend-spec. Part of #1053.
* tor-hscrypto: Add a From<&HsIdKeypair> impl for HsIdKey.Gabriela Moldovan2023-10-191-0/+6
| | | | | | | | Sometimes it's useful to have the ability to derive the `HsIdKey` from the keypair (for example, if we've just read the `HsIdKeypair` from the keystore and also need the `HsIdKey`, this `From` impl enables us to derive the public part of the key, instead of having to read it from the keystore).
* tor-hscrypto: Add a new constructor and an accessor for TimePeriod.Gabriela Moldovan2023-10-191-0/+42
|
* tor-hscrypto: Rename offset_in_sec to epoch_offset_in_sec.Gabriela Moldovan2023-10-191-5/+9
| | | | | | This renaming aims to make it clearer that this offset is _not_ the time between start of the epoch and the start of this time period, but rather the delta between our epoch and the Unix epoch, in seconds.
* tor-hsservice: Add HsClientDescEncKeypair.Gabriela Moldovan2023-09-252-0/+20
|
* tor-hscrypto: Reinstate HsDescSigningKey/HsDescSigningKeypair.Gabriela Moldovan2023-09-221-2/+0
| | | | We need it to sign descriptors.
generated by cgit v1.2.3 (git 2.46.0) at 2026-08-26 23:34:03 +0000