This omits the public key of an encrypted attribute from a
presentation proof, meaning the verifying server will see that the
attribute has been "correctly" encrypted, but cannot verify which key
was used to perform that encryption.
Previously, zkcredential declared traits 'KeyPair' and 'PublicKey',
which could be implemented to provide custom encryption keys for the
homomorphic encryption used in credentials. However, those keys still
had to be consistent with the proofs generated by zkcredential, and
they ended up looking the same for every attribute type...except in
their decryption.
Now, clients like zkgroup implement a 'Domain' trait to provide the
generator points and type safety for a key, and can reuse
zkcredential's KeyPair, PublicKey, and Ciphertext types. The 'decrypt'
operation still has to be provided on a per-type basis, unfortunately.
The code size and performance impact is below the noise threshold.
This commit CHANGES THE SERDE REPRESENTATION for zkgroup KeyPairs,
including those embedded in types like GroupSecretParams.
Serializations using bincode, including Signal's, will not see any
change, but serializing using another serde implementation will result
in different structure in the KeyPair type.
On the Rust side, this expects a typical C callback function with a
"context" parameter. On the Swift side, we pass a manually-refcounted
object as that "context" which can be used to complete a
CheckedContinuation, bridging into the language 'async' functionality.
The main obstacle to this approach is that Swift does not allow C
function pointers to be used in generic ways, due to its run-time
generics model. AsyncUtils.swift describes the workarounds needed to
deal with this.
bridge_fn already supported async functions for Node, by running them
on the Node microtask queue using the work in the signal_neon_futures
crate. This PR fits that into the AsyncRuntime trait added for
bridge_io, allowing async bridge_fn and async bridge_io to share code
and the same basic structure when compiling for Node.
This will come in handy when bringing the existing Node async function
support into the AsyncRuntime model: these async operations do *not*
require Send, because they are executed synchronously with JavaScript
operations on the Node microtask queue. This differs from the
"concurrent" async we plan to use with bridge_io, which *will* require
Send on its Futures.
When archiving the current session, we log at the Info level if there
wasn't actually a session to archive. However, session handling code
elsewhere can promote an archived session back to current; doing so
implicitly archives the current session. If there was no current
session, this would still log even though the "archive" was an
implementation detail. Now, only the publicly-exposed API will log;
promotions will not.
Additionally, don't bother explicitly archiving the current session
when we receive a pre-key message; we use "promote" to install the new
session, which as discussed will archive automatically.
This will let us (a) avoid hardcoding any particular async runtime in
the libsignal-bridge macros, and (b) separate the platform-specific
stuff from the async runtime. libsignal_bridge now has an AsyncRuntime
trait whose only requirement is "run a self-contained Future".
RUSTFLAGS (correctly) goes into the incremental build hash used by
Cargo and by extension rust-analyzer, and having your IDE and build
script disagree results in a fresh build every time.
Replace the String values with Cow<'static, str> which lets us hold references
to static strings without copying them onto the heap. Since most added values
are static, this should save on heap usage and runtime cost.
For now, the "runtime" is spawning a thread that then uses
now_or_never, but eventually this will be a persistent tokio runtime
of some kind.
Also for now, this is only implemented for Java. Swift and Node
support coming soon.
This requires a bit of reorganization in SimpleArgTypeInfo, following
a similar pattern in the JNI and Node bridges, but simplifies the use
of ArgTypeInfo in general, including the generated code for
`bridge_fn`.
- Factor out common utilities
- Simplify error handling using syn::Result
- Stop using unzip to produce two collections at once
- Add more explanatory comments
- Remove features on libsignal-bridge-macros
Co-authored-by: Alex Konradi <akonradi@signal.org>
By importing past tags of libsignal-protocol, we can check how the
current implementation behaves against previous versions. This initial
test only does v3 (pre-Kyber) 1:1 sessions, but we can add more tests
in the future.
Previously this didn't compose correctly with `--duplicates` (`-d`),
but now it prunes out dependencies in proc-macros just like we already
were for non-"normal" dependencies (build and dev), allowing us to
maintain our focus on code size.
While here, prefer long forms of flags for more readable code, and
improve the comments around the dependencies we can't avoid
duplicating.
