Previously, we had HKDF-for-session-version-3, which matches RFC 5869,
and HKDF-for-session-version-2, which produced slightly different
results. However, nothing in the current versions of Signal uses
anything but the RFC-compliant version. Therefore, this commit removes
support for version 2 and deprecates the entry points that take a
version:
- Java: The HKDFv3 class is deprecated in favor of static methods on
the HKDF class.
- Swift: The hkdf function that takes a 'version' parameter is
deprecated in favor of a new overload that does not.
- TypeScript: The HKDF class is deprecated in favor of a top-level
hkdf function.
- Rust: The libsignal-protocol implementation of HKDF has been removed
entirely in favor of the hkdf crate.
There are no significant benchmark deltas from this change, and a
minimal code size increase that's the cost for removing our own
implementation of HKDF. The deprecations can be removed as a later
breaking change.
- cargo update
- But stay on our fork of curve25519-dalek (pinned at 3.0.0)
- Update x25519-dalek from 1.0 to 1.1 (instead of 1.2) to stay
compatible with curve25519-dalek
- Update cpufeatures to 2.1 to match our dependencies
- Note that updating picky* resulted in more duplicate crates (rand*)
- Pin num-bigint-dig to a build that supports Cargo's -Zbuild-std,
because xargo + autocfg has stopped working with the new toolchain
- Remove xargo in favor of -Zbuild-std
Signal has a fork of curve25519-dalek to add some features that are
used by zkgroup. However, libsignal-protocol and poksho don't use
those features directly, and thus they don't depend on our fork
specifically. Anyone outside of Signal using libsignal-protocol can
thus use the standard curve25519-dalek and avoid building it twice.
Signal will continue using our fork thanks to the workspace patch in
the root Cargo.toml.
Additionally, remove all the passthrough features for customizing
curve25519-dalek; we don't use any of them, and clients can always
specify them directly.
This is overkill for most calls but multi-recipient messages require
potentially a lot of objects. The codegen is in the way of making a
surgical change at the moment so hitting it with a broad fix for
now. May return to add a conditional to the macro definition later.
- Drop our fork of Neon now that our changes have been integrated
- Adopt rename of EventQueue to Channel
- Add a napi-6 feature to signal-neon-futures to make it easier to test
under the configuration we're actually shipping
Both futures::executor::block_on and our own expect_ready were being
used to resolve futures that were, in practice, known to be
non-blocking. FutureExt::now_or_never handles that case more lightly
than block_on and more uniformly than expect_ready.
This lets us drop the dependency on the full 'futures' crate down to
just futures_util, which should help with compile time.
The signal-crypto struct Aes256Ctr32 is still useful because we use a
different nonce size than RustCrypto's "full block", and we provide a
convenience constructor to specify an initial counter value.
Now that RustCrypto aes-gcm-siv supports runtime-detected ARMv8 and
x86_64 crypto intrinsics, we don't need our own implementation, which
will be removed from signal-crypto in a later commit.
- Add a new "multi-recipient encrypt" entry point
- Add an "encrypt v1 sealed sender from UnidentifiedSenderMessage-
Content" entry point
- Add a public constructor for UnidentifiedSenderMessageContent
- Change group_encrypt to return a CiphertextMessage instead of bytes,
so it can be used with the above
- Java: add SenderKeyStore to SignalProtocolStore requirements
