mirror of https://gitlab.torproject.org/tpo/core/arti http://git.dilluti0n.com/mirrors/arti.git/atom?h=arti-v1.3.0 2023-11-29T17:42:03Z 2023-11-29T17:42:03Z Nick Mathewson nickm@torproject.org 2023-11-29T17:42:03Z urn:sha1:4ee2039934e4e87919eba9496eaf2645055f2c73 2023-11-29T17:10:18Z Nick Mathewson nickm@torproject.org 2023-11-29T17:10:18Z urn:sha1:adc3209c6bef9cc03542c31c22c0f308938e1643 With this change, we no longer expose the ExpandedSecretKey unescorted, which makes it harder to misuse the API. 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-05-18T15:00:43Z Nick Mathewson nickm@torproject.org 2023-05-18T15:00:43Z urn:sha1:dcec7ca2dc6563e5277f5e913759ab19884e2e69 Per #798, we want to make sure that we never pass around an `ed25519::SecretKey`; only an `ed25519::Keypair` (or `ExpandedKeypair`). This is because, when you're computing an ed25519 signature, you have to use the public key as one of your inputs, and if you ever use a mismatched public key you are vulnerable to a nonce reuse attack. (For more info see https://moderncrypto.org/mail-archive/curves/2020/001012.html ) 2023-01-27T13:27:47Z Nick Mathewson nickm@torproject.org 2023-01-27T12:49:39Z urn:sha1:bf04641c6818cb2c87c6ed9cf463a5710f8919d2 This warning kind of snuck up on us! (See #748) For now, let's disable it. (I've cleaned it up in a couple of examples, since those are meant to be more idiomatic and user-facing.) Closes #748. 2023-01-20T13:06:30Z Nick Mathewson nickm@torproject.org 2023-01-19T19:50:07Z urn:sha1:889206cde4ef29d7d10bda546f8ad518eb09c290 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. 2022-09-10T12:39:47Z trinity-1686a trinity@deuxfleurs.fr 2022-09-10T12:39:47Z urn:sha1:8e7a904260dfe344eed70a9eef109695544347c1 2022-04-26T16:16:22Z Nick Mathewson nickm@torproject.org 2022-04-25T19:39:26Z urn:sha1:aaab6f38122261f7527e9a04b24972d09b775689 Now that we require Rust 1.56, we can upgrade to AES 0.8. This forces us to have some slight API changes. We require cipher 0.4.1, not cipher 0.4.0, since 0.4.0 has compatibility issues with Rust 1.56. 2022-04-25T17:06:26Z Nick Mathewson nickm@torproject.org 2022-04-25T16:40:33Z urn:sha1:2f6bc6bdc431fa36de70a167eea777dcf3f60bf2 Remove all `use` statements for `TryFrom` and `TryInto`. These are now redundant in Rust 2021. 2022-02-20T14:09:38Z Nick Mathewson nickm@torproject.org 2022-02-20T14:09:38Z urn:sha1:dd55f5ce2d0120733d1eb488dfa114f1c136c733 This exception is no longer necessary now that the underlying CI bug is fixed.