[messaging] Giving new devices access to old messages

[Gary Belvin]

It seems to me that the challenge with this approach is authenticating the
requests before releasing a set of symmetric keys to your data.  It's
another attack surface.  It also change the semantics of "only the person
with the private key can read the message".  Thoughts?

On Sun, Apr 19, 2015 at 10:37 AM, Trevor Perrin <trevp at trevp.net> wrote:

> 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
> _______________________________________________
> Messaging mailing list
> Messaging at moderncrypto.org
> https://moderncrypto.org/mailman/listinfo/messaging
>



-- 
Gary Belvin | Software Engineer | gdb at google.com | Security Team
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://moderncrypto.org/mail-archive/messaging/attachments/20150420/1f4aaa51/attachment.html>