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

On Thu, May 21, 2015 at 4:14 PM, Nico Williams <nico@cryptonector.com> wrote:
> On Thu, May 21, 2015 at 12:22:55PM +0000, Peter Gutmann wrote:
>> Alexey Melnikov <alexey.melnikov@isode.com> 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.

On the contrary, 3 would hurt unless properly designed. The danger is
that the same key could produce a valid signature under two different
algorithms, thus leading to potential exploitation. We would need to
ensure there are no collisions in what is fed into the signing
algorithm.

It seems as though determinism, one pass schemes, and avoiding
collision resistance are at odds, unfortunately, unless someone comes
up with a good idea.

Sincerely,
Watson Ladd

>
> Nico
> --
>
> _______________________________________________
> Cfrg mailing list
> Cfrg@irtf.org
> http://www.irtf.org/mailman/listinfo/cfrg

-- 
"Man is born free, but everywhere he is in chains".
--Rousseau.