mirror of https://gitlab.torproject.org/tpo/core/arti http://git.dilluti0n.com/mirrors/arti.git/atom?h=arti-v1.1.12 2023-11-29T16:17:17Z 2023-11-29T16:17:17Z Nick Mathewson nickm@torproject.org 2023-11-29T16:17:17Z urn:sha1:af75131bcfca2c89d200fa13704be1f49a9fd94d (These types were all already re-exported from pk::ed25519.) 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-10-30T14:18:50Z Gabriela Moldovan gabi@torproject.org 2023-10-30T14:18:50Z urn:sha1:b5a22f3ab554329561c58b691d33a5fc3de0d5ad 2023-10-30T14:18:02Z Gabriela Moldovan gabi@torproject.org 2023-10-30T13:56:58Z urn:sha1:28a0b24db240cc24230c80732c5f4ba3a0b0d461 Representing the supported HTYPEs as `HandshakeType`s instead of `u32`s makes it more difficult to pass in wrong/invalid values to `HsDescBuilder::create2_formats`. This also fixes a descriptor publisher bug spotted by @jnewsome, where the advertised CREATE2 HTYPEs included HTYPE `1`, which is actually supposed to be a reserved value. The publisher now only advertises the `NTOR` HTYPE (just like C Tor). 2023-10-27T13:18:10Z Nick Mathewson nickm@torproject.org 2023-10-27T13:18:10Z urn:sha1:2c6724364ac1a5986c2d2a70f70d41af22ab7a19 2023-10-25T15:32:36Z Gabriela Moldovan gabi@torproject.org 2023-10-25T14:54:49Z urn:sha1:36f8b29ffd4e6291168cf4b34132d83249e076a4 2023-10-25T15:32:36Z Gabriela Moldovan gabi@torproject.org 2023-10-24T17:09:32Z urn:sha1:3df065a6b1af6f37d65517fa82a28b3e30928c71 2023-10-25T15:32:36Z Gabriela Moldovan gabi@torproject.org 2023-10-23T17:56:33Z urn:sha1:7edade162c8dd5f45f8d69496084f32003357e55 This will enable us to (eventually) the load the descriptor signing key cert from the keystore (as opposed to always recomputing it when building the `HsDesc`). Part of #1048 2023-10-25T15:32:36Z Gabriela Moldovan gabi@torproject.org 2023-10-24T16:35:48Z urn:sha1:35f3c1c9dc8a64b4f6f76e6e3d06b782b3d255d5