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

[Nico Williams <[e-mail]>]

On Thu, May 21, 2015 at 12:22:55PM +0000, Peter Gutmann wrote:
> Alexey Melnikov <[e-mail]> writes:
> >However, this approach implies that the signing algorithm would have to
> >buffer the entire message. That could lead to unacceptable memory usage for
> >applications that sign very large messages.
> 
> It's also pretty much an instant fail for any API-based security toolkit that
> implements streaming/staged message processing via the init/update/final
> model, which seems to be pretty much all of them (using PKCS #11 as a
> representative example, you've got "begin", "update", "update", [...], "end",
> which hardcodes a single pass over the data, OpenSSL does the same thing, as
> does CryptoAPI, Java (JCE/Bouncy Castle/whatever), my own cryptlib, and I'd
> guess most other libraries).

I hate to agree with this, but this is just too common an API pattern.
The assumption of online signing is quite pervasive; an off-line-only
signature scheme might have a hard time getting traction.

> >#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.
> 
> +1.  Without having done a survey of all implementers, I do however get the
> feeling that this is the only option available for practical use, meaning the
> choice would be to either go with this option or have whatever other option
> you select ignored because it's impractical for general use.

#3 wouldn't hurt.  From an API perspective #3 is best seen as *two*
signature schemes (with different OIDs), one of which is incompatible
with online signature APIs.

I'd certainly like to have both.  Protocols like TLS and PKIX should use
the off-line signature scheme when the implementor can manage it, as it
would be the preferred scheme.  Pretty much all apps using existing
crypto frameworks (generic APIs parametrized by algorithm ID) would get
the online version.

Nico
--