mirror of https://gitlab.torproject.org/tpo/core/arti http://git.dilluti0n.com/mirrors/arti.git/atom?h=arti-v1.1.11 2023-11-29T15:55:04Z 2023-11-29T15:55:04Z Nick Mathewson nickm@torproject.org 2023-11-29T15:49:26Z urn:sha1:7fb24cb69da537ac04ab2dae80997c6d481622ef 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.) 2023-11-29T15:34:58Z Nick Mathewson nickm@torproject.org 2023-11-21T15:58:29Z urn:sha1:98037a2c788bd901679139178d25f855324637f3 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. 2023-11-27T16:48:03Z Jim Newsome jnewsome@torproject.org 2023-11-16T17:23:05Z urn:sha1:5d7f70c0fe515aee8640f336cc799b70828fd109 2023-05-23T17:33:07Z Nick Mathewson nickm@torproject.org 2023-05-23T17:33:07Z urn:sha1:24d67594d7117cf0b5b5e5283d7d92619494ed0e 2023-05-10T16:30:32Z Nick Mathewson nickm@torproject.org 2023-05-10T16:25:57Z urn:sha1:7ce808b75bb500f27ce7837d4f76cbf7fc1ee705 If we didn't do this, we would need to transfrom `EncodedLinkSpec`s into a `LinkSpec::Unrecognized`, which is not semantically right. What's more, every user of this API wants to consume encoded link specifiers, so encoding them early saves a little effort. 2023-05-10T16:19:37Z Nick Mathewson nickm@torproject.org 2023-05-10T16:19:37Z urn:sha1:a86aff8399655d0468a483d1ee6814653a37216f This lets us check the type of an `EncodedLinkSpec` as well, and lets us remove an interface that took a raw u8. 2023-05-10T15:23:39Z Nick Mathewson nickm@torproject.org 2023-05-10T15:23:39Z urn:sha1:02785ca6505572bdbfaa560178f299e30f7bc7e8 2023-03-06T13:46:40Z Nick Mathewson nickm@torproject.org 2023-03-06T13:46:40Z urn:sha1:1254a8b86ec4aab8e8078d91459bf8982a7f759b (This is the encrypted information inside the INTRODUCE2 cell; it's used by the client to tell the service where to find its rendezvous point.) 2023-03-01T16:18:50Z Nick Mathewson nickm@torproject.org 2023-03-01T16:18:50Z urn:sha1:03df452f7bc7491bfe2e5e813a0b7bf6ca036df9 2023-03-01T12:38:56Z Nick Mathewson nickm@torproject.org 2023-02-27T20:38:47Z urn:sha1:8c9a1a6fad6fa34dd4ff42795d5c698f0928b331 The old code parsed and encoded a signature and a mac... but there was no way to actually set them properly. Now EstablishIntro is built around an EstablishIntroBody, and has the ability to check signatures and macs. Because there is no way to handle one of these messages if we can't check the signature, we no longer accept unrecognized `auth_key` types in this message. I've added a test to make sure that we can validate a message from the C tor implementation, and a test to make sure we can validate our own cells. I also had to modify the previous tests so that their keys were well-formed.