- Java: on IdentityKeyPair and IdentityKey, respectively
- Swift: on IdentityKeyPair and IdentityKey, respectively
- Node: on IdentityKeyPair and PublicKey; Node doesn't have a separate
IdentityKey API
For convenience, exposes IdentityKeyPair.generate() in Java and Node
as well. (This API already existed in Swift.)
This marks that a session is being opened by Alice to reply to Bob,
who has sent a message to Alice's phone number rather than her account
UUID. Apps can check this flag to determine if they need to include
extra information in the message content to certify that yes, this
account is the owner of this phone number. The state is automatically
cleared once the current session receives a response from Bob.
And straighten out InvalidState (a precondition the caller failed to
enforce) vs. InternalError (something went wrong that the caller
couldn't have checked for).
This makes it clear that the only way to get invalid MessageKeys is to
have a corrupted session, which in turn means we can remove the
InvalidCipherCryptographicParameters error case.
Separating encryption and decryption errors makes it clearer what can
fail in what ways; using a dedicated error type forces callers within
the crate to decide how to report the error to external clients. The
next commit will remove the now-unused error case here.
Enforce that directly-created keys have the right length, which pushes
the error to the lazy deserialization code in a session. If the
lengths are wrong there, the session is corrupt.
Fingerprint checks are done with a boolean-returning method; the error
is never thrown. Android and iOS aren't using the exception / error
case either.
node-gyp-build should make sure that we don't build the Rust library
*again*, but if we do by accident, the tests should still run against
what we're going to submit, which is what's in the prebuilds/
directory.
The academic paper zkgroup is based on uses one-based indexes for 'y'
values, which is reflected in the poksho proof elements. Add a
OneBased wrapper so that these values can be used as an aggregate
but indexed in a way that matches the proofs.
It doesn't actually *do* that yet (next commit), but at least now
there isn't a hardcoded y1, y2, y3, y4 when we might want to use more
(or fewer!) attributes in a credential KeyPair.
