On Tue, Apr 21, 2015 at 4:18 AM, Trevor Perrin <[email protected]> wrote:

> On Mon, Apr 20, 2015 at 6:07 PM, Gary Belvin <[email protected]> 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.
>
> This could leverage existing mechanisms.  E.g. if multidevice support
> requires copying the long-term private key from old device -> new
> device, the "read-caps" could be sent along with the private key.
>
> If new devices are being provisioned with a passphrase and
> server-stored data, then whenever an old device downloads and decrypts
> some messages, it could upload passphrase-encrypted read-caps.
>

Arguably, there would be a slightly more concentrated attack surface on the
server storing all this data, since it collects a large number of
"read-caps" under a single passphrase. Would this not affect forward/future
secrecy claims?

Although, the usage of a passphrase *would* elegantly resolve
authentication matters. Overall, I like where Trevor is going with this. :-)

Nadim


>
> > It also change the semantics of "only the person
> > with the private key can read the message".
>
> I'd put it differently: This is just the old device giving messages to
> the new device.  We're trying to make it more efficient, but this was
> always possible.
>
> I would like to deprecate the semantics "any person with your
> long-term private key can decrypt all messages you've received".  If
> the long-term keys used for authentication are separated from the
> per-message keys used for sharing data, I would hope that also enables
> using more granular keys for forward-secure encryption.
>
> Trevor
> _______________________________________________
> Messaging mailing list
> [email protected]
> https://moderncrypto.org/mailman/listinfo/messaging
>
_______________________________________________
Messaging mailing list
[email protected]
https://moderncrypto.org/mailman/listinfo/messaging

Reply via email to