[messaging] Giving new devices access to old messages

[Trevor Perrin]

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