[messaging] Giving new devices access to old messages

[David Leon Gil]

>> > 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.

The idea of storing a key of trees is not particularly novel. A
somewhat better way of doing it is to store a tree with a branching
factor of (storage_page_size / (key_size + sizeof(uintptr_t))).

Does anyone have a decent citation? (RR, perhaps?)

On Mon, Apr 20, 2015 at 6:07 PM, Gary Belvin <gdb at google.com> wrote:
> It seems to me that the challenge with this approach is authenticating the
> requests before releasing a set of symmetric keys to your data.

I very much agree. In particular, I think that
passphrase-based-authentication is a dreadful idea for this.

(So: Use a decent multi-device model instead.)

And, to reiterate a point which I have made previously: It is
extremely important to ensure that stored messages cannot be
correlated with the messages sent on the wire between sender and
recipient. This requires that messages be re-encrypted for storage.

> It's another attack surface.  It also change the semantics of "only the person
> with the private key can read the message".  Thoughts?

"Only the person with the private key can read the message" implies
transferring (relatively) long-term private encryption keys between
devices. This is far, far worse than transferring even PFS ephemeral
keys.

> On Sun, Apr 19, 2015 at 10:37 AM, Trevor Perrin <trevp at trevp.net> wrote:
>> 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.

This threat model would make sense if a provider

(1) allowed users to rewrite stored messages at arbitrary times,
(2) but did not allow them to rewrite the hashes.

Is there some reason that this would be a useful service to provide?
The only particularly good reason to rewrite stored messages is to
re-encrypt them under a new key. But if you can't change the "secure
hash", you still need the old "secure hash" key.

--

(Or, you could just do an (N?)IZKP that the message is a re-encryption
of the same plaintext under a different encryption key, and that the
"secure hash" is a MAC of the same plaintext under a different MAC
key...)