<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Oct 8, 2014 at 5:03 PM, Ben Laurie <span dir="ltr"><<a href="mailto:benl@google.com" target="_blank"><span tabindex="-1" id=":8eo.1" style="background:none repeat scroll 0% 0% yellow" class="">benl</span>@google.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br><br><div class="gmail_quote"><span class="">On Tue Oct 07 2014 at 10:51:21 PM Hanno Böck <<a href="mailto:hanno@hboeck.de" target="_blank">hanno@hboeck.de</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">I like it that the whole area of post-quantum-crypto is getting more<br>
attention lately.<br>
<br>
However what immediately catched my attention: The webpage says<br>
"Signatures are 41 KB, public keys are 1 KB, and private keys are 1 KB"<br>
<br>
The signature size is a problem. It makes the claim that it's a<br>
"drop-in replacement" for current signature schemes somewhat<br>
questionable.<br>
<br>
41 kb may not seem much, but consider a normal TLS handshake. It<br>
usually already contains three signatures (2 for the certificate chain<br>
and one for the handshake itself). That already makes 120 kb.<br>
<br>
It may not seem that much, but it definitely is an obstacle because this<br>
would significantly impact your loading time.<br></blockquote><div><br></div></span><div>Definitely a deal breaker for HTTPS.</div><div><br></div></div>
<br></blockquote><div><br></div><div><span tabindex="-1" id=":8eo.2" style="background:none repeat scroll 0% 0% yellow" class="">TLS</span> can re-use sessions, and re-use cached information, so this overhead can be negligible.  Large signatures will just adjust the trade-off, favoring session re-use and caching. Even without session-reuse, 2 of the certificate chain hashes described above can be cached indefinitely on the client, which means the number of <span tabindex="-1" id=":8eo.3" style="background:none repeat scroll 0% 0% yellow" class="">DNS</span> requests is an absolute upper bound on this traffic.<br><br>For example <a href="https://tools.ietf.org/html/draft-ietf-tls-cached-info-16">https://tools.ietf.org/html/draft-ietf-tls-cached-info-16</a> could be used.<br><br></div><div>Btw, the same approach makes sense for the transfer of the SCT in your CT design.<br><br>Further, for HTTP/2.0 the web will get longer sessions, so handshake overhead should means less.<br><br></div><div>Re-sending static information in the TLS handshake is inefficient and makes no sense, and designing with that as a fundamental limit to the design space is simply not necessary.<br></div><br><div>Having a signature scheme that is hard to implement incorrectly and that is quantum-computer secure seems like an obvious win.<br><br></div><div>Alexander<br></div></div></div></div>