Re: [Secdispatch] Preliminary agenda online

[Rene Struik <[e-mail]>]

Dear colleagues:

At the end of my presentation yesterday, Ben Kaduk asked about batch 
ECDSA verification speed-ups with single signer and with multiple 
signers. The suggested speed-ups in the draft [1] are ~1.3x for single 
verification and up to ~6x for batch verification. If all signatures 
have been produced by different signers, one can achieve a speed-up of 
~2.5x (still respectable). Usual caveats that these are ballpark figures 
(which depend on, e.g., relative cost of field multiplication and adds) 
apply. Ballparks above are for NIST curves with Jacobian addition rules.

As already indicated in the email below (July 21st), the draft does not 
contain new crypto and only uses a public and reversible (r,s) to (r,-s) 
signature transformation, if need be. This should therefore allow for a 
very quick start-to-finish project, where enabling this simply depends 
on defining code points or another unique cross-reference and getting 
this out of the door.

Best regards, Rene

Ref: [1] draft-struik-secdispatch-verify-friendly-ecdsa-00


On 2021-07-21 11:15 a.m., Rene Struik wrote:
> Hi Mohit:
>
> I would like to discuss 
> https://datatracker.ietf.org/doc/draft-struik-secdispatch-verify-friendly-ecdsa/ 
>
>
> This draft discusses representation of ECDSA signatures that allow 
> fast single verification and batch verification and which is 
> consistent with ordinary ECDSA signatures for prime-order curves (such 
> as with NIST prime curves, Brainpool curves, secp256k1). To enable 
> verifiers to reap these benefits one simply needs a flag (code point, 
> #) to indicate ECDSA signatures have been put into this 
> verification-friendly format. The representation change can be made by 
> any device, not just the signer, and can thereby be made retroactively 
> (without need for new signature).
>
> This draft does not deal with new crypto, only whipped-up 
> representations: it simply uses the well-known fact that if (r,s) is a 
> valid ECDSA signature, then so is (r,-s), to effectuate this switch 
> under certain conditions.
>
> Batch verification speed-ups (up to ~6x) have been known since the 
> 90s; single verification speed-ups (~1.3-1.4x) for at least 16 1/2 years.
>
> Intention is that IETF could (perhaps: should) use this across the 
> board, so as to reap benefits for verification devices that wish to do 
> so (one can still use slower techniques if one does not wish to 
> change). To realize this, one simply needs a brief description and 
> registration of flags to indicate this. {In other words, this could be 
> a very short project to get to wide-scale use. The current draft 
> contains most info already.}
>
> History with IETF: I discussed this with lamps at IETF-110 [1], but 
> despite positive feedback (from, e.g., Scott Fluhrer) lamps did not 
> include this with their recent re-charter yet. The simple technique is 
> broader than just lamps, though, and should be beneficial for any 
> deployment (certificate transparency, openpgp, pkix, etc.). This being 
> said, perhaps lamps would be a good starting point.
>
> Best regards, Rene
>
> Ref: [1] 
> https://datatracker.ietf.org/meeting/110/materials/slides-110-lamps-verification-friendly-ecdsa-00 
>
> [2] 
> https://datatracker.ietf.org/meeting/110/materials/minutes-110-lamps-01.pdf
>
>
> On 2021-07-15 5:57 a.m., Mohit Sethi M wrote:
>> Dear all,
>>
>> The preliminary agenda for Secdispatch @ IETF 111 is available online:
>> https://datatracker.ietf.org/meeting/111/materials/agenda-111-secdispatch 
>>
>>
>> Let us know if you notice any discrepancies.
>>
>> @presenters/authors: please send your slides to
>> [e-mail] early enough.
>>
>> Kathleen, Richard, and Mohit
>>
>> _______________________________________________
>> Secdispatch mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/secdispatch
>
>

-- 
email: [e-mail] | Skype: rstruik
cell: [phone] | US: [phone]