libsignal-net-chat builds higher-level APIs on top of libsignal-net's
ChatConnection, while also abstracting for a future using a
non-WebSocket-message-based transport for these requests. It will
likely change a fair bit as more APIs get filled in, and existing
high-level APIs in libsignal-net may get moved here (specifically
keytrans and registration).
libsignal-cli-utils is a common place to put helpers for our example
binaries; it's not (at this time) meant for the bridge libraries we
ship as our main products.
`scramble` replaces the most obvious identifying information in an backup.
The backup will still be identifiable in practice (e.g. from its
timestamps), but all text, names, ACIs, etc will be scrambled. The
input can be encrypted or unencrypted; the output (on stdout) is
unencrypted binproto.
This allows decrypt_backup and encrypt_backup to use the full set of
options for specifying key material as the main validator CLI, though
they will continue to use a fallback AEP and ACI if no key material is
provided. The upcoming scrambler tool will likewise use the same
options for decrypting.
This tracks whether we are using the old "master key" rules for
derived keys, or the new "account entropy pool" ones. Clients of
BackupKey have been audited:
- MessageBackupKey supports both sets of rules for now.
- The message-backup tests continue to use the old keys for now,
because they share their encrypted test case with the app
language tests.
- The CLI validator and the encrypt_backup and decrypt_backup tools
support both the old and new rules; however, the "default key" for
the encryption tools now uses the new rules.
- zkgroup's BackupAuthCredentialRequestContext supports both sets of
rules.
- All bridge functions continue to use the old keys for now.
...formerly "signal-pin", leaving MessageBackupKey in
libsignal-message-backup.
BackupKey and BackupId are more general parts of the backup system,
and don't just apply to the message backup files. More concretely,
this allows removing the redundant implementation of derive_backup_id
in zkgroup (libsignal-message-backup already depends on zkgroup). The
stronger types aren't (yet) used in the bridge layer since they're not
exposed to apps.
Further changes to backup keys and backup IDs will come shortly.
Add a new crate, libsignal-message-backup-io, and move the existing code that
handles backup decryption, deframing, and protobuf deserialization there. Keep
the actual validation of the protobuf contents in the libsignal-message-backup
crate.
This allows the existing example binproto<->json binaries to be built with
local modifications to the backup.proto file without also requiring all the
validation code to be modified.
Treat the first 16 bytes of the stream as the IV for the AES block cipher. This
is incompatible with the previous scheme, where the IV was derived from the
master key.
Handle encrypted & compressed message backup files with additional padding
after the compressed contents (the padding bytes are encrypted, but not
compressed). Update the example encrypter binary to add padding by default.
Add a utility binary that compresses and encrypts backup files per the spec.
Use the encryptor binary to encrypt the unencrypted test case file and include
it as an additional golden test. Check that, in addition to calling via the
library, the binary also accepts valid test files.
