Page MenuHomePhabricator

[web] Introduce `cryptoStore` to replace `primaryIdentityPublicKey` in Redux
ClosedPublic

Authored by atul on Feb 23 2023, 2:15 PM.
Tags
None
Referenced Files
F3364508: D6877.diff
Mon, Nov 25, 4:06 AM
Unknown Object (File)
Fri, Nov 22, 6:03 AM
Unknown Object (File)
Mon, Nov 18, 1:14 PM
Unknown Object (File)
Sun, Nov 10, 7:02 PM
Unknown Object (File)
Sun, Nov 10, 7:02 PM
Unknown Object (File)
Sun, Nov 10, 6:59 PM
Unknown Object (File)
Tue, Nov 5, 2:09 AM
Unknown Object (File)
Oct 19 2024, 10:23 AM
Subscribers

Details

Summary

Migrate from having primaryIdentityPublicKey in Redux to having the more flexible cryptoStore which will have both our primary identity keys AND notification identity keys.

Only the primaryIdentityPublicKey is being passed to the keyserver in the login/siwe_auth/register requests... so no behavior should change and this is effectively a "noop."


Depends on D6876

Test Plan

Migration succeeded:

6f4367.png (2×3 px, 692 KB)

4ed18d.png (2×3 px, 596 KB)

6a6db5.png (2×3 px, 505 KB)

primaryIdentityPublicKey is set correctly in the database:

aa8eb7.png (232×3 px, 90 KB)

Diff Detail

Repository
rCOMM Comm
Lint
Lint Not Applicable
Unit
Tests Not Applicable

Event Timeline

atul published this revision for review.Feb 23 2023, 2:16 PM
atul edited the test plan for this revision. (Show Details)
atul added inline comments.
web/root.js
42 ↗(On Diff #23040)

Not going to persist cryptoStore just yet.

ashoat added a subscriber: kamil.

EDIT – never mind, I see this is addressed later in the stack

What happens to the private keys? Figure that should be persisted somehow, but maybe it's handled later in the stack. If it isn't, can you create a task (or diff) and link here before landing?

I think it's pretty important that we make sure we don't lose the private keys... storing the public keys on the keyserver for notifs won't be useful if the clients aren't able to decrypt the notifs as they come in.

In terms of how to store the keys on the web:

  1. Ideal solution: SubtleCrypto with a non-extractable encryption key. We would encrypt the "pickled" result from Olm with the non-extractable encryption key (AES-256, not sure what mode), and then we could store that encrypted blob somewhere like IndexedDB.
  2. What we should probably do now: @kamil is working on an encrypted SQLite store and this will probably just go there. So instead of spinning our own solution now, we could probably just store in redux-persist for now.
This revision is now accepted and ready to land.Feb 24 2023, 8:14 AM

So instead of spinning our own solution now, we could probably just store in redux-persist for now.

Yup, this is what I ended up doing