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.
This is useful for PlaintextContent messages (just
DecryptionErrorMessage for now), which can't include a group ID when
sent outside of sealed sender because it would reveal group
membership.
That is, when there's an error decrypting the inner payload of a
sealed sender message, instead of just saving the sender (and more
recently the content hint and group ID), save the whole decrypted
contents of the sealed sender message. This is necessary so that the
app can make a DecryptedErrorMessage from that failed payload.
This is complicated somewhat by the fact that the app also uses the
"short" constructor for the various Protocol*Exceptions, so we have to
keep those working.
This allows a device to know whether it's the one that sent a bad
message, and take action accordingly.
We could have a slightly more typesafe API here by using
ProtocolAddress and extracting the device ID, but that doesn't match
up with getting the device ID out of a sealed sender certificate.
- Default: sender will not resend; an error should be shown
immediately
- Resendable: sender will try to resend; delay any error UI if
possible
- Implicit: don't show any error UI at all; this is something sent
implicitly like a typing message or a receipt
This checks if there is an active sender state using the given ratchet
key, for use with decryption error messages. In this case, the app may
choose to archive the current session, or take even stronger actions
such as fetching new prekeys for the recipient.
For now this only supports DecryptionErrorMessage, which is sent
without session encryption because something might be wrong with the
session. In the future we might have other kinds of PlaintextContent;
what's important is that we don't mix up content that's okay to send
unencrypted with content that should never be in the clear.
Note that even though the content might not be session-encrypted, it
can still be put in a sealed sender message, which has its own
encryption.
This is a new message type that indicates that the current app was
unable to decrypt a received message (for instance, because they don't
have the sender key needed to decrypt a SenderKeyMessage). It includes
the timestamp of the original message as well as the "ratchet key" to
identify the 1:1 session it came from, if applicable.
This is a content message, like SenderKeyDistributionMessage. See next
commit.
The app-visible change is that sealedSenderMultiRecipientEncrypt now
takes a SessionStore as well. Sessions will be looked up in bulk using
a new SessionStore API, 'loadExistingSessions' or
'getExistingSessions`. The registration ID is then loaded from each
session and included in the resulting SSv2 payload.
The implementation is a bit of a divergence from some other APIs in
libsignal-client in that the "look up in bulk" step is performed in
the Java, Swift, or TypeScript layer, with the resulting sessions
passed down to Rust. Why? Because otherwise we'd pass a list of
addresses into Rust, which would have to turn them back into a Java,
Swift, or TypeScript array to call the SessionStore method. This would
be (1) a bunch of extra work to implement, and (2) a waste of CPU when
we already /have/ a list of addresses in the correct format: the
argument to sealedSenderMultiRecipientEncrypt.
This is an example of "the boundaries between the Rust and
Java/Swift/TypeScript parts of the library don't have to be perfect;
they're internal to the overall product". In this case, we've taken
that a little further than usual: usually we try to make the
libsignal-protocol API as convenient as possible as well, but here it
had to be a bit lower-level to satisfy the needs of the app language
wrappers. (Specifically, callers need to fetch the list of
SessionRecords themselves.)
P.S. Why doesn't v1 of sealed sender include registration IDs? Because
for SSv1, libsignal-client isn't producing the entire request body to
upload to the server; it's only producing the message content that
will be decrypted by the recipient. With SSv2, the serialized message
the recipient downloads has both shared and per-recipient data in it,
which the server must assemble from the uploaded request. Because of
this, SSv2's encrypt API might as well produce the entire request.
