<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Mar 3, 2016 at 3:16 PM, Yawning Angel <span dir="ltr"><<a href="mailto:yawning@schwanenlied.me" target="_blank">yawning@schwanenlied.me</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 Thu, 3 Mar 2016 16:33:42 +0000 (UTC)<br>
lukep <<a href="mailto:lukep@tutanota.com">lukep@tutanota.com</a>> wrote:<br>
> Hi,<br>
> I'm trying to understand the hybrid protocol that's described here.<br>
> The server generates the parallel secret PAR_SEC or P and then<br>
> computes C  = ENCRYPT( P | B | Y, QSPK);<br>
> The client decrypts C to get P and then uses it combination with the<br>
> ECC secret E: secret_input = E | P | QSPK | ID | PROTOID<br>
><br>
> So E is secret, P is generated by the server, QSPK ID and PROTOID are<br>
> all public. So IF ECC is broken and IF the server has been<br>
> compromised (big IF's!) then everything is known.<br>
<br>
</span>If the server is compromised, the client loses regardless of handshake<br>
mechanism because said compromised server has access to the plaintext.<br></blockquote><div><br></div><div>Also: if the client has a bad RNG, the client loses whether the material it contributes to the eventual secret is secret or public. </div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
> I guess my point is that the client isnt contributing any secret<br>
> information to the quantum-safe part of KEY_SEED. Is that OK?<br>
<br>
</span>Yes.  I'd rather both sides contribute, but since `P | B | Y` is<br>
transmitted encrypted to a ephemeral key generated by the client,<br>
baring the "the server is compromised" case (which is irrelevant)<br>
the construct should hold.<br>
<br>
See RFC 4432, RFC 5246 7.4.7.1 for this sort of thing being done with<br>
RSA.<br>
<br>
Note: The Ring-LWE variant of this hybrid construct would fulfill the<br>
"both sides contribute material" clause (yay).<br></blockquote><div><br></div><div>Just to be careful here, both sides do contribute material (because the QS ciphertext, which is derived from P, is hashed into secret_input). The difference is that the client doesn't contribute *secret* material. However, it's hard to come up with an attack model in which this actually matters, even though there are obviously more warm fuzzies if the secret material comes from both sides.</div><div><br></div><div>Cheers,</div><div><br></div><div>William</div><div><br></div><div><br></div><div> </div></div></div></div>