Re: [Cfrg] Elliptic Curves - signature scheme: friendliness to low memory implementations (ends on June 3rd)

[Tom Yu <[e-mail]>]

Alexey Melnikov <[e-mail]> writes:

> Penalising large messages might be seen as a positive by some because
> signing arbitrarily large messages invites implementations to process
> unauthenticated data because of its potential size. Also, designs that
> really wish to do this can always define that the message to be signed is
> actually a hash of the data. In doing so they would reintroduce the
> requirement that the hash function be collision resistant, but can
> implement an IUF API in constant space again.

Based on some conversations with people who deal with crypto in high
performance applications, there are use cases for which minimizing
copying and optimizing cache usage can bring significant improvements.
Making multiple passes over messages could cause cache bottlenecks even
on systems that have large amounts of memory.  This was mosty in the
context of symmetric crypto, but I imagine that there are probably
signing scenarios where this is the case.

> On the other hand, if we wish a signature primitive to be easy to
> substitute into existing protocols then supporting a constant-space IUF
> API might be seen as a requirement.
>
> Chairs wish to poll the group on the following topic (please pick one):

No strong opinion, but leaning toward #1 or #3.

> #1: The signature scheme should follow the traditional model of hashing
> the message to be signed, thus trivially supporting IUF APIs in
> constant-space, at the cost of requiring collision resistant hash
> functions.
>
> #2: The signature scheme should not depend on collision resistance, at the
> cost of the signing algorithm having to buffer messages to be signed.
>
> #3: option #2, but with an additional "large message" mode defined for
> protocols that feel that they need it, where the message to be signed is
> actually a hash of the true message.