Rather than embedding a server certificate inside every sender
certificate, future sender certificates will be able to reference
their server certificate by ID as long as all receivers have a version
of libsignal containing that certificate.
This change also handles the sender ACI being represented as bytes
instead of a string.
The "fingerprint" / safety number operations *are* tied to the
"protocol" in that they provide a way to verify identity keys, but
they are also completely distinct from the message handling that the
rest of SignalProtocolError is used for.
- arrayref can be replaced by split_first_chunk -- not quite as
concisely, but actually a little safer, and no macros involved
- array-concat has an equivalent in const_str
- num_enum has already been replaced by derive_more
- The test using regex has been removed
- Drop X3DH tests
- Drop cross-version tests with libsignal v0.12 and v0.21
- Change session benchmarks to use PQXDH, which is relevant if doing
comparisons before/after this commit.
This known-answer test was originally ported over from
libsignal-protocol-java, but did not produce the same results. Why?
Because one of the private keys chosen by libsignal-protocol-java for
its test was unclamped, while libsignal-the-Rust-implementation always
clamps private keys as part of deserialization, not just generation.
Consequently, the public key didn't actually correspond to the private
key according to our modern libsignal.
Rather than try to line up exactly with what libsignal-protocol-java
was coincidentally doing, this commit clamps the private key, computes
the resulting public key, and verifies a new
consistent-between-both-sides outcome.
This PR integrates a post-quantum ratchet (SPQR) into libsignal, using an API that maintains its own internal chain and provides per-message keys. In doing so, it also aims to be fully backwards-compatible with current clients and stored session state.
## Backwards compatibility with current clients
Remote clients that connect to us or that we connect to may not have this integration. If they don't, their SignalMessage wire format should still deserialize, and in doing so we'll receive an empty pq_ratchet field. SQPR handles this internally, by downgrading the protocol version to "version 0" or "don't do anything". Note that should we eventually want to disallow this, we can do so via increasing the `min_version` field passed into the SQPR init functions to V1. This is also the method by which we would upgrade SQPR from v1 to a future v2, etc.
## Opt-in
The publicly facing API calls for this now expose an explicit opt-in via a passed-in `use_pq_ratchet` bool (and associated enums in language-specific APIs). If false, they default to SQPR `v0`, IE: none. If true, they try to set up SPQR on new sessions, but will downgrade if the remote party cannot or will not do the same.
This fixes a bug introduced by cd36118 where starting a new session
locally would prevent incoming messages on a previous session from
being decrypted if that session hadn't advanced past the "pre-key"
stage. Fix this by promoting the session *before* successful
decryption instead of after; since we won't *save* the promotion
unless the message decrypts successfully, there's ultimately no change
in either the failure or success cases *except* when hitting this bug.
