[messaging] Giving new devices access to old messages
David Leon Gil
coruus at gmail.com
Mon May 11 01:12:53 PDT 2015
>> > 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
> 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
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
More information about the Messaging