encrypted-chat  Timeline

This seems preferable to bincode for cryptographic applications (and
potentially for speed?), as well as being available in Dart, making it a
reasonable choice for the Rust/Flutter FFI. check-in: af6e2f0ac2 user: wesleyac tags: borsh

This is unmodified, for easy diffing later if needed. check-in: a9e1fa97c9 user: wesleyac tags: flutter-testing

Committing this as-is so I can diff against it if needed. Closed-Leaf check-in: 532c710ea8 user: wesleyac tags: flutter-testing

This is good for testing and figuring out what a good API for lib::client is. check-in: 7254b55bd0 user: wesleyac tags: trunk

This is basically the exact same thing and isn't buying us security or
anything, but it feels nicer to do this more explicitly. check-in: ca37fddac1 user: wesleyac tags: trunk

This should make it easier to review just the important impls, while skimming the rest. check-in: 0595475c17 user: wesleyac tags: trunk

These let us avoid confusion between the device and identity keys. check-in: f4b2ee30c8 user: wesleyac tags: trunk

I'm not super confident in this, and it needs a lot of cleanup and making all
the types nicer. But it's a start. check-in: e2090134fd user: wesleyac tags: trunk

I'm waffling on whether we need this or not. On the one hand, it could probably
help avoid some attacks, on the other hand, I need to actually specify what it
means and how the client has to handle it. Probably something to come back to
later. check-in: fa24183916 user: wesleyac tags: trunk

This is more correct, as the same double ratchet session can go over multiple different transports. check-in: 4cfc62817d user: wesleyac tags: trunk

We have this in the signed_identity_bundle now. check-in: 1deb0d95fd user: wesleyac tags: trunk

This isn't really a win since we've just pushed these all into the lib binary,
but it's nice to know we have a better abstraction, I guess. check-in: ce2360a6c9 user: wesleyac tags: trunk

In a multidevice world, what we used to call a "identity key" is now a "device key" check-in: a4ce61df0f user: wesleyac tags: trunk

This name isn't exactly right, as it contains the X3DH code as well, but those
are somewhat tightly integrated anyways. check-in: 329a5ae22a user: wesleyac tags: trunk

Since we already have the top-level code directory, this is not really helpful
and just adds noise. check-in: a4df73eb81 user: wesleyac tags: trunk

This constant allows us to switch curves or representations later if we would like. check-in: c1335ac90b user: wesleyac tags: trunk

This seems to make the code clearer. check-in: cefeadbab1 user: wesleyac tags: trunk

No sense in differentiating these while things are still so in flux, and maybe ever. check-in: 62f81dd96d user: wesleyac tags: trunk

I'm not convinced that a separation between types used over the wire and
internally is useful at this point. If it becomes useful later we can bring it
back. In the next commit, the lib::crypto::types will be pulled into this
module. check-in: 36a16e4311 user: wesleyac tags: trunk

It will be shared between all of the code, not just the X3DH/double ratchet. check-in: 03ea096214 user: wesleyac tags: trunk

This allows us to receive duplicate messages without panicing. check-in: 94a12e8c74 user: wesleyac tags: trunk

This is in a semi-working state (lots of things still broken, but more working
than it was before I started work on multidevice). Needs a huge amount of code
cleanup, error handling, and transaction handling code.

This also adds some docs and things that I've been noodling on while I was
working on this. check-in: 00769b39df user: wesleyac tags: trunk

We will in the future have a higher-level identity key, but what we've
currently been calling a "Identity Key" we'll now call a "Device Key". check-in: 90796f4138 user: wesleyac tags: trunk

This code is very messy right now. It will get cleaned up soon :) check-in: e2c37874ac user: wesleyac tags: trunk

This implements header encryption as described in the Double Rachet Protocol
paper. It currently uses static (insecure!) header encryption keys, but in the
future I intend to derive these keys from the X3DH shared secret. check-in: ba398229ae user: wesleyac tags: trunk

I believe that the AES-256-CBC + HMAC construction isn't easily suitable for
implementing the header encryption variation of the protocol, so I plan to move
to AES-GCM-SIV first. Leaf check-in: 1ce23ac30b user: wesleyac tags: start-header-encryption

public keys in the AD are only used to prevent a identity binding attack, which
is irrelevant after the key negotiation is complete. check-in: 12ff92110b user: wesleyac tags: trunk

This makes error handling significantly easier. check-in: 25fd474774 user: wesleyac tags: trunk