We've discussed the "multidevice" case where users want to send / receive messages from their (phone + tablet + laptop etc). Users might also want new devices to be able to read old messages stored at the provider.
One approach is to share an "identity" key pair across devices. But some systems might not want to do this, or might have forward-secrecy mechanisms so the identity private key can't decrypt all messages. So here's another approach, which I'll explain by analogy to the Tahoe distributed filesystem [1]: In Tahoe clients can exchange "read capabilities" or "read-caps" which grant access to a file stored elsewhere. A read-cap contains a symmetric encryption key for an encrypted file and a secure hash of its ciphertext, so it has all the data needed to retrieve and decrypt an authentic copy of the file. Read-caps could be stored inside files, creating "directories" - given the read-cap for the directory you could fetch/decrypt it, then fetch/decrypt its subfiles which might be other directories, etc. Now imagine a client receiving secure messages (texts/emails/whatever). Each message will already be encrypted and stored at the provider, so the client only has to hash it to construct a "read-cap". During provisioning of a new device, an old device could send: - read-cap for each old message - metadata (sender, timestamp) for each old message Given this, the new device could display a list of old messages, and fetch and decrypt their contents as requested by the user. Presumably this is more efficient than provisioning full message contents to every new device, but it could still be a lot of data. So every day your devices could upload an encrypted "day directory" containing message read-caps for the last day. And every month you could upload an encrypted "month directory" containing ~30 day read-caps for the last month, and every year upload a "year directory" containing 12 month read-caps. Now to provision a new device you just have to give it a mix of year / month / day read caps that covers the time range you want it to have access to. The new device can fetch older ciphertexts on demand if the user wants to go back and review old messages. Anyways, thoughts? Better ideas? Trevor [1] https://gnunet.org/sites/default/files/lafs.pdf _______________________________________________ Messaging mailing list [email protected] https://moderncrypto.org/mailman/listinfo/messaging
