[Cryptography] SPHINCS: practical hash-based digital signatures

Alexander Kjeldaas alexander.kjeldaas at gmail.com
Mon Oct 27 07:51:06 EDT 2014


On Wed, Oct 8, 2014 at 5:03 PM, Ben Laurie <benl at google.com> wrote:

>
>
> On Tue Oct 07 2014 at 10:51:21 PM Hanno Böck <hanno at hboeck.de> wrote:
>
>> I like it that the whole area of post-quantum-crypto is getting more
>> attention lately.
>>
>> However what immediately catched my attention: The webpage says
>> "Signatures are 41 KB, public keys are 1 KB, and private keys are 1 KB"
>>
>> The signature size is a problem. It makes the claim that it's a
>> "drop-in replacement" for current signature schemes somewhat
>> questionable.
>>
>> 41 kb may not seem much, but consider a normal TLS handshake. It
>> usually already contains three signatures (2 for the certificate chain
>> and one for the handshake itself). That already makes 120 kb.
>>
>> It may not seem that much, but it definitely is an obstacle because this
>> would significantly impact your loading time.
>>
>
> Definitely a deal breaker for HTTPS.
>
>
>
TLS 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 DNS requests is an absolute upper bound
on this traffic.

For example https://tools.ietf.org/html/draft-ietf-tls-cached-info-16 could
be used.

Btw, the same approach makes sense for the transfer of the SCT in your CT
design.

Further, for HTTP/2.0 the web will get longer sessions, so handshake
overhead should means less.

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.

Having a signature scheme that is hard to implement incorrectly and that is
quantum-computer secure seems like an obvious win.

Alexander
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20141027/ad9e3bef/attachment.html>


More information about the cryptography mailing list