<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, Apr 21, 2015 at 4:18 AM, Trevor Perrin <span dir="ltr"><<a href="mailto:trevp@trevp.net" target="_blank">trevp@trevp.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Mon, Apr 20, 2015 at 6:07 PM, Gary Belvin <<a href="mailto:gdb@google.com">gdb@google.com</a>> wrote:<br>
> It seems to me that the challenge with this approach is authenticating the<br>
> requests before releasing a set of symmetric keys to your data.<br>
<br>
</span>This could leverage existing mechanisms.  E.g. if multidevice support<br>
requires copying the long-term private key from old device -> new<br>
device, the "read-caps" could be sent along with the private key.<br>
<br>
If new devices are being provisioned with a passphrase and<br>
server-stored data, then whenever an old device downloads and decrypts<br>
some messages, it could upload passphrase-encrypted read-caps.<br></blockquote><div><br></div><div>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?</div><div><br></div><div>Although, the usage of a passphrase *would* elegantly resolve authentication matters. Overall, I like where Trevor is going with this. :-)</div><div><br></div><div>Nadim </div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class=""><br>
<br>
> It also change the semantics of "only the person<br>
> with the private key can read the message".<br>
<br>
</span>I'd put it differently: This is just the old device giving messages to<br>
the new device.  We're trying to make it more efficient, but this was<br>
always possible.<br>
<br>
I would like to deprecate the semantics "any person with your<br>
long-term private key can decrypt all messages you've received".  If<br>
the long-term keys used for authentication are separated from the<br>
per-message keys used for sharing data, I would hope that also enables<br>
using more granular keys for forward-secure encryption.<br>
<div class="HOEnZb"><div class="h5"><br>
Trevor<br>
_______________________________________________<br>
Messaging mailing list<br>
<a href="mailto:Messaging@moderncrypto.org">Messaging@moderncrypto.org</a><br>
<a href="https://moderncrypto.org/mailman/listinfo/messaging" target="_blank">https://moderncrypto.org/mailman/listinfo/messaging</a><br>
</div></div></blockquote></div><br></div></div>