Re: [Cfrg] Elliptic Curves - signature: shorter signatures versa batch verification (ends on August 21st)

[Göran Selander <[e-mail]>]

On 2015-08-25 13:08, "Yoav Nir" <[e-mail]> wrote:

>
>> On Aug 14, 2015, at 1:55 PM, Alexey Melnikov
>><[e-mail]> wrote:
>> 
>> Dear CFRG participants,
>> 
>> Of the various proposals, one ("hamburg", see
>><http://ed25519.cr.yp.to/cfrg/signatures.py>) takes the option of
>>shortening the final signature by using a method known as Schnorr's
>>trick, while the others do not. This means that the "hamburg" scheme
>>enjoys shorter signatures (e.g. 48 bytes instead of 64 bytes at the
>>128-bit security level). But it removes the ability of the scheme to
>>support fast batch verification of signatures. Some concerns about the
>>security implications of the approach adopted in the "hamburg" scheme
>>have also been voiced on list
>
>A little late for the party. My excuse is that I was on vacation. I’m
>also against having shortened (“Hamburg” or “2”) signatures.
>
>Regarding the IoT use cases, I realize that a signature enlarging the
>data so much that in exceeds a single packet is inconvenient. I’m
>wondering, though, what kinds or protocols are we talking about. (D)TLS
>and others all have signatures very rarely. Most packets (or records)
>don’t carry signatures - they carry tags or MACs based on relatively
>long-lived state. Is sending a signature once an hour or once a day that
>is 16 bytes longer still considered prohibitive?  Or are we talking about
>some protocol that signs every message?

One example of type of application is given in
https://tools.ietf.org/html/draft-seitz-ace-core-authz-00#section-2.2

The candidate message format for the work in ACE is developed in the COSE
WG. Key establishment is TBD - the proposed architecture contains trusted
parties that e.g. could act KDC.

Hope that helps.

Göran

>
>Yoav
>
>_______________________________________________
>Cfrg mailing list
>[e-mail]
>https://mail.ietf.org/mailman/listinfo/cfrg