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

[Yoav Nir <[e-mail]>]

> On Jun 4, 2015, at 2:31 AM, Tom Yu <[e-mail]> wrote:
> 
> 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.

There could be. But if we generate a signature scheme that works well for certificate authorities as well as common protocols such as TLS, SSH, IKE, and S/Mime, we should do that. 

If that doesn’t fit some use cases, there can be another signature scheme for them. This is kind of like #3, but I don’t think it’s required that the two schemes be linked.

Yoav