Re: [Secdispatch] Preliminary agenda online

Rene Struik <> Wed, 21 July 2021 15:16 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id EF2843A1B73 for <>; Wed, 21 Jul 2021 08:16:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id SWytIi9mM9v1 for <>; Wed, 21 Jul 2021 08:16:00 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::f32]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id B1BC23A1B7F for <>; Wed, 21 Jul 2021 08:15:57 -0700 (PDT)
Received: by with SMTP id a10so1079888qvj.11 for <>; Wed, 21 Jul 2021 08:15:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=to:references:from:subject:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding:content-language; bh=tFRH0wohT+Zx3XC7IgSuI3UjZ3/AVKNkgOptlYp/7Ro=; b=ppBnWo/fbshAw4iJLTP6uCbgueg8SKyfVndMbddIr6FEez5r2mYmjNFw+CEzD2awfp iQIC8y09VIUNLcCufosVL86Fg4TERSLpwR1j5RQEa4RmnbFDLl2DinNgW/vrzrfazyOw Tu3D8WA3RMNe6J96qx6hvV6v8KDhCYJPaQsrRriIpx9kvo5bQ4lJSVsen5MWlNtoAWGu SXXOmZtV70dTrhFuFm1RTXMmnadzYPvmkI/QsKA6fWxVn2GXlhbJDhwofb92vuW3pwmq YFWIBndtbd+pPGquQQghdTIZk2ptpugnCrDcGZbN+od2lTJX4/gP3nfTzqZMY1kS0TPj UsqQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:to:references:from:subject:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=tFRH0wohT+Zx3XC7IgSuI3UjZ3/AVKNkgOptlYp/7Ro=; b=gipm6aqn6xQMumwsYHZx1v8aOiE78IFv2lhGof2XDJySi0EtnKmX5L1qJojU4i5tLs DZaMZL51mXn/390Gi2AiMt3Hw6aKh7SmPv/2sUXjvL6CasRWzKMNZq9MswkZdYe0RrL4 XLpu2rjiaGEp13z7FWrjOXPY4bEpzQNkZWihPjrK7EhYdfEopOaXTpzh0xOZGd4KDZn3 HKhN0pWD3K9hTSpqbkdHr6Bqar58NKE6y8l0Re0Zu9Yvvm49QUre5O78qJKAIaiByFjG DQNsIgffr5I/gI/hhbMtaIITGq+PyRncOt2Vtai3RzQo6a0BkCLSNY8R22oVfQPtJt6T JAIQ==
X-Gm-Message-State: AOAM533V49UjTUW59O4/hZF0r14uylp0mGqoYI1DTmH7Gduq0rlGDoxq JsUOd2hwaT4vYtxCroNGpvsR9I2ybCk=
X-Google-Smtp-Source: ABdhPJw0Ld1flUGaPatG8VRUrQvPkbjkiCyPRyQznab5BeSD7bix74S4ULJKMcPmhTyst8Dz69vpxw==
X-Received: by 2002:ad4:4ae5:: with SMTP id cp5mr36231997qvb.38.1626880555762; Wed, 21 Jul 2021 08:15:55 -0700 (PDT)
Received: from ?IPv6:2607:fea8:8a0:1397:f15e:13a1:2292:bf67? ([2607:fea8:8a0:1397:f15e:13a1:2292:bf67]) by with ESMTPSA id x14sm3855002qts.13.2021. (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 21 Jul 2021 08:15:55 -0700 (PDT)
To: Mohit Sethi M <>, IETF SecDispatch <>
References: <>
From: Rene Struik <>
Message-ID: <>
Date: Wed, 21 Jul 2021 11:15:51 -0400
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.12.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: quoted-printable
Content-Language: en-US
Archived-At: <>
Subject: Re: [Secdispatch] Preliminary agenda online
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Security Dispatch <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 21 Jul 2021 15:16:05 -0000

Hi Mohit:

I would like to discuss 

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 

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] 


On 2021-07-15 5:57 a.m., Mohit Sethi M wrote:
> Dear all,
> The preliminary agenda for Secdispatch @ IETF 111 is available online:
> Let us know if you notice any discrepancies.
> @presenters/authors: please send your slides to
> early enough.
> Kathleen, Richard, and Mohit
> _______________________________________________
> Secdispatch mailing list

email: | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 287-3867