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

[Tony Arcieri <[e-mail]>]

On Wed, May 20, 2015 at 2:16 PM, Alexey Melnikov <[e-mail]>
wrote:

> #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.


I'll restate my vote again for clarity:

I vote for both #2 with #1 as a fallback, with the caveat is that I think
#1 is of waning usefulness. I'm sure some will cite the IoT use case, but I
think the constant-space requirement will generally go away as technology
improves.

For the TLS use case, I think both can be supported:

- TLS servers obtain certificates that use both algorithms, or servers that
don't care about supporting "tiny" clients can forego #1. I am guessing #2
is sufficient for most use cases
- "Tiny" clients can specify in their ClientHello that they only support
#1, and servers can respond with a cert signed using #1. These clients
forego collision resistance

I think most devices that "matter" (sorry if I'm being too judgmental here)
should be capable of #2

-- 
Tony Arcieri