Registration IDs are used to detect if a device ID has been reused,
since the new device will (with high probability) use a different
randomly-generated registration ID from the old one. The server should
be able to validate this for SSv2 like it does for SSv1, though the
handling of this for SSv1 is in the various apps.
We still encode the "current" version in the message version byte, but
the part that the receiver will check is now based on the session's
original message version rather than the "current" version in the
sender. (Note that these are the /same/ version right now, so this
change won't have any effect on the current wire format.)
This matches the behavior of SignalMessage and PreKeySignalMessage.
The parameters for these constructors cannot be chosen correctly in
isolation; messages always need to be created as part of a session.
The Node APIs have been renamed with leading underscores rather than
removed because we *did* have tests that explicitly constructed
messages just to test that they faithfully preserve information. In
this case the parameters are plausible values but not used for
anything.
Debian has a more stable retention period for pinned dependencies (the
version of OpenJDK 8 we were using for Ubuntu is gone already!), and
it matches what the Signal-Android repository is doing.
We're optimizing for size overhead in this encoding, so forego the
flexibility of protobufs in favor of a flat encoding (though one that
still uses protobuf's varints). Additionally, this encoding includes
the recipients inline in the message so the client can dump it all to
server in one go.
As a side effect, this means an SSv2 message encoded for sending no
longer has the same format as one encoded for receiving when there's
only one recipient. Consequently, all the tests need to be modified to
"fan out" a multi-recipient message to several single-recipient
messages. For simplicity, the wrapper language tests only support this
operation for SSv2 messages sent to exactly one recipient.
- 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
Unlike the other two bridges, the Java representation of a
CiphertextMessage uses an interface with implementing classes, rather
than an opaque wrapper. But bridge_fn's ResultTypeInfo can model this
too, and it simplifies things to do so.
It's a payload message, something that would go inside a SignalMessage
or PreKeySignalMessage. Drop it from all the enums, and while we're
here let's sync up the CiphertextMessageType::SenderKey case with the
sealed sender content type and the envelope content type.
With distribution IDs embedded in SenderKeyMessage and
SenderKeyDistributionMessage, the abstraction of SenderKeyName (a
sender address + distribution ID tuple) is no longer pulling its
weight. Remove it from the implementation and the public API.
The distribution ID is used to identify which key a particular sender
is using to encrypt their SenderKeyMessage, so it has to be known as
part of decryption. The previous design had the distribution ID stored
alongside each message (perhaps on the "envelope" structure that's
received from the server), but that's harder to keep track of, and it
would only be present for certain message kinds anyway.
Clarifies the use of "ID" in SenderKey-related APIs. I've left
deprecated entry points for Java but not for Swift and TypeScript
(which are not in use yet).
- SenderKeyMessage::key_id -> chain_id (avoids double "key" in name)
- SenderKeyDistributionMessage::id -> chain_id (to match SKM)
- SenderKeyName::group_id -> distribution_id (it's not the global group ID)
As Java has no concept of slices and we need some way of doing partial
updates, since this is required to implement the JCE Cipher interface,
and Android uses it.
Previously we defined one entry point for FFI (Swift) that took an
extra "context" parameter (to pass through iOS's database
transactions), and one for JNI+Node that did not (no context needed
currently). But this is all in our glue layer, which doesn't need to
be a perfect reflection of the outside interface. Remove that
duplication by accepting a Context parameter for both JNI and Node
that, for now, must be null.
By disallowing arbitrary expressions, bridge_get_bytearray (and
bridge_get_optional_bytearray) ends up a lot more like bridge_get,
and can reuse the infrastructure in bridge_fn_buffer instead of
needing a separate per-bridge implementation.
Additionally, never look up a session by e164 when decrypting
sealed-sender messages.
This is an API-breaking change for both Java and Swift clients;
certain fields and arguments are no longer Optional. On top of that,
some tests may need to be updated to provide UUIDs instead of just
phone numbers.
