<div dir="ltr">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?</div><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Apr 19, 2015 at 10:37 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 Sat, Apr 18, 2015 at 6:50 PM, Matthew Hodgson <<a href="mailto:matthew@matrix.org">matthew@matrix.org</a>> wrote:<br>
> On 19/04/2015 01:22, Trevor Perrin wrote:<br>
</span>[...]<br>
<span class="">>>  A read-cap contains a symmetric encryption key for an<br>
>> encrypted file and a secure hash of its ciphertext, so it has all the<br>
>> data needed to retrieve and decrypt an authentic copy of the file.<br>
><br>
><br>
> How does this differ from caching per-message PFS keys on the receiving<br>
> device, and sharing them with the new device when migrating?<br>
<br>
</span>Couple ways:<br>
<br>
 * The "read-cap" contains a secure hash of ciphertext, it's not just<br>
a decryption key.  If you only share message-decryption keys then the<br>
messages seen by the new device could be maliciously altered if those<br>
keys leak.<br>
<br>
Example:  Alice sends you a message, you later share the<br>
message-decryption key to a new device.  But spyware on Alice's<br>
machine was stealing her keys!  Your service provider could use the<br>
stolen message key to rewrite Alice's message.  This is prevented if<br>
you give the new device a secure hash of the message alongside the<br>
key.<br>
<br>
(As a sidenote: you could reuse the message's MAC as the "secure hash"<br>
in some cases, e.g. HMAC would work, GCM wouldn't.  That would avoid<br>
having to calculate an extra hash.)<br>
<br>
<br>
 * I mentioned nesting the message read-caps into encrypted<br>
"directories" for days / weeks / years etc.  So you can provision the<br>
new device with a read-cap for "year 2014" instead of a read-cap plus<br>
metadata for every message in 2014, and the new device can fetch /<br>
decrypt / authenticate those messages if it wants.<br>
<br>
This is just an optimization, we could argue if it's necessary.  But<br>
sync'ing individual key+hash+metadata for each message could add up.<br>
E.g. 50 bytes/message at 10 years of 100 messages/day ~= 20 MB.<br>
<br>
You suggested reducing the volume of provisioning data by a "coarser<br>
PFS granularity", but then you're weakening security.<br>
<span class="HOEnZb"><font color="#888888"><br>
Trevor<br>
</font></span><div class="HOEnZb"><div class="h5">_______________________________________________<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><br clear="all"><div><br></div>-- <br><div class="gmail_signature"><div dir="ltr"><span style="font-size:small;color:rgb(85,85,85);font-family:sans-serif;line-height:19.5px;border-width:2px 0px 0px;border-style:solid;border-color:rgb(213,15,37);padding-top:2px;margin-top:2px">Gary Belvin |</span><span style="font-size:small;color:rgb(85,85,85);font-family:sans-serif;line-height:19.5px;border-width:2px 0px 0px;border-style:solid;border-color:rgb(51,105,232);padding-top:2px;margin-top:2px"> Software Engineer |</span><span style="font-size:small;color:rgb(85,85,85);font-family:sans-serif;line-height:19.5px;border-width:2px 0px 0px;border-style:solid;border-color:rgb(0,153,57);padding-top:2px;margin-top:2px"> <a href="mailto:gdb@google.com" target="_blank">gdb@google.com</a> |</span><span style="font-size:small;color:rgb(85,85,85);font-family:sans-serif;line-height:19.5px;border-width:2px 0px 0px;border-style:solid;border-color:rgb(238,178,17);padding-top:2px;margin-top:2px"> Security Team</span><br></div></div>
</div>