summaryrefslogtreecommitdiff
path: root/crates/tor-hscrypto/src/pk.rs
Commit message (Collapse)AuthorAgeFilesLines
* 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
* Run maint/add_warning.Nick Mathewson2024-03-131-0/+1
|
* 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-291-14/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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: Define Keypair conversions for all curve25519 newtypesIan Jackson2023-11-231-9/+0
| | | | | | | | | 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: 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-hsservice: Add HsClientDescEncKeypair.Gabriela Moldovan2023-09-251-0/+16
|
* tor-hscrypto: Reinstate HsDescSigningKey/HsDescSigningKeypair.Gabriela Moldovan2023-09-221-2/+0
| | | | We need it to sign descriptors.
* tor-hscrypto: Implement PartialEq for HsClientDescEncKey.Gabriela Moldovan2023-09-181-0/+6
| | | | Needed to implement `PartialEq` for `AuthorizedClientConfig`.
* hscrypto: Define a keypair type for HsSvcNtor{,Secret}KeyNick Mathewson2023-09-171-0/+1
| | | | | (Also, extend our macro so that we can wrap other curve25519 keys in this way, if we want.)
* tor-hscrypto: Impl From<&HsBlindIdKeypair> for HsBlindIdKey.Gabriela Moldovan2023-08-251-0/+7
| | | | This will be used by the descriptor publisher when building descriptors.
* tor-hscrypto: Add a function for deriving the subcredential.Gabriela Moldovan2023-08-251-3/+15
| | | | | | This function will be used by the descriptor publisher (it needs to generate descriptors, and for that it needs the subcredential, which can be derived from the `HsBlindIdKey` and `TimePeriod`).
* Run maint/add_warning to add lint block everywhereIan Jackson2023-08-231-0/+1
|
* Run maint/add_warning to actually apply new lint allowsIan Jackson2023-07-101-0/+1
|
* hscrypto: downgrade a comment to HSSNick Mathewson2023-06-221-1/+1
|
* New ErrorKind for invalid onion addressesNick Mathewson2023-06-221-0/+15
| | | | Use this to emit HS_BAD_ADDRESS as appropriate.
* hscrypto: comment out an unused key type.Nick Mathewson2023-06-131-5/+6
| | | | | | | | (I'm not removing it entirely since maybe we _should_ use it, and maybe we _will_ as we do services. I've added a TODO HS for removing it or using it, and removed the TODO HS at the head of pk.rs about making sure that all the key types in the module really belong there.)
* hscrypto: Remove a TODO about extending an internal macro.Nick Mathewson2023-06-131-2/+0
|
* hscrypto: Remove a TODO about implementing ErrorKind.Nick Mathewson2023-06-131-1/+0
| | | | | | I think it isn't actually a great idea for HsIdParseError to implement ErrorKind, since the actual ErrorKind would depend entirely on where the problematic ID came from.
* hscrypto: clarify and downgrade TODOs about blinding secretsNick Mathewson2023-06-131-2/+10
|
* hscrypto: Remove an incorrect comment.Nick Mathewson2023-05-181-5/+0
| | | | | (It said that we want to deprecate all unescorted secret keys; in fact, only unescorted EdDSA secrets are bad.)
* hscrypto: Replace ed25519 secret keys with keypairsNick Mathewson2023-05-181-42/+32
| | | | Part of #798: We no longer use unescorted ed25519 secret keys.
* hscrypto: Add comment about impl that will be removed after we address #798.Gabriela Moldovan2023-05-031-0/+2
| | | | Signed-off-by: Gabriela Moldovan <[email protected]>
* hscrypto: Add From impl for deriving KP_hsc_desc_enc out of KS_hsc_desc_enc.Gabriela Moldovan2023-05-031-0/+6
| | | | | | | | | | The `HsClientSecretKeys` stored in the HS client connection context only have the secret keys. Certain APIs (such as `HsDesc::parse`) expect a keypair (both `HsClientDescEncKey` and `HsClientDescEncSecretKey`). This `From` impl makes it possible to get a `HsClientDescEncKey` out of `HsClientDescEncSecretKey`. Signed-off-by: Gabriela Moldovan <[email protected]>
* Debug as hex strings for HsBlindId and HsDirIndexIan Jackson2023-03-311-2/+3
|
* Stop requiring the caller to supply `AuthClient`s.Gabriela Moldovan2023-03-311-0/+15
| | | | | | | | | | | | | | | | | | `AuthClient`s were originally meant to represent parsed `auth-client` lines. In !1070, this struct was repurposed for representing individual authorized clients in the HS descriptor encoder. However, hidden services will likely use a list of public keys to represent the authorized clients rather than a list of `AuthClient`s, as the information from an `AuthClient` (`client_id`, `iv`, `encrypted_cookie`) likely won't be immediately available to the hidden service. This change updates the HS descriptor encoder to represent authorized clients as a list of `curve25519::PublicKey`s. As such, it is now the responsibility of the encoder to create the `client_id`, `iv`, and `encrypted_cookie` using the available keys, the unencrypted descriptor cookie, and HS subcredential. Signed-off-by: Gabriela Moldovan <[email protected]>
* tor-hscrypto: key blinding: Use consistent terminologyIan Jackson2023-03-281-10/+12
| | | | | | | | * Don't ever use the words "parameter" or "param". These doesn't appear in the spec anywhere. * Use `h` as the variable name for the unclamped blinding factor, and `blinding_factor` in function names.
* Use the type system to enforce use of blinded keys.Gabriela Moldovan2023-03-271-0/+24
| | | | | | | | | | | | | | | 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]>
* Improve error from HsId parse of "www.B32.onion"Ian Jackson2023-03-091-2/+11
| | | | And add some clarity and todos about address errors.
* Test HsId parse of subdomainIan Jackson2023-03-091-0/+1
| | | | This error is not great.
* Use strip_suffix_ignore_ascii_case to quickly reject non-.onion HsId (fmt)Ian Jackson2023-03-081-1/+3
|
* Use strip_suffix_ignore_ascii_case to quickly reject non-.onion HsIdIan Jackson2023-03-081-3/+3
|
* Impl Redactable for HsIdIan Jackson2023-03-071-1/+25
|
* Debug HsId as the .onion; retain the hex printing as {:x}Ian Jackson2023-03-071-3/+10
|
* impl Display for HsIdIan Jackson2023-03-071-1/+144
|
* tor-llcrypto: Add a TODO re impl Redactable for HsIdIan Jackson2023-03-011-0/+1
|
* tor-hscrypto: Provide manual Debug impl for HsIdIan Jackson2023-03-011-1/+16
| | | | | This is still not great, but it at least makes the output plausible to read by eye.
* HS secret keys: Move aggregate/config to tor-hsclientIan Jackson2023-03-011-11/+0
| | | | | | | | Provide a more cookied "secret keys for use to connecting to a particular HS" type, with a builder. This wants to use config stuff, so oughtn't to be in tor-*crypto. The individual types remain there.
* hscrypto: Use minutes, not seconds, in blinding parameter.Nick Mathewson2023-02-101-8/+4
| | | | | | | | | | | | Fixes an instance of #768. The problem with the test vectors is that I used a random time period number (1234) and the default-in-tor period length (1440) without checking whether 1440 _meant_ minutes or seconds. I'll add another test to Tor to make sure that the time period matches now. With this change, I can test Tor-generated hsdescs with encryption, so I'm fairly confident that the new behavior is correct.
generated by cgit v1.2.3 (git 2.46.0) at 2026-08-27 09:03:00 +0000