cryption capabilities

[chase-moskal]

the idea is that we can encrypt data for any public authlocal identity -- and the data can only be decrypted by that identity -- all offline, asynchronously.

this opens up some interesting use-cases

• apps can keep a serverside vault of user data, which only the client can decrypt locally
• we can make a kind of "secure drop" app, where users can establish a mailbox on a server, and other users can drop encrypted payloads for the recipient's eyes only
• we can do offline ecdh symkey derivation to open a private comms channel between two authlocal identities

add x25519 keypair

• currently, every authlocal identity includes an ed25519 signing keypair, derived from a random seed
• knowing the random identity seed, authlocal can also derive a x25519 encryption keypair
• the resulting public encryptionKey can be included with every authlocal nametag (in every claim/proof/login)
• now, apps can encrypt information for an authlocal identity, and only that authlocal id can decrypt it

new authlocal popup flows

• login — we already support this flow
  • we add the new encryptionKey on every claim/proof/login
  • maybe login gains a new helper method login.signEncryptionToken()?
• decrypt — app provides {encryptionKey, ciphertext}
  • authlocal sees which id has that encryptionKey
  • asks the user "would you like to decrypt this data for this app?"
  • sending back the decrypted payload if the user obliges
  • (note: should probably do this with fancy transferable streams, so we could efficiently decrypt massive multi-gigabyte payloads)
• loginDecrypt — combines a login with an immediate decryption in a single popup flow
• deriveSharedKey — (maybe out of scope) ecdh diffie-hellman, yielding an agreed symkey between two parties
  • app provides a foreign user's signed encryptionKey and a salt
  • authlocal asks the user "do you want to open a secure channel with this user, and give it to this app?"
  • derives and returns an agreed symkey

design concerns

• we currently have this UX where a user can click-to-copy an "authlocal id" -- but that doesn't include the encryptionKey, and we can't derive it without the identity seed -- and so we may need to consider a different UX where you can click-to-copy a larger signed data blob that includes the user's id and encryptionKey together? maybe this is a concept like a copyable "authlocal mailbox" or something?