[messaging] Giving new devices access to old messages

[Trevor Perrin]

On Sat, Apr 18, 2015 at 6:50 PM, Matthew Hodgson <matthew at matrix.org> wrote:
> On 19/04/2015 01:22, Trevor Perrin wrote:
[...]
>>  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.
>
>
> How does this differ from caching per-message PFS keys on the receiving
> device, and sharing them with the new device when migrating?

Couple ways:

 * The "read-cap" contains a secure hash of ciphertext, it's not just
a decryption key.  If you only share message-decryption keys then the
messages seen by the new device could be maliciously altered if those
keys leak.

Example:  Alice sends you a message, you later share the
message-decryption key to a new device.  But spyware on Alice's
machine was stealing her keys!  Your service provider could use the
stolen message key to rewrite Alice's message.  This is prevented if
you give the new device a secure hash of the message alongside the
key.

(As a sidenote: you could reuse the message's MAC as the "secure hash"
in some cases, e.g. HMAC would work, GCM wouldn't.  That would avoid
having to calculate an extra hash.)


 * I mentioned nesting the message read-caps into encrypted
"directories" for days / weeks / years etc.  So you can provision the
new device with a read-cap for "year 2014" instead of a read-cap plus
metadata for every message in 2014, and the new device can fetch /
decrypt / authenticate those messages if it wants.

This is just an optimization, we could argue if it's necessary.  But
sync'ing individual key+hash+metadata for each message could add up.
E.g. 50 bytes/message at 10 years of 100 messages/day ~= 20 MB.

You suggested reducing the volume of provisioning data by a "coarser
PFS granularity", but then you're weakening security.

Trevor