From nobody Mon Nov 8 09:47:33 2021 Return-Path: X-Original-To: crypto-panel@ietfa.amsl.com Delivered-To: crypto-panel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D5DB3A073E for ; Mon, 8 Nov 2021 09:47:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isode.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T0oo9rSC_dWc for ; Mon, 8 Nov 2021 09:47:27 -0800 (PST) Received: from statler.isode.com (Statler.isode.com [62.232.206.189]) by ietfa.amsl.com (Postfix) with ESMTP id 014393A074B for ; Mon, 8 Nov 2021 09:47:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1636393645; d=isode.com; s=june2016; i=@isode.com; bh=l0gD2iP2PFe8LUYZWgKIU/itoNTo6KzBJ2Yk93dkx5E=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=eA19ttl8NggTsqA4xV2TVpJVeQ8HxP3y7YNUKrEmxUFcOUpetOZmM/LWCZXO8TYEUXHtlt kdHB7a8cibhFRnUu8a4CszesPpH39bGPiYqXWzbpkOz777JiTmriAvgDLgRebj4OdqeNNl QsJHnBdnLIZZ40qG0Gt3B/rRhrH9ZeY=; Received: from [192.168.0.5] ((unknown) [94.3.228.58]) by statler.isode.com (submission channel) via TCP with ESMTPSA id ; Mon, 8 Nov 2021 17:47:25 +0000 X-SMTP-Protocol-Errors: NORDNS From: Alexey Melnikov To: crypto-panel@irtf.org Cc: "cfrg-chairs@ietf.org" Message-ID: Date: Mon, 8 Nov 2021 17:47:24 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.14.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-GB Archived-At: Subject: [Crypto-panel] End of 2 year term for the Crypto Panel members X-BeenThere: crypto-panel@irtf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Nov 2021 17:47:32 -0000 Dear Crypto Panel members, When CFRG chairs announced the current Crypto Panel membership the stated term length was 2 years (January 2020-December 2021). We are now near the end of this term, so CFRG chairs will be soon anouncing another round of applications for the following two years. Chairs are very pleased with work done by the current Crypto Panel and would like to encourage existing members to re-apply. (If instead you want to step down, please also let the chairs know by emailing cfrg-chairs@ietf.org directly.) Thank you, Alexey, on behalf of the CFRG Chairs From nobody Mon Nov 8 10:05:40 2021 Return-Path: X-Original-To: crypto-panel@ietfa.amsl.com Delivered-To: crypto-panel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B0F53A0C7B for ; Mon, 8 Nov 2021 10:05:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BQi468qAUI8S for ; Mon, 8 Nov 2021 10:05:32 -0800 (PST) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8799D3A0C77 for ; Mon, 8 Nov 2021 10:05:32 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 0E674300BF9 for ; Mon, 8 Nov 2021 13:05:34 -0500 (EST) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id S5Pi6LE4h6Kf for ; Mon, 8 Nov 2021 13:05:32 -0500 (EST) Received: from a860b60074bd.fios-router.home (pool-141-156-161-153.washdc.fios.verizon.net [141.156.161.153]) by mail.smeinc.net (Postfix) with ESMTPSA id 6CF553005D7; Mon, 8 Nov 2021 13:05:32 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.21\)) From: Russ Housley In-Reply-To: Date: Mon, 8 Nov 2021 13:05:29 -0500 Cc: crypto-panel@irtf.org, "cfrg-chairs@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <3411BB5B-7183-4846-87C4-3682C3572400@vigilsec.com> References: To: Alexey Melnikov X-Mailer: Apple Mail (2.3445.104.21) Archived-At: Subject: Re: [Crypto-panel] End of 2 year term for the Crypto Panel members X-BeenThere: crypto-panel@irtf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Nov 2021 18:05:38 -0000 I am willing to continue. Russ > On Nov 8, 2021, at 12:47 PM, Alexey Melnikov = wrote: >=20 > Dear Crypto Panel members, >=20 > When CFRG chairs announced the current Crypto Panel membership the = stated term length was 2 years (January 2020-December 2021). We are now = near the end of this term, so CFRG chairs will be soon anouncing another = round of applications for the following two years. Chairs are very = pleased with work done by the current Crypto Panel and would like to = encourage existing members to re-apply. (If instead you want to step = down, please also let the chairs know by emailing cfrg-chairs@ietf.org = directly.) >=20 > Thank you, >=20 > Alexey, on behalf of the CFRG Chairs >=20 >=20 > _______________________________________________ > Crypto-panel mailing list > Crypto-panel@irtf.org > https://www.irtf.org/mailman/listinfo/crypto-panel From nobody Mon Nov 8 10:33:45 2021 Return-Path: X-Original-To: crypto-panel@ietfa.amsl.com Delivered-To: crypto-panel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 677193A0E48 for ; Mon, 8 Nov 2021 10:33:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.178 X-Spam-Level: X-Spam-Status: No, score=-5.178 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_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, NICE_REPLY_A=-3.33, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hmry2IjJ3qsm for ; Mon, 8 Nov 2021 10:33:38 -0800 (PST) Received: from mail-wr1-x434.google.com (mail-wr1-x434.google.com [IPv6:2a00:1450:4864:20::434]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5E9F33A0E27 for ; Mon, 8 Nov 2021 10:33:38 -0800 (PST) Received: by mail-wr1-x434.google.com with SMTP id t30so28540826wra.10 for ; Mon, 08 Nov 2021 10:33:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=message-id:date:mime-version:user-agent:subject:to:references:from :in-reply-to:content-transfer-encoding; bh=T7YLxDto4ipHGo1iACI5KCMaw/pZNhPyT3wvvex6T9U=; b=P0VmvvOSx4ezBxcUwIIBz61yckj0Ut8UVinV3scd8UfEdDGuqx+v4wqMhxwegnjTUT puDTsoaK+cCWs1rNuwzdXCcCGcesLA875vtPm2lFu9Ua0MzmZJvjF04QAAL4RgnYsnXo UjtL/q2h4gBSWlgP+FtaslcEwsQJylCwbGx4juVLHCFb1GyoFNcn5dxBdZWkObVP1zTJ YVmdlPioTBbiL35A8pCKu2i4JQnQCzkkhvrr/hqC2xKgwrYI0wu1R64q6TCG8N7VEDqQ Ras/SuzzdyRo9SAKm81IUSFt0DB0E6E4x/Q6LMKmrBocjwG5q+F1gtr4d5CjKe2MT02r KdKg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :to:references:from:in-reply-to:content-transfer-encoding; bh=T7YLxDto4ipHGo1iACI5KCMaw/pZNhPyT3wvvex6T9U=; b=F9xb8VTe+UkfQzgCKqJzyweBYG+Em8WdXdJ8wWHoJZ5+BKzF5mEk3Ey3oXa9oMsZbY Pdk2FYpJGrlBcr45syHYTQkOYo1DqxhyWENWXiXcypykmzvoIsaeNtSOR76T2bFQVRmC zBNsOFDqOtWU990ZIE/KWU0H8YHbSjssZ+CaPAo+GEEgAXaofrOsldmJW2PzqKqeYOmy 1L4GveCGlIci02LbLxne19280tVJNF3nSCN+TFtNsI1u+sxkBN2G/7uxLZAaYhu+LbVv 2XL7Bp96+6290L3BdpI+7oEtgOAL6GvEBToS0+WvBqz4PzDj0DSH0L3pXKzgz0GvDg8M X1AA== X-Gm-Message-State: AOAM533RryZ3E+zpgqmIuAZvVdL4EXRGyGK6xJfy4rR37OrTe0tOwnqQ kW+jJTrZjcFgU4S6T/kS/ZUrQ+7ttyhXOw== X-Google-Smtp-Source: ABdhPJw+0sqh0upAJMq7WO0KyJTJu1fLjrcy68ilG3Dte7OVJ3kHdzamku8ulz8aKO5BEJK/Rj3eog== X-Received: by 2002:a5d:4a85:: with SMTP id o5mr1487709wrq.109.1636396415936; Mon, 08 Nov 2021 10:33:35 -0800 (PST) Received: from ?IPV6:2a02:aa12:a780:5480:68e8:8de1:e49:acda? ([2a02:aa12:a780:5480:68e8:8de1:e49:acda]) by smtp.gmail.com with ESMTPSA id c1sm17352675wrt.14.2021.11.08.10.33.35 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 08 Nov 2021 10:33:35 -0800 (PST) Message-ID: Date: Mon, 8 Nov 2021 19:33:34 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.3.0 To: crypto-panel@irtf.org References: <3411BB5B-7183-4846-87C4-3682C3572400@vigilsec.com> From: Julia Hesse In-Reply-To: <3411BB5B-7183-4846-87C4-3682C3572400@vigilsec.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Crypto-panel] End of 2 year term for the Crypto Panel members X-BeenThere: crypto-panel@irtf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Nov 2021 18:33:43 -0000 Me too! (Still on the OPAQUE draft review...) Julia Am 11/8/2021 um 7:05 PM schrieb Russ Housley: > I am willing to continue. > > Russ > >> On Nov 8, 2021, at 12:47 PM, Alexey Melnikov wrote: >> >> Dear Crypto Panel members, >> >> When CFRG chairs announced the current Crypto Panel membership the stated term length was 2 years (January 2020-December 2021). We are now near the end of this term, so CFRG chairs will be soon anouncing another round of applications for the following two years. Chairs are very pleased with work done by the current Crypto Panel and would like to encourage existing members to re-apply. (If instead you want to step down, please also let the chairs know by emailing cfrg-chairs@ietf.org directly.) >> >> Thank you, >> >> Alexey, on behalf of the CFRG Chairs >> >> >> _______________________________________________ >> Crypto-panel mailing list >> Crypto-panel@irtf.org >> https://www.irtf.org/mailman/listinfo/crypto-panel > _______________________________________________ > Crypto-panel mailing list > Crypto-panel@irtf.org > https://www.irtf.org/mailman/listinfo/crypto-panel From nobody Mon Nov 8 10:38:18 2021 Return-Path: X-Original-To: crypto-panel@ietfa.amsl.com Delivered-To: crypto-panel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C2423A0F0E for ; Mon, 8 Nov 2021 10:38:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 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, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JEbfjql7RISr for ; Mon, 8 Nov 2021 10:38:07 -0800 (PST) Received: from mail-lf1-x12e.google.com (mail-lf1-x12e.google.com [IPv6:2a00:1450:4864:20::12e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CC2D73A0E9F for ; Mon, 8 Nov 2021 10:38:06 -0800 (PST) Received: by mail-lf1-x12e.google.com with SMTP id l22so11551759lfg.7 for ; Mon, 08 Nov 2021 10:38:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Y7JUN2KDFb21+VmMmk+MqjGgFVs0TMDlh50DRJlhhcA=; b=WSvnem4+lOSIPGBeW5rtFnu746X6Imj2pH7Xdnsu2Iolx4+n1RprjS4zDp5moMBQe3 ZE9jE27lCRwjHv6KORSbkjSQdCRuUJFxT6+UFSpOsujuLq7af1r8jg8aHkaRV/sslKU2 MOYjjtu7cSB/rGbfvGfnzTVrIijHU+aMKNuns4KMorGb9+NMfMSLB0dY07TuMKLLN7pF CpioqDsRS3w7aUbWVkbQPFtQ2dh+ehD20rQY6YIi8QC5vFQKfzwWTalqxHqiRN5S3j2z pcb5tXFl6t+QyDsDpkyHysNxAMzMppRS76YdPHoG9qB6/QZVxGC5noimlSdZGJyKIVi9 RQ/w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Y7JUN2KDFb21+VmMmk+MqjGgFVs0TMDlh50DRJlhhcA=; b=lTeAI+SqDqiYxhfUGhl5HtrQwWcXf5DbZShOQdBSwGVUv0sG0MZxprZypAqKi+xoWM 3A/CMeITzgnsOqea87tldXd/3FpDbLd8pHw0E6R4L5x6haUJ1RHh8KkN7s2466Hq/L5m /PJN71koruS9KAbbppGf0jLXV1aMRHVdnVrmKIC0OQwKJ4hfn566HSJ6ALgUTk0Yv4bf aZbNEOn/g8aBrJtbIb+C3QfR72yXbzA2C4XF2oYdVw8flLqnZbuXj16LDS0xit2dL6q1 2prVdVEqTUlnglyCSiPRojbGwX3PD2YkCrGv1YBGFvZVReS6UXlh3nlj2nlyWV6fEc3R xYdw== X-Gm-Message-State: AOAM530qALLOnU/9dyjCqxY/EgZqztq+j0I5gAPi8SQ+wGemnuWWz96c zf/1OEdUJRFcZ2cggsx44wS3XqqcEV7dQ+mOXMs= X-Google-Smtp-Source: ABdhPJwKucOWFgAseUgbppwBXbqNx1nFbJn/FAoBDFM8x4sL+iCy3Htt1kDU7kZYjst/9BEJvVzDSaQKixaSGaKNeF4= X-Received: by 2002:a05:6512:398a:: with SMTP id j10mr1275059lfu.126.1636396683203; Mon, 08 Nov 2021 10:38:03 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Jean-Philippe Aumasson Date: Mon, 8 Nov 2021 19:37:52 +0100 Message-ID: To: Alexey Melnikov Cc: crypto-panel@irtf.org, "cfrg-chairs@ietf.org" Content-Type: multipart/alternative; boundary="00000000000003960705d04b4b8d" Archived-At: Subject: Re: [Crypto-panel] End of 2 year term for the Crypto Panel members X-BeenThere: crypto-panel@irtf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Nov 2021 18:38:17 -0000 --00000000000003960705d04b4b8d Content-Type: text/plain; charset="UTF-8" Happy to continue, although I haven't contributed much in the last two years, but if you think I can help then I'll be happy to do so when opportunities arise. On Mon, Nov 8, 2021 at 6:47 PM Alexey Melnikov wrote: > Dear Crypto Panel members, > > When CFRG chairs announced the current Crypto Panel membership the > stated term length was 2 years (January 2020-December 2021). We are now > near the end of this term, so CFRG chairs will be soon anouncing another > round of applications for the following two years. Chairs are very > pleased with work done by the current Crypto Panel and would like to > encourage existing members to re-apply. (If instead you want to step > down, please also let the chairs know by emailing cfrg-chairs@ietf.org > directly.) > > Thank you, > > Alexey, on behalf of the CFRG Chairs > > > _______________________________________________ > Crypto-panel mailing list > Crypto-panel@irtf.org > https://www.irtf.org/mailman/listinfo/crypto-panel > --00000000000003960705d04b4b8d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Happy to continue, although=C2=A0I haven't contributed= much in the last two years, but if you think I can help then I'll be h= appy=C2=A0to do so when opportunities arise.

On Mon, Nov 8, 2021 at 6:47 PM = Alexey Melnikov <alexey.mel= nikov@isode.com> wrote:
Dear Crypto Panel members,

When CFRG chairs announced the current Crypto Panel membership the
stated term length was 2 years (January 2020-December 2021). We are now near the end of this term, so CFRG chairs will be soon anouncing another round of applications for the following two years. Chairs are very
pleased with work done by the current Crypto Panel and would like to
encourage existing members to re-apply. (If instead you want to step
down, please also let the chairs know by emailing cfrg-chairs@ietf.org
directly.)

Thank you,

Alexey, on behalf of the CFRG Chairs


_______________________________________________
Crypto-panel mailing list
Crypto-panel@irt= f.org
https://www.irtf.org/mailman/listinfo/crypto-panel=
--00000000000003960705d04b4b8d-- From nobody Mon Nov 8 11:08:45 2021 Return-Path: X-Original-To: crypto-panel@ietfa.amsl.com Delivered-To: crypto-panel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA5713A0A10 for ; Mon, 8 Nov 2021 11:08:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.618 X-Spam-Level: X-Spam-Status: No, score=-9.618 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_NONE=0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=hd0WhbVl; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=gOlPzSc5 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WB8g1jlZ1rBL for ; Mon, 8 Nov 2021 11:08:38 -0800 (PST) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 33B593A0A09 for ; Mon, 8 Nov 2021 11:08:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1066; q=dns/txt; s=iport; t=1636398518; x=1637608118; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=ULb0k6yp2Jcgw1DMthWBCuEnyPdoC5aVGuFa7LQUDSU=; b=hd0WhbVl4qYCUP67Fb7mgVqzO37YbG51E8+ItjQwAdv4fNVSvQRlAMwm yCh2BC2eYNB1vBjvrqoqBUknX5WtCAwrxhT6xBsr5t2njDaPygyApRZLc yuPwOOgkwvnhp3Et8GimW+tjW4mlNKAU4jQyGFaQLj6Ce2a95va7Nnq0h c=; IronPort-PHdr: =?us-ascii?q?A9a23=3AOcnSPRECw9RIONzFZ7stQZ1GfjwY04WdBeZdw?= =?us-ascii?q?ps8jL5DNK+k+seqME/e4KBri1nEFcXe5ulfguXb+6bnRSQb4JmHvXxDFf4EV?= =?us-ascii?q?xIMhcgM2QB1BsmDBB76N/nmYmoxG8ERHFNg9muwZE5SHsu2blbOo3q0uDgVH?= =?us-ascii?q?Bi3NQd8KunvXIDIiMHi3OGp8JqVaAJN11KA?= IronPort-Data: =?us-ascii?q?A9a23=3AtxvqDKonzNjXDZqBmr6xWPg4wq5eBmLSZxIvg?= =?us-ascii?q?KrLsJaIsI4StFCztgarIBmHOqnfajf0Kot+atvj/UoPupCHnYUxHgVpqCAwR?= =?us-ascii?q?SsS9OPIVI+TRqvS04x+DSFioHqKZKzyU/GYRCwPZiKa9kjF3oTJ9yEmjPjRH?= =?us-ascii?q?uqkUYYoBwgoLeNaYHZ54f5cs7ZRbr5A2bBVMivV0T/Ai5S31GyNg1aYBlkpB?= =?us-ascii?q?5er83uDihhdVAQw5TTSbdgT1LPXeuJ84Jg3fcldJFOgKmVY83LTegrN8F251?= =?us-ascii?q?juxExYFENiplPPwdVcHB+OUNgmVgX0QUK+n6vRAjnVtieBga7xNMgEO1mvhc?= =?us-ascii?q?9NZkL2hsbSrRwM0PrfBgswWUgJTFGd1OqguFLrvcCbm7JzClRybG5fr67A0Z?= =?us-ascii?q?K0sBqUT9Px4RGpO/P0CMxgMYwyNweWsz9qTQfN9ntgkadHiOo4bknB60T+fC?= =?us-ascii?q?uwpKbjKR6ja6M4e2To0gMFNGuj2ZtEeZTcpZxPFCyCjkH9/5IkWhuykgDz0d?= =?us-ascii?q?CdV7Q/Trqss6G+Vxwt0uIUB+eH9IrSiLfi5VG7Czo4ew1nEPw=3D=3D?= IronPort-HdrOrdr: =?us-ascii?q?A9a23=3AKo0wDa/QSzTh9E09pdVuk+F6db1zdoMgy1?= =?us-ascii?q?knxilNoENuE/BwxvrBoB1E73DJYW4qKQ4dcdDpAtjmfZquz+8K3WB3B8biYO?= =?us-ascii?q?CGghrnEGgG1+vfKlLbalbDH4JmpMJdmu1FeaHN5DtB/IbHCWuDYqwdKbC8mc?= =?us-ascii?q?jC74qzvhQdLz2CKZsQkjuRYTzrdHGeMTM2fabRY6Dsn/avyQDQHUg/X4CePD?= =?us-ascii?q?0oTuLDr9rEmNbNehgdHSMq7wGIkHeB9KP6OwLw5GZcbxp/hZMZtUTVmQ3w4a?= =?us-ascii?q?uu99uhzAXH6mPV55NK3PP819p4AtCWgMR9EESvtu/oXvUlZ1SxhkFznAid0i?= =?us-ascii?q?dtrDAKmWZ4Ay1H0QKUQohym2q05+Cv6kd015ao8y7ovZKqm72IeNt9MbsauW?= =?us-ascii?q?qcGSGpt3bJe7pHof92NiuixulqJAKFkyLn69fSURZ20kKyvHo5iOYWy2dSSI?= =?us-ascii?q?0EddZq3MEiFW5uYdw99RjBmcoa+ShVfbbhzecTdUnfY2HSv2FpztDpVnMvHg?= =?us-ascii?q?2eSkxHvsCOyTBZkH1w0kNdnaUk7zg93YN4T4MB6/XPM6xumr0LRsgKbbhlDO?= =?us-ascii?q?NERcesEGTCTR/FLWrXK1X6E6MMPW7LtvfMkfkIzfDvfIZNwIo5mZzHXl8dvW?= =?us-ascii?q?kue1j2AcnLx5FP+gClehT0Yd0s8LAW23FUgMyIeFPbC1z0dLl1qbrTnxw2OL?= =?us-ascii?q?yuZ8qO?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AmAABndIlh/5xdJa1aGwEBAQEBAQE?= =?us-ascii?q?BBQEBARIBAQEDAwEBAUCBRgUBAQELAYFRUQd3WjcxiA4DhTmIEQObAoEuFIE?= =?us-ascii?q?RA1QLAQEBDQEBKgsMBAEBhD1FAoJWAiU1CA4BAgQBAQESAQEFAQEBAgEGBIE?= =?us-ascii?q?RE4VoDYZCAQEBAQMBARAoBgEBLAsBCwQCAQgRBAEBHxAnCx0IAgQBDQUIGoJ?= =?us-ascii?q?QglUDLwEOn1YBgToCih94gTOBAYIIAQEGBASFChiCNQMGgToBgwqJf4EfJxy?= =?us-ascii?q?BSUSBFUOCNzA+gmMBgSc8g02CLo9VEH1bPYFfvj0KgzifGxWDbItxl0uWEB+?= =?us-ascii?q?lZAIEAgQFAg4BAQaBYwI3gVlwFTuCaVEZD44gg3KFFIVKdDgCBgsBAQMJkHU?= =?us-ascii?q?BAQ?= X-IronPort-AV: E=Sophos;i="5.87,218,1631577600"; d="scan'208";a="961589295" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 08 Nov 2021 19:08:36 +0000 Received: from mail.cisco.com (xbe-rcd-002.cisco.com [173.37.102.17]) by rcdn-core-5.cisco.com (8.15.2/8.15.2) with ESMTPS id 1A8J8a8v021712 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=OK); Mon, 8 Nov 2021 19:08:36 GMT Received: from xfe-rtp-005.cisco.com (64.101.210.235) by xbe-rcd-002.cisco.com (173.37.102.17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.15; Mon, 8 Nov 2021 13:08:35 -0600 Received: from xfe-rtp-002.cisco.com (64.101.210.232) by xfe-rtp-005.cisco.com (64.101.210.235) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.15; Mon, 8 Nov 2021 14:08:35 -0500 Received: from NAM02-BN1-obe.outbound.protection.outlook.com (64.101.32.56) by xfe-rtp-002.cisco.com (64.101.210.232) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.15 via Frontend Transport; Mon, 8 Nov 2021 14:08:34 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=iV1xqZqEPBkYNA9bh40/FgDHdKX/1hlD2sWX4kdjhi9nSwZuoyPtM3Wp+mBP2l2QnFqW2sSl/ZCZxYC0mahZT/sjD0FznFzaL8L5Zk/+EkUFjBnSG4L8n0vnavebJwLVISrDtI59qsQeTnXQ6SQ0i95ZS+fXZh7SAXea4I3x+k3At48kKaGauxY7MuKxUDfdUc1CeSnXp7/hp3Db6rKYBfQE2Bt6BfKvQKlHL7MDgw3YPT0JcoAN8bP/rOF4zzFPLD3rnDLX4Eq4bH3BE28NOBZcO3wXUvrqJGDfBd+vZvxjon/y6WAZ/Cimhk0Ot7VeCo5x5PspwPWtr3RgsrxQNA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=ULb0k6yp2Jcgw1DMthWBCuEnyPdoC5aVGuFa7LQUDSU=; b=LZUzp7ROoKWIdXytil6dG6il/6wfmqLrlFEPNRWNLIUS8TCP/1jVsNVPnTo0gz1a9momsfAG0Hrk54b6B+8lRUlJjQ0ZbyjERuiccmwI36pan7AAo+hbrjSf/hQe9Mdbn9UXEmFPEn30VTYGvFBj35m7jbCwrnBQrafdWkVa1iYauCUR9VJ6G1H2vaiqKd4KYCFwYAryBS99IlsFbO5kpOYApZ4J0LQ7RL/Vbk36DW59SNwJAzZd/DaTJxUB4+UOgHUITYLB0s0kpot3Ny/b+7oKusJwLStnN/qsURCMD6h1pkM5WfMc3KcJtpsLAYa6XAQBlQrhOTD2lb8Y/AyuMA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ULb0k6yp2Jcgw1DMthWBCuEnyPdoC5aVGuFa7LQUDSU=; b=gOlPzSc5jETFIPTqzj3bLPnfipL1aBRqFOBdav4U1qSvx7cjgHxSttC3mr1KQCAxYMp0oG6g2uSR7YuSdmMXsvIXwriOQRsn8yxrj0lPtsf4FXAM7xfSqQ2LWTIQC/csvASUhfKQHokXM8hbBr8tL1tv7vo3sm7p7xnrs/9aRZk= Received: from BL3PR11MB5682.namprd11.prod.outlook.com (2603:10b6:208:33d::18) by MN2PR11MB4367.namprd11.prod.outlook.com (2603:10b6:208:18b::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4669.11; Mon, 8 Nov 2021 19:08:34 +0000 Received: from BL3PR11MB5682.namprd11.prod.outlook.com ([fe80::7967:f6c7:1632:1549]) by BL3PR11MB5682.namprd11.prod.outlook.com ([fe80::7967:f6c7:1632:1549%7]) with mapi id 15.20.4649.020; Mon, 8 Nov 2021 19:08:34 +0000 From: "Scott Fluhrer (sfluhrer)" To: Alexey Melnikov , "crypto-panel@irtf.org" CC: "cfrg-chairs@ietf.org" Thread-Topic: [Crypto-panel] End of 2 year term for the Crypto Panel members Thread-Index: AQHX1Mi7i2/0iDolcEiIW1lAsb3h0qv5/nIQ Date: Mon, 8 Nov 2021 19:08:33 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: isode.com; dkim=none (message not signed) header.d=none;isode.com; dmarc=none action=none header.from=cisco.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: c0f0bc68-1dde-448f-44bb-08d9a2eb2932 x-ms-traffictypediagnostic: MN2PR11MB4367: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: xmfM1I+3J7Mx6W4LqoojsxfAmMY4BDOcZGZWz59S0hreKvWGNFlBkQIC/rD3kMsZw4BAnhP4z5V0x+kduJEeTya8IZ3PGrYG28EoVWSJlSIlSInLiYMqUVelDNdwPqJHPjRKzye5rVGPkS9Fow7hL2LTNwPwYf6R8d4DEOlpV1kVT8ZQ5nfBDVGozC+soBzftBXiaIy0dgb9NSIYw9tNyQdsJIWDaBVvVxwZJpUzkRaszr62Vwa/hscKDlQxxxMxO6YWNRpt2cQPK8IeIt9MDMwS01dG4fyV9DS6eCQRExUs0F2p1ZtRg35YHXFNy6YvbKMRmchdhUTsrtKfD24ASHEDZSduqC/N5AbBdeJqxH9XtSIj9qfg/qaC0S1+QxIdC+GpQBWjbiknBTYApDLKbunYzOIlGmdoCAYXwxVA/fxK0NcYiFW7yudI3jEICikdnYgHY1yL6eUcOyF8qrLMP779BzyCyIB59E5kP6j4oC3C7wFKEr9n5YE/ASJ7O8sIjCjb4o7sYNNyTsvBOaMPzWR7f+bSOXdVb0fRl7APCRgqvePTNhBb61w+fApnIIYa4xHI8fhlYv00TufYsD1E6bbnzwZqOaxze8cOCgUFblkNZ+XRoVzswAO1FR55/TFvEErratP+2FirymdYKdMnufA3Nc5z8dJ+ltRx6YkE03n9WkQ/xZumk811Y9bMW7bY/RZmVhkF9Cmibj+aHqup+1kB7aQvPPTmvwogEqxaY/6tnIM2lCY/f+8Kdtg2LS5EKk16jRR+tKiFnND8kh4AtXNsSt09eroVYB8654fhtlk= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BL3PR11MB5682.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(366004)(7696005)(110136005)(2906002)(33656002)(52536014)(76116006)(8676002)(316002)(8936002)(26005)(66476007)(4744005)(66446008)(71200400001)(5660300002)(53546011)(38070700005)(186003)(86362001)(66946007)(6506007)(55016002)(4326008)(64756008)(122000001)(66556008)(966005)(9686003)(508600001)(38100700002)(83380400001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?6L1ZCKYSI4+opikcGUEWnVVugIguxtQTVtmrTWBzoAK4cWx4Jhub3sV0x3ww?= =?us-ascii?Q?ctJQ61qHuMPqrSSw1vjWbJqBk/2VfFheso6j8tlJZPPdfGOIQ2XWaV41jy7g?= =?us-ascii?Q?0wNcQWyWPZxH0DtMfGcjDuMvDQouZhsihxBtBDHl6dMx5bSdsIBBejs0YlZA?= =?us-ascii?Q?4zISmfsUeCQ3G3fE55WPqniuU8+wJaWpzulPylAPyiXJ2PZ0+LX2dFsUUORE?= =?us-ascii?Q?ifYAGftRZ0IOGtxeuBYyGxStxmT0mCXoEcU8YrRNi8muEuWd4Q9rwC07QS18?= =?us-ascii?Q?D1wYmo0Nn83onJzKhi8kXQg+GtAjXpIdSb5j70SVnwU+n9t5vBDWvZ0NrDH6?= =?us-ascii?Q?TS5FGxHd5t4f0FxBwVNUXkEliF0+ziLEyqU2S7b/qO/H4rbtW6AnjWGzgkGF?= =?us-ascii?Q?fO1exizqDLWw3GAr2r7XVjTZRg+7Bk9rtizzBBbSQoVWIQ66gx6iaVZuPRGg?= =?us-ascii?Q?sIO3J10D4vwjnj3P4GhAz3aWYSBm/J0wTVy9vg7IXoqjAVD7u2yVPY39Rgi3?= =?us-ascii?Q?nqr2x2w8wV0woHLmN8I1Nm72suJLbl9R+BpMXbFxgNBB0iFWEBpoU0Jd703a?= =?us-ascii?Q?lTO7MFTGJgNh2Hg2vl8QXjxyKxSOKkaPwvTsPaeednUMS2TrwzBAh3MGJihg?= =?us-ascii?Q?3XH44D3ZY0KGOX7fAM5vsaMDaIg9GJYvlmjMuKJE2jeeiK9xGQJFjzJKdiq9?= =?us-ascii?Q?ItWrh7ztfUESju6iVnIg8EDK9On8ZSxi280o7JCtHxL7VGt9p13INpBP4Io/?= =?us-ascii?Q?cF7l3mkvP3ZzrOcCNWlvHhBv7cmWwcHL/5c9w1vEspvmDRTzT9mx0ZjG263i?= =?us-ascii?Q?gg8CTa0sMkuOCBn+I7O8MR3iVr6nulOnSCa569t+cDH0WPwOIJwi5SH8cFaW?= =?us-ascii?Q?C/xErFoGEVgZ+buucrfilfG29URmnKwds29lIrthFSd0zPcndPfru1uR+MjL?= =?us-ascii?Q?nb2f/m5khVegg0boiX/iUom/aIBkV9Qft7ehQZV2k0tGKVR/1Tv5x7K3NWJl?= =?us-ascii?Q?x/3MzYDFxx5IxISlJUBeIRWGd86ovYY/36Vbd3tC9U6YnXLpD7craFdlVSQz?= =?us-ascii?Q?bmmxaDWfBXIHiBh2yHD6kLXonXV6eBqCNrfo9Omf2PGUsgpTgFwMJ38hO34M?= =?us-ascii?Q?NLQLWaFKdU0bs9Wt42ptSG1XTQ3XsEJ/Lv/MGhRLaF5KVDTYnd+jUF2VOOsx?= =?us-ascii?Q?xeyDQZpDbP7YkUYMJLpSRTX1yu7FhwMhnaN65qse/g4XdnpbCLBGENxEc1yy?= =?us-ascii?Q?z1T4spdmB99qWBunQN8aJi2AUsPEqe2XDaTVJ6EyUoD2DfGv4HT9tmx3yseV?= =?us-ascii?Q?7XYVfSE4B4+3gxVpL2IyrUecakIWhLw7MsPqWIT8H2W2mJgexdQ3uSz+6XS1?= =?us-ascii?Q?+PnsJNlpBCi9OTxf9ObTPLYWXkY3bEZyWZ5sZ1GdULZeL3A7vkUPwqfWgr8A?= =?us-ascii?Q?q7SFrmDk0Q5S4dl9zGM2L6+dpzgOtzmq3h1xtkgaFI4RpnKr7ZB+hIjCSgZa?= =?us-ascii?Q?YcOsIn34aWuQKbdejEOQMFlHxwR0yY1CtWdTNxrZJrdL+eYeSKKnaRqW9e8s?= =?us-ascii?Q?lpf1A7G+GY4j4ndRdAdCjr0yHHGyAO+y6OKa/e25q/HGNp/0cowPUrVCPnNH?= =?us-ascii?Q?1A=3D=3D?= Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BL3PR11MB5682.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: c0f0bc68-1dde-448f-44bb-08d9a2eb2932 X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Nov 2021 19:08:34.0137 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 3bk9dwrLJMh2Z+Gt0IE2vuZgQ6RMGsbVkJfs42gPOwqJNZZaW+LC/Oo0eBs1Sc93CZ/Wdq6sSgcJPCiPV9KpMg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB4367 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.17, xbe-rcd-002.cisco.com X-Outbound-Node: rcdn-core-5.cisco.com Archived-At: Subject: Re: [Crypto-panel] End of 2 year term for the Crypto Panel members X-BeenThere: crypto-panel@irtf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Nov 2021 19:08:44 -0000 I'm willing to continue -----Original Message----- From: Crypto-panel On Behalf Of Alexey Meln= ikov Sent: Monday, November 8, 2021 12:47 PM To: crypto-panel@irtf.org Cc: cfrg-chairs@ietf.org Subject: [Crypto-panel] End of 2 year term for the Crypto Panel members Dear Crypto Panel members, When CFRG chairs announced the current Crypto Panel membership the stated t= erm length was 2 years (January 2020-December 2021). We are now near the en= d of this term, so CFRG chairs will be soon anouncing another round of appl= ications for the following two years. Chairs are very pleased with work don= e by the current Crypto Panel and would like to encourage existing members = to re-apply. (If instead you want to step down, please also let the chairs = know by emailing cfrg-chairs@ietf.org directly.) Thank you, Alexey, on behalf of the CFRG Chairs _______________________________________________ Crypto-panel mailing list Crypto-panel@irtf.org https://www.irtf.org/mailman/listinfo/crypto-panel From nobody Mon Nov 8 11:10:51 2021 Return-Path: X-Original-To: crypto-panel@ietfa.amsl.com Delivered-To: crypto-panel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B45D93A0A71 for ; Mon, 8 Nov 2021 11:10:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 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, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=nccgroup.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4cM80Uu4xw7x for ; Mon, 8 Nov 2021 11:10:45 -0800 (PST) Received: from NAM10-BN7-obe.outbound.protection.outlook.com (mail-bn7nam10on2048.outbound.protection.outlook.com [40.107.92.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D25173A0AB9 for ; Mon, 8 Nov 2021 11:10:44 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=UzMXzZC7Ffmj+QQHt2tZQWGl/uyU5PNi8Gl+fVlpsCc+KSBZBOgG9IZUsPFHRydS5QXmSIGRjIRlonqpFaQRG7fMA0acy/aL5IQLeZL4C6mhfBQ2FpIknBZXsPFpGWWXq/03oNtuO2VjygovbViFoK9dzoKqaw0ALdK3S5uAOeCsVe36uTTbb0wTQG7LspuytIKuoGjoAnFIjDdluhAQaWm8TCSPninMXl5cUykqr3m3YY0DHZYNRb4R5Ep22IDFzbVEmAlqBaXPXq9wouvEwuEK2wbWBkPIJkCyFN4dVtCX5Nv0+iMGw8gh+154YcP42TaP1xKKi7hht4hmJtP+2g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=vGVb0TI7JTCM/x5Xi58ysuutEW23Q0OXL0R6C7KQmSQ=; b=nldhpJN4GpUQ+Dka+XD1+GCnk6WnjO484xjANXRQQPS1Ku0J8BHm/RFeG9/XmEsyexEANV/sRxNpTfFiUqBFKfx7bONuaJE3NK/apU1Zw1MEafIXZYnFAl9dR5L+7GIPfldG8LjR9ZTYuu2jQ38y3kXdQOQwOjJJpu4cbhvPCNAtPYJKpidliPB0zjzOdT9oiY2tdibkPSD/vm4YV9sr0CCvZM5Y6CGCZrfl3TDouCnYMLpVYdmitWZs7wf5GLmCk+HZhiv0ZZCBePOUoUuSQ9P7hsLVACD8G5JUNNySMu9hPhn77FeL9N/4MVU0deRKhJjFW+0yrzRMJsVVUCTOrw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=nccgroup.com; dmarc=pass action=none header.from=nccgroup.com; dkim=pass header.d=nccgroup.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nccgroup.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=vGVb0TI7JTCM/x5Xi58ysuutEW23Q0OXL0R6C7KQmSQ=; b=Crfr/uiWfIcZJq3WJ7+IdMYWo2ebs5U1qfVf0oYZ2i2WBvMX32RvM+IoPLgwB/y4BaxUYucJhZnfkDXzXRp39ivpmBnKZVsPzTK00Foy3pk7hjc9RpwL8DG2GwEPJLwz5uZqhZl26aY4B6W/ipir8TVfMvHzrgkLNxpmk7rxLkZP5VK/DaZkFY9D0ENIBgVmiuVSYMehRvcsYwrQOVZefEbKZpqz4QeEN7aqui174KjojvEYpk+VwcDT0wFOKtCqWKVomSEgkAp2+vYOF95mKxLW2fbnNXtpV26WpN/QA7rxHCYPlsVsONRbkDeXPW5dKhTFMwKoOleiotDbRZO2Ww== Received: from DM6PR06MB6187.namprd06.prod.outlook.com (2603:10b6:5:126::28) by DM6PR06MB6460.namprd06.prod.outlook.com (2603:10b6:5:22f::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4669.11; Mon, 8 Nov 2021 19:10:41 +0000 Received: from DM6PR06MB6187.namprd06.prod.outlook.com ([fe80::9d9c:5a7b:aaef:691]) by DM6PR06MB6187.namprd06.prod.outlook.com ([fe80::9d9c:5a7b:aaef:691%5]) with mapi id 15.20.4669.016; Mon, 8 Nov 2021 19:10:40 +0000 From: Thomas Pornin To: Alexey Melnikov CC: "crypto-panel@irtf.org" , "cfrg-chairs@ietf.org" Thread-Topic: EXTERNAL: [Crypto-panel] End of 2 year term for the Crypto Panel members Thread-Index: AQHX1MjT8tiQlcjBZ0+s5nc+cn25RKv5qz0A Date: Mon, 8 Nov 2021 19:10:39 +0000 Message-ID: <78B15995-9349-49AA-8B7E-1D577E654481@nccgroup.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: isode.com; dkim=none (message not signed) header.d=none;isode.com; dmarc=none action=none header.from=nccgroup.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: ed4f45a7-50c3-4157-aa51-08d9a2eb7463 x-ms-traffictypediagnostic: DM6PR06MB6460: x-microsoft-antispam-prvs: campaign: C_Default signature: S_NoSignature disclaimer: D_NoDisclaimer x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: B2OgUZIyuZA4qriwIboVRT0jIz2g1ti7SLo/NNRG9vttPt3SzEsY9k9yhJJPHMOnRQVCzyMv1a++fiW7ryw/t1btbcuaa/mQjpY27r6KlRlYQVnMIRKFybyTvgHOCEieoxfLhq5D7bIlS0bzM2no1DvwNP2V8Etv3286gP+HLGtsFE84cARtW4DMvbOkUZjkMCI1oIlNYSODdo6Eky94vicddl8YyBVVj79Vs8UL8LOIiWQJtaAVajbyo1tW1T96BBdKiJtC9PeW2ymSh6wh8Kh5C4DnZOW6mJT+ZRWKhabquv5kKzaPzChWebQ9S3Kyofb+dCDOtIOl+umgmKaJxXSAuXZ5S3fdgC70jqGcVSaGUKkhZ1zRexGT1ti1JJvUwDcU4yhVGR58tI+HOJM9+rojZmw6ehMWBb8PzBE8Lm9TI49RM7KZ3vk8G4rBW4kP9u9Nt5+Am3L78PKHaO41spADge4niMAH7rPkkKKYwtlkMkrHCTSxfk8LBy2440yQpEP6QY1zfNI9WKlPHM8JcozT+GgC/FMdahdWHcWzEKuW1nCccUo+9LlGVr9sE9FTEObFgBkl77MDOtwFvPGeotZpFfVtrQI0XOAO771WnvTFBqEiHc/eRTT8643BM+VsutAK8GiKB4C4kBCnaKIydIS4kUOXYAMMAZWbe3cxOQPbjIRcLCe/WT5m98+uO1XMgDcONjMHRC5HEPFOC0Oarv2cYiEH5HHlA5DuUIgSChY5zGgJTzJv3GZdjdeIO6Wsrg+YJ6RMZwMPfHlSqXwFg+RSpPGyhJUAwT/FL9aUmU2de/CPpjAjgg41gmCDJjmd x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM6PR06MB6187.namprd06.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(508600001)(66946007)(8676002)(8936002)(6486002)(44832011)(6916009)(6506007)(91956017)(71200400001)(86362001)(33656002)(4326008)(26005)(6512007)(54906003)(966005)(36756003)(45080400002)(38100700002)(316002)(76116006)(66476007)(83380400001)(5660300002)(64756008)(186003)(2906002)(66556008)(38070700005)(122000001)(2616005)(66446008)(45980500001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?Yk5WZldkVXIza1U5TXRGcldYaWJwc0FiaEcrbVErb0ZIejIyNkcwM1Y0cHlt?= =?utf-8?B?UjJvNW1KZDN5QU5VV2gxUUVDbkxldmhuSU1ZNER3QWdMNXBiaHpFY0l0NEhI?= =?utf-8?B?UEVOUGF5bWFTZ2pxUlVlVUNyU1RaRjhQSUZEZFdkNFJaSHFHZmpLWEZMbit4?= =?utf-8?B?NUNTVU9IVm42d1Y2V3c1L3FWSGg1Vi9NOHVmR3lhcU5weTJwNUduVXVJN2dQ?= =?utf-8?B?MDNDRE5ETjMrVGd0ZlJtYjJuMGVkU053WXVGeTk0V2R1b0p2Z1B5Snc5M2lM?= =?utf-8?B?YlZMaUl3dXBrYnFJWnluYlFSVlBiZjFUdFc1WmNadis4RHFXUU1VNEgzcHhE?= =?utf-8?B?K1E0elg4dXJlTGxiaXlpVDZwZ1FUNEROamtkeDhab25rNVZuWlEvWllBUk91?= =?utf-8?B?NzFyMEFYaWhjQ1lvM21Yd3QwQXhsMlBpVTdRcU5NTElXbTBkU1pBL2ZrTWkz?= =?utf-8?B?Sm1scXpCRzQ2QThyQzVWZHYxdUg4M1lyTGNPY25pT3FiRU1yM1ZCTmphTzQy?= =?utf-8?B?NWd3TStzUFB6RVUrRFRaakQyUEZHYXFlclcyV2J2b1ZJUW4wYkVHRlBtblAr?= =?utf-8?B?NTRxM3ptQ0JsZ3o4cXlreldrVUI4VkJlSEJZVGQxWkpsNDBTRmV2YUlwOFNo?= =?utf-8?B?U0JiN0lkdmkyNGVERTc0WWdqbU5CUE9KNVhka3RiTlIvQUQ4Q1lWemhRbVBU?= =?utf-8?B?T1RCWkl3bWJSczJqbFdDdE9wTTlMNkNHMVlWUE5CMVh5RGhheDUvRlZleTBy?= =?utf-8?B?QmZpUDlqR3cwR2UvaWhYZGQxMUhVekhldGlSa0Z0NEYrK2JrMEJDaEJLU1A5?= =?utf-8?B?TFA2ajlLNGxyeVYxWktXYTRXU0x0WCtyazk3Mk02aFBLL0FEQyttMVBjS2Fy?= =?utf-8?B?MWViMW53RkkremFhOGpjZ2IyQ1ltQ2djamQzUERFSGxwbUxmNnRWdnMvQnhk?= =?utf-8?B?WnRPaHZGN0VnUGhiM29QYml0dUVncUFsbXJZQ2w5b05VQWhuTVRUYUJyQjgr?= =?utf-8?B?S2dpOWdPejc0Y0IzZmFtVWNFL3I2ZU1SMldiWXM3QUNIWXFKZWQxdGx3eEht?= =?utf-8?B?WkcxSWx3aFA2L1Y4Y3NzMVBoOGlvOWgzKzdSS1FaRW1DVGRnaWxpNS9BM2xS?= =?utf-8?B?TjVLZ0dGaDBDUEdwTDRCbHBrZmptV1M5MjRFR09oV0NqVEwvMGc5WXJES09W?= =?utf-8?B?Rzl2aHJBdFYvMW8wQUc0ek9ETnlKNVJrR0tBbDY5UEFOUHhUbXF6RXVPSlRY?= =?utf-8?B?YUt1akoxZnVSS2JRZHRFT241MkZEc05uVzVpWjZJa25CRTFzc2NYaXUzL2pH?= =?utf-8?B?MHQ4MEQ2TVR4Vnp1MzdKNVVGSmc1SVgvaWpWZFR3dldOWWh1N20xU3prSno0?= =?utf-8?B?RmdMZmhEUDlrV056Y3Bub054QXJ2V00rNG03QU4wa3dnRWlkUHpMdTlNSUkr?= =?utf-8?B?MDB1SjVBWXY4S3o4L2xGT281ZEZUUWxiWUxQY3VEYmhTb0ZGTzFuVWNZZS84?= =?utf-8?B?a21JVzdYekdjcUQvRlpCUDRTSnJmWCtKU3ZQUzNXVGV0dkwrY09DNUVobmFQ?= =?utf-8?B?V3FGN29JOXIyUW05d0UzZEt0eGgyTE1idmo5d3hDOEp6UldDZElGLzBoZFpw?= =?utf-8?B?TWwrdkRXWXMrTkJWVFU3eGZoeGdzeGoxdUtxem9wdWppSUdkVEJCQmtxakdN?= =?utf-8?B?dzhwcUtKUVZGbC94SGNpeHVTeUlvQjZuMDd2UFU5alViTndHQVZSSmpHamcz?= =?utf-8?B?YXg2UzIrRGNpWGF6K0V1d3BzTmlQNzV4NjFFYzRZaXFlRC81L2FZa0dnK0RL?= =?utf-8?B?UkhLRHJkWGE1WXU1Tlo2Q2JaRHpkckVSQVplcFFQMGQwSm8rLzVTN09WMS91?= =?utf-8?B?bE9LQ3Y2WjIxOTJRbHRNcTBBS08xUkRrTHNzbU9CQWFHVlZYdVRGc1hZV0N0?= =?utf-8?B?bGs0Sk5WYnNQYTJOT2llVjN2a0h5NUZEUDc1WndhRlk2eCtQVUZuODlPeFM2?= =?utf-8?B?aGxMaHNtQnEzTzFtV3ZJcjVyQ0NQbVJka1VDN21NUFlQRCtQRVc4WkRnbG4r?= =?utf-8?B?ZXpJMTZHeEV2d3AzMXA4OXkxbHJDY1V5QnR2MDg2OFJxdTJHU3d3cUhiaEpW?= =?utf-8?B?a2dVOHhqS0ltZVZhTUN0L2J3ZjlnTkViU2R1L0Vtc3RIYitQcUh2SmZYcy9l?= =?utf-8?B?cENYTGRydldscmw0OXBoaXlhTHZQN2ptejRsdlZUZ2hXQnlLUTVSK1RIa2pl?= =?utf-8?Q?45ZvrLiiK7/PmJo7z8aubX7JrEPSenuLycEiEmVVwE=3D?= Content-Type: text/plain; charset="utf-8" Content-ID: <0B38CF89D185B144A6CD2A508519D143@namprd06.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: nccgroup.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DM6PR06MB6187.namprd06.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: ed4f45a7-50c3-4157-aa51-08d9a2eb7463 X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Nov 2021 19:10:39.0965 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: a41111be-486b-45f6-8bd0-ee01a62f368e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: HtL0Juu6YX3yKoOGwoLved3yFDAYwciwN3uC5QUW2VSuE/eG8GuZmyr2c+/hU6KN+zRuPKCALhUbEQ3Y8Mo0DO1VQreEVezh2uvFxcp71Kg= X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR06MB6460 Archived-At: Subject: Re: [Crypto-panel] EXTERNAL: End of 2 year term for the Crypto Panel members X-BeenThere: crypto-panel@irtf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Nov 2021 19:10:50 -0000 SSdsbCBiZSBoYXBweSB0byBjb250aW51ZS4NCg0KVGhvbWFzDQoNCu+7v09uIDIwMjEtMTEtMDgs IDEyOjQ4LCAiQ3J5cHRvLXBhbmVsIG9uIGJlaGFsZiBvZiBBbGV4ZXkgTWVsbmlrb3YiIDxjcnlw dG8tcGFuZWwtYm91bmNlc0BpcnRmLm9yZyBvbiBiZWhhbGYgb2YgYWxleGV5Lm1lbG5pa292QGlz b2RlLmNvbT4gd3JvdGU6DQoNCiAgICBEZWFyIENyeXB0byBQYW5lbCBtZW1iZXJzLA0KDQogICAg V2hlbiBDRlJHIGNoYWlycyBhbm5vdW5jZWQgdGhlIGN1cnJlbnQgQ3J5cHRvIFBhbmVsIG1lbWJl cnNoaXAgdGhlIA0KICAgIHN0YXRlZCB0ZXJtIGxlbmd0aCB3YXMgMiB5ZWFycyAoSmFudWFyeSAy MDIwLURlY2VtYmVyIDIwMjEpLiBXZSBhcmUgbm93IA0KICAgIG5lYXIgdGhlIGVuZCBvZiB0aGlz IHRlcm0sIHNvIENGUkcgY2hhaXJzIHdpbGwgYmUgc29vbiBhbm91bmNpbmcgYW5vdGhlciANCiAg ICByb3VuZCBvZiBhcHBsaWNhdGlvbnMgZm9yIHRoZSBmb2xsb3dpbmcgdHdvIHllYXJzLiBDaGFp cnMgYXJlIHZlcnkgDQogICAgcGxlYXNlZCB3aXRoIHdvcmsgZG9uZSBieSB0aGUgY3VycmVudCBD cnlwdG8gUGFuZWwgYW5kIHdvdWxkIGxpa2UgdG8gDQogICAgZW5jb3VyYWdlIGV4aXN0aW5nIG1l bWJlcnMgdG8gcmUtYXBwbHkuIChJZiBpbnN0ZWFkIHlvdSB3YW50IHRvIHN0ZXAgDQogICAgZG93 biwgcGxlYXNlIGFsc28gbGV0IHRoZSBjaGFpcnMga25vdyBieSBlbWFpbGluZyBjZnJnLWNoYWly c0BpZXRmLm9yZyANCiAgICBkaXJlY3RseS4pDQoNCiAgICBUaGFuayB5b3UsDQoNCiAgICBBbGV4 ZXksIG9uIGJlaGFsZiBvZiB0aGUgQ0ZSRyBDaGFpcnMNCg0KDQogICAgX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCiAgICBDcnlwdG8tcGFuZWwgbWFpbGlu ZyBsaXN0DQogICAgQ3J5cHRvLXBhbmVsQGlydGYub3JnDQogICAgaHR0cHM6Ly9nYnIwMS5zYWZl bGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNBJTJGJTJGd3d3LmlydGYu b3JnJTJGbWFpbG1hbiUyRmxpc3RpbmZvJTJGY3J5cHRvLXBhbmVsJmFtcDtkYXRhPTA0JTdDMDEl N0N0aG9tYXMucG9ybmluJTQwbmNjZ3JvdXAuY29tJTdDNzhmOTVhYjJiOGM4NGQwOGRjNGUwOGQ5 YTJkZmQ5YzAlN0NhNDExMTFiZTQ4NmI0NWY2OGJkMGVlMDFhNjJmMzY4ZSU3QzAlN0MwJTdDNjM3 NzE5OTA1MDM0NTA4Njg1JTdDVW5rbm93biU3Q1RXRnBiR1pzYjNkOGV5SldJam9pTUM0d0xqQXdN REFpTENKUUlqb2lWMmx1TXpJaUxDSkJUaUk2SWsxaGFXd2lMQ0pYVkNJNk1uMCUzRCU3QzIwMDAm YW1wO3NkYXRhPUZXSFFpN3pPOGhKb1hWYVpuTXdhRCUyQncyOU1ydUZwV2tlYmE3Unh1bmNvRSUz RCZhbXA7cmVzZXJ2ZWQ9MA0KDQo= From nobody Mon Nov 8 11:51:08 2021 Return-Path: X-Original-To: crypto-panel@ietfa.amsl.com Delivered-To: crypto-panel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA86F3A0FD3 for ; Mon, 8 Nov 2021 11:51:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=callas.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UXJ3BzHgFXdI for ; Mon, 8 Nov 2021 11:51:02 -0800 (PST) Received: from mail-pf1-x429.google.com (mail-pf1-x429.google.com [IPv6:2607:f8b0:4864:20::429]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D0E413A0FD1 for ; Mon, 8 Nov 2021 11:51:02 -0800 (PST) Received: by mail-pf1-x429.google.com with SMTP id y5so6784636pfb.4 for ; Mon, 08 Nov 2021 11:51:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=callas.org; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=mLNDmdoLKmqcCdI7xcX99ESXXO6n+zT3IffhDGhfgro=; b=b6d5ZODwqfw6JUP/xofR19FQtb/DuvnmMw8MjAnOQnfd+ol/bpl42yOnCMM68ngWPY +8Xc+HQfnVSI50fBQsD5oTaA3VoQX3WMIFiS88wRy613SDqhNjnpuzpYhdxJncqnA932 saj+eB4kssjymDRcjEBNGqQGd3YmBrEkDxkPRNXi1Q3vvEo7EU2Wi04xFWiDlR671HT0 qerPFWxsUPzQkKufgqEiqlpxiSfAWMHcRiPCwwYrpm00YMFzi9Tjy09X58AN1XF+pDPm Vb0ZOykgusvjjjuC5/wZ+K3R+QrL2sqtHIHuqmh0IEDbD9kYSyDomKFMUK1kZ2MYrLa8 A3VQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=mLNDmdoLKmqcCdI7xcX99ESXXO6n+zT3IffhDGhfgro=; b=EMHtXX8K8XwjkdMCvdF/Ez7snWzNyLDkG48/SCEIeypzvDL5mLLbZQcSWgW0mx0CuH wv89WDLKWDSuGEGXHRvwUs6tsRR8Yxa9h291F72DpvKvQtcscX0YL3+ntRwiUFjbSg6G aRCatURszE/kgSg4ugr9XvvKDFYSXZoVu7hkbgu2jvDwxJt7r/plmipJODE6kmJnqWA8 LI/17tumQPvvCor36KVbOm4uj3eIOKBo2pn+hgVQ2MrZndBOYq70DdX86nCe9pBD0Rxf 6XFVC6+Fr7zfPZXZoulyGnIfSh84Zom3FMA1ZVjwrsM/cS0f4CB+KnRhBQMkqNZnp4mv wozg== X-Gm-Message-State: AOAM531vibjAqHUYzWo4bvGMjhDOpPNbhnTcVq6GCiE4m7Qp91wZ8Paf 5IO/Oxec/4qjCb4StWpjSTddMg== X-Google-Smtp-Source: ABdhPJzZtARsSULhiDXyQKn6VSeYW4llA9MOi5PXhlFe1bMGMDcqlZJmJ2DCKPlFHGtOUU07b8tzuA== X-Received: by 2002:a63:86c1:: with SMTP id x184mr1515193pgd.114.1636401061598; Mon, 08 Nov 2021 11:51:01 -0800 (PST) Received: from smtpclient.apple ([2600:1700:38c4:12bf:7546:d053:e27c:548b]) by smtp.gmail.com with ESMTPSA id k13sm17583284pfc.197.2021.11.08.11.50.58 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 08 Nov 2021 11:50:59 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) From: Jon Callas In-Reply-To: Date: Mon, 8 Nov 2021 11:50:58 -0800 Cc: Jon Callas , crypto-panel@irtf.org, "cfrg-chairs@ietf.org" Content-Transfer-Encoding: 7bit Message-Id: <43FF21FA-0783-4081-93A7-33CC0FF9F472@callas.org> References: To: Alexey Melnikov X-Mailer: Apple Mail (2.3654.120.0.1.13) Archived-At: Subject: Re: [Crypto-panel] End of 2 year term for the Crypto Panel members X-BeenThere: crypto-panel@irtf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Nov 2021 19:51:08 -0000 Likewise I'm willing to continue. Jon From nobody Mon Nov 8 22:00:33 2021 Return-Path: X-Original-To: crypto-panel@ietfa.amsl.com Delivered-To: crypto-panel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B89903A0820 for ; Mon, 8 Nov 2021 22:00:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dowx8-ako13y for ; Mon, 8 Nov 2021 22:00:26 -0800 (PST) Received: from mail-wm1-x330.google.com (mail-wm1-x330.google.com [IPv6:2a00:1450:4864:20::330]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 280253A083F for ; Mon, 8 Nov 2021 22:00:26 -0800 (PST) Received: by mail-wm1-x330.google.com with SMTP id az33-20020a05600c602100b00333472fef04so258502wmb.5 for ; Mon, 08 Nov 2021 22:00:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=OTtNfbnizJ31L6J58SiLKQrsRzpnf1P8vng/gNuZh1E=; b=RALmn4nikS7LEAk5MeFdAuNJjdc4I29We6XGuj4AzupGfe/jwA5mzEo0DD9nDrnhAA OO+P7eslrbc1oNL328anQ2aT7S8LsdKhOF5JIgFCwFzLDrkyBIpZMCip2xJBLhovyRvn i9H1MjDCmpa/UeP68u9119Tt3nloGEDFCwHJikW8SQB0iZjJv5T8bCOKfylI/TRaLNc4 FiIjFL6CtCl+zQxbCquSv6EOaSCFiHFo4v/CBe3eJLU/dCr3GW+2OUoRyjHKv1OMspTc JUUiiiqnFi3YxnpkfgbDxhi7uVGb4fdkxZzLjSMcLIMVsoQDnmMA4kEsPcOBEG+0l766 XZSg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=OTtNfbnizJ31L6J58SiLKQrsRzpnf1P8vng/gNuZh1E=; b=bQg+WbHr2RZ5rkjCFv3BI7X3g1DomG6Cx9lt4CibMnNIi/EG9VN44X9wV6+uweIHBv GDnpkyYVyWW2VmDEY/UsNUoBh2ModlGRLcevLPBmgM3bqgo92VBjb1+QrUG1Fu5t2WOu Ud38abx1vQZeEN8QaMOupxvo0GFelnIYVSCoFEoAA518uRYbUNo2wDbBGXhJZZnTdWOe YvH8yicll1ItPPV9/LSOWBU3uyVzD7H/+nLi2dfbIf7zLBQORuUXFa63A7eHJAVjLxaM h6pa/ShYNfTySPOQUG2DLMPzEErlKnSyW41zoX990sWbpqIszIkC9l2S+tv0AaRlWugn cfBw== X-Gm-Message-State: AOAM531iccq6ZndM7fdK+7YlqBS2Hb3hYkCqa7cFgl/txomJuBex5A5m ykbtnKfbmAXZYM5I/wDfwKc= X-Google-Smtp-Source: ABdhPJyDnvhF1DS6CRmSOAKL+leJ2TQFe0h7RnwjDpsesfHUeuJp8qVurbSry/ajGf5DtOMIfksFbQ== X-Received: by 2002:a05:600c:19d1:: with SMTP id u17mr4443060wmq.148.1636437619589; Mon, 08 Nov 2021 22:00:19 -0800 (PST) Received: from smtpclient.apple (89-156-101-160.rev.numericable.fr. [89.156.101.160]) by smtp.gmail.com with ESMTPSA id o2sm19740966wrg.1.2021.11.08.22.00.18 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 08 Nov 2021 22:00:19 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 15.0 \(3693.20.0.1.32\)) From: Karthikeyan Bhargavan In-Reply-To: <43FF21FA-0783-4081-93A7-33CC0FF9F472@callas.org> Date: Tue, 9 Nov 2021 07:00:18 +0100 Cc: Alexey Melnikov , crypto-panel@irtf.org, "cfrg-chairs@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: <43FF21FA-0783-4081-93A7-33CC0FF9F472@callas.org> To: Jon Callas X-Mailer: Apple Mail (2.3693.20.0.1.32) Archived-At: Subject: Re: [Crypto-panel] End of 2 year term for the Crypto Panel members X-BeenThere: crypto-panel@irtf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Nov 2021 06:00:31 -0000 I=E2=80=99ll continue as well. > On 8 Nov 2021, at 20:50, Jon Callas wrote: >=20 > Likewise I'm willing to continue. >=20 > Jon >=20 > _______________________________________________ > Crypto-panel mailing list > Crypto-panel@irtf.org > https://www.irtf.org/mailman/listinfo/crypto-panel From nobody Tue Nov 9 01:59:51 2021 Return-Path: X-Original-To: crypto-panel@ietfa.amsl.com Delivered-To: crypto-panel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B51973A0D69 for ; Tue, 9 Nov 2021 01:59:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 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, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4XyJnNtAX3gu for ; Tue, 9 Nov 2021 01:59:45 -0800 (PST) Received: from mail-yb1-xb36.google.com (mail-yb1-xb36.google.com [IPv6:2607:f8b0:4864:20::b36]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5790A3A0D66 for ; Tue, 9 Nov 2021 01:59:45 -0800 (PST) Received: by mail-yb1-xb36.google.com with SMTP id v138so51466635ybb.8 for ; Tue, 09 Nov 2021 01:59:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=K6G+JkBg44t2rfhy4kdx+NmMOHccKil16CWzUSq/Qvs=; b=kRoXdL8o71CGFlfIEyxbj8pPqIUPCARYOn5zfcbmrMaVc+tfxd3MudW724gdMM4t8D XSZ8gAIClA2rbHk/45VbnyOt657UQua4QsFRP1sHnGLgmHw84JDXMK/ZoeD1+e/xiwA+ ptf2Hp0OTxtBTXIadHnGE8rtUfKoYCTcAk950lcbNpZsTaKGAe8hLLm5Nen+fUJSh+xP rmIHN/vH3yTPrYY7BInmfgckNX0Tnl9wUM7jjnBEJwKA/rrGoSddsqC0bacGuO3Mz/Zc wHN6EdBe8Nn14DF4+vZdifAOdPvILfsZJ5jS8AP5eCIT+mkZnZtO4/oIbVHav4LGMscO LGCQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=K6G+JkBg44t2rfhy4kdx+NmMOHccKil16CWzUSq/Qvs=; b=aH1wbyIxbEMVi+grPJg/hSYS4RwPMJwaoDzsIHSd8jwH2wedJr9Qfz7ZDjaPlpPnd+ zHk8b7Au4dzI/SoPyJHEY/l6gz0b/fOCWxnNSdv6eR54tnTETuuWDxAHWk4sPwdU4tpN khI8l2KJUNJOX3dK5OMpvnPrrFbHgagRUThVol6NYA7XbKndsohh949EE3tiDqzV08ti AyK3BjbGs1Pd52k6/f8rV7+1XDj6rHSNDgz+5j4xNJeZyK+56FBDhP1y5HFFMUZCH3q/ fbtyTUOtaeb/yLDW+3QHaGiU8gYJnvRQQm5JvoeLPrw4U0vOxjlxbaApwXOoHQCyZp6V 2kSw== X-Gm-Message-State: AOAM532vz20yRzkvCliryDecYhh+3LqBP77ylOyWFHJoqWMnigVgaaY4 yfXervLasvGSFdI7FI66CpcdHUp9R4mN2QwQk0X81eXN X-Google-Smtp-Source: ABdhPJwbEiXAIIUqT3dakyDZvigpBTH6jnob4/6J8F4yhHyIt4EGJu1zdWpa1VG/2+P2joIV+oztrOUh7eRn+p0vlg8= X-Received: by 2002:a25:a427:: with SMTP id f36mr6677681ybi.245.1636451981328; Tue, 09 Nov 2021 01:59:41 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Chloe Martindale Date: Tue, 9 Nov 2021 09:59:31 +0000 Message-ID: To: Alexey Melnikov Cc: crypto-panel@irtf.org, cfrg-chairs@ietf.org Content-Type: multipart/alternative; boundary="0000000000000a062105d0582b44" Archived-At: Subject: Re: [Crypto-panel] End of 2 year term for the Crypto Panel members X-BeenThere: crypto-panel@irtf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Nov 2021 09:59:50 -0000 --0000000000000a062105d0582b44 Content-Type: text/plain; charset="UTF-8" I'm also happy to continue. All the best, Chloe On Mon, 8 Nov 2021, 17:47 Alexey Melnikov, wrote: > Dear Crypto Panel members, > > When CFRG chairs announced the current Crypto Panel membership the > stated term length was 2 years (January 2020-December 2021). We are now > near the end of this term, so CFRG chairs will be soon anouncing another > round of applications for the following two years. Chairs are very > pleased with work done by the current Crypto Panel and would like to > encourage existing members to re-apply. (If instead you want to step > down, please also let the chairs know by emailing cfrg-chairs@ietf.org > directly.) > > Thank you, > > Alexey, on behalf of the CFRG Chairs > > > _______________________________________________ > Crypto-panel mailing list > Crypto-panel@irtf.org > https://www.irtf.org/mailman/listinfo/crypto-panel > --0000000000000a062105d0582b44 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I'm also happy to continue.=C2=A0
All=C2=A0the best,
Chloe

On Mon, 8 Nov 2021, 17:47 Alexey Melnikov, <alexey.melnikov@isode.com> wrote:
Dear Crypto Panel members,

When CFRG chairs announced the current Crypto Panel membership the
stated term length was 2 years (January 2020-December 2021). We are now near the end of this term, so CFRG chairs will be soon anouncing another round of applications for the following two years. Chairs are very
pleased with work done by the current Crypto Panel and would like to
encourage existing members to re-apply. (If instead you want to step
down, please also let the chairs know by emailing cfrg-chairs@ietf.org
directly.)

Thank you,

Alexey, on behalf of the CFRG Chairs


_______________________________________________
Crypto-panel mailing list
Crypto-panel@irtf.org
https://www.irtf.org/mailman/listinfo/c= rypto-panel
--0000000000000a062105d0582b44-- From nobody Fri Nov 12 05:28:22 2021 Return-Path: X-Original-To: crypto-panel@ietfa.amsl.com Delivered-To: crypto-panel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A93B53A095D for ; Fri, 12 Nov 2021 05:28:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.097 X-Spam-Level: X-Spam-Status: No, score=-1.097 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, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F3-qH1F3GcD4 for ; Fri, 12 Nov 2021 05:28:10 -0800 (PST) Received: from mail-wm1-x330.google.com (mail-wm1-x330.google.com [IPv6:2a00:1450:4864:20::330]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CFB6B3A0952 for ; Fri, 12 Nov 2021 05:28:09 -0800 (PST) Received: by mail-wm1-x330.google.com with SMTP id p3-20020a05600c1d8300b003334fab53afso6943889wms.3 for ; Fri, 12 Nov 2021 05:28:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=UwueKsmXILSRBCAc+xLCcQgp6E/u38heK65ShqzVWW0=; b=HURy2tvsjSRE5uunhF63l8c94qwTfoqWXI5rcVxqSnLDUJ+NHSm+7Pqp3iRsZpTME+ TqmmLY7xF5FE+n6CnHTWtbXRtM+kRROkhHIzjp62eHbNYLrr+U6ymxJYKoa+xbx7+fOW VQf3hGJDSaVVYBa7IYu4ILsERJDxVjj9TPEMMl+qQ6OyOBUK6KJkMBteeasPSkdJBbog NSItkMI/tuZb8uONBtutPGfo4ylrze1Ava2lh4uL9C6Kv3VbzlsQ+rzSzCv/qJBXSTFR 52QaJe3suoqp1fUiqS3b12i9bhHDisvmWcFUapGDfbnD1W2Q6AMIao8UG4RYDXmAsC2D HAig== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=UwueKsmXILSRBCAc+xLCcQgp6E/u38heK65ShqzVWW0=; b=D9KVd6lNDH8SgIkNANwwDtxg5dqhBx12gAvf6Bm//2EcZuZNidG5rkxHHjtxqtTGoK XtQdRyitPcUN2QUY2UVidEOI1opiYFBsHGZVPQN5EbD3JwX8FoenE10Ng0wTz7AF8KWB 2JD9YYn0oWs7THf0YbUQpLkSfYYRkPNeWiM7RizyeAbS5Xi/uPtyJW0xixZKR6XgqADe PJmc7IKOyaXEdDbvOdu6GY83hdGzX6ASi3mCCU71gC14Z26BbA0qDgt3F3g71fSut2uI AxixYEUXPGW3n6YL4goEaSwZz9Q4YesYfCW6maptl/7OSU3LwSdWISuxS5X9GBc513MB zacg== X-Gm-Message-State: AOAM530yziPM7A3hxBYg8G26Iv96R+mSKW69TlCMWElY0JSP4Ya3A9VI picOZVza7N0vHxW4BY3QAzFFLTLSGOw= X-Google-Smtp-Source: ABdhPJx1dAgyDRRXgQEszhqoAJMReBt1UHU5Ar1F8QgZ7siww2Ja+Pqn26hJQ/Yq6+krRUkukNVmtA== X-Received: by 2002:a05:600c:4e51:: with SMTP id e17mr12653930wmq.127.1636723682547; Fri, 12 Nov 2021 05:28:02 -0800 (PST) Received: from smtpclient.apple (89-156-101-160.rev.numericable.fr. [89.156.101.160]) by smtp.gmail.com with ESMTPSA id g5sm9035493wri.45.2021.11.12.05.28.01 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 12 Nov 2021 05:28:02 -0800 (PST) From: Karthikeyan Bhargavan Message-Id: <3B440D27-2490-4050-BDA0-4D0700FB8944@gmail.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_D459231E-CD05-49D7-8BC2-7280F427F68A" Mime-Version: 1.0 (Mac OS X Mail 15.0 \(3693.20.0.1.32\)) Date: Fri, 12 Nov 2021 14:28:00 +0100 In-Reply-To: Cc: Benjamin Smith To: crypto-panel@irtf.org, ek.ietf@gmail.com, sec-ads@ietf.org, draft-ietf-lwig-curve-representations.all@ietf.org, cfrg-chairs@ietf.org References: <5915C771-DCCF-4186-AD78-81A11A739160@gmail.com> <8B6AC27E-2483-4939-8813-9BC9F2F0C352@gmail.com> X-Mailer: Apple Mail (2.3693.20.0.1.32) Archived-At: Subject: Re: [Crypto-panel] Request for review: "Alternative Elliptic Curve Representations" X-BeenThere: crypto-panel@irtf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Nov 2021 13:28:21 -0000 --Apple-Mail=_D459231E-CD05-49D7-8BC2-7280F427F68A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hello All, Below is a detailed technical review of = draft-ietf-lwig-curve-representations-21 by Benjamin Smith (cc-ed). I discussed this review with Ben and agree with his concerns and it = would be great if the authors could address his questions. In particular, I feel the code reuse motivation needs to be better = justified. One way to do this would be to extend Implementation Considerations = (and/or Implementation Status) with concrete examples of code reuse in = Wei25519 implementations, quantified in lines of code, for example. If most of the code in these implementations is in the field arithmetic, = which can be reused between representations anyway, the argument for = this draft becomes less compelling. Best regards, Karthik =3D=3D=3D draft-ietf-lwig-curve-representations-21 =3D=3D=3D [Curve representations = draft](https://datatracker.ietf.org/doc/draft-ietf-lwig-curve-representati= ons/ = )= # Review by Benjamin Smith This draft specifies a series of new elliptic curves related to = Curve25519 and Curve448, and transformations between these new curves = and Curve25519/Curve448. The motivation is essentially code re-use: = legacy elliptic-curve software and hardware works with the classic = "short Weierstrass form", often with the a-coefficient set to -3, but in = more recent protocols and software we might work with Curve25519 and = Curve448 in either "Montgomery form" or "twisted Edwards form" = (depending on the protocol), for efficiency reasons. On the surface, = these equation forms are not the same, so the newer curves are = incompatible with legacy ECC code. This document bridges the gap by writing down isomorphisms to short = Weierstrass curves with a=3D-3 where such isomorphisms exist, and = isogenies (homomorphic maps) where isomorphisms do not exist. It also = specifies several other curves and maps, of various levels of = usefulness. I am not entirely convinced by the code re-use argument here. I agree = that this is an interesting goal, given the time and effort it takes to = develop and certify cryptographic software and especially hardware. But = for a concrete example, suppose we have an existing implementation = elliptic-curve scalar multiplication on NIST P256, and we want to use = this document to re-use that software for scalar multiplication on = Curve25519: 1. The curve group operations for P256 can be and reused, and so can the = scalar multiplication algorithm(s), insofar as they just call the curve = group operations. 2. The underlying field arithmetic implementation must be = rewritten/replaced, because these curves work modulo different primes. = Generally this isn't just a matter of changing a hard-coded value for = the prime p: the different primes have been chosen to allow completely = different optimized modular reduction algorithms. 3. The code to actually map points between the two curves must be added, = and in some cases this code will be particularly large. In particular, = the code here to convert from Curve25519 to Weierstrass with a=3D-3 = involves 9kb worth of data to define the isogeny (to say nothing of the = code to evaluate the isogeny). 4. The protocol may need to be tweaked to deal with the implicit = multiplication by the isogeny degree Comparing the small amount of code saved to the new code to be added, = and the possible modifications to the protocol: is this really worth it? = If you're going to have to add a whole new field arithmetic = implementation _and_ an extremely heavy isogeny-evaluation function = (specified by a massive collection of precomputed coefficients), then = maybe you would be better off just implementing Curve25519 properly. One might argue that the real benefit here would be for curve = implementations in hardware, where changing (and re-certifying) designs = is extremely slow, but I think that argument is defeated by the fact = that the finite field arithmetic (the lowest level) still has to be = rewritten. Ironically, herefore, this document could be read as a convincing = argument **against** code re-use. Of course, I might just be totally = missing the point. In that case, since I have read all 150 pages and = still missed the point, I think this means that the author hasn't fully = explained the point. The document is _extremely_ long, and often quite repetitive. There is = too much repetition of boilerplate text blocks for the various = transformations applied to different concrete instances. To give just = one example: Appendix M is essentially the same as Appendix E, but with = different curve parameters. There must be a way to minimise this = repetition (especially given the focus on code re-use!). More structural/editorial issues: - Appendix I (data conversions) must already be covered elsewhere: it = could probably be removed. - Appendices P, and Q are basically out of scope, and should be removed. - Appendix K is also essentially out of scope. - Appendix L can also be removed: it is a long and unneccessary = elaboration on a remark in Appendix K, and therefore out of scope. - Appendix N seems mostly superfluous: I don't understand why this = Edwards448 curve needs to be defined and named (we already have = Ed448...) Most of the technical content is uncontroversial, and it is mostly = correct (detailed technical comments follow). I am not competent to = evaluate Sections 10, 11, and 12, but I have checked the rest in detail. One key technical point: as mentioned above, the transfer between many = of the curves here requires an isogeny (a homomorphic map) rather than = an isomorphism (essentially a change of coordinates). One of the most = important isogenies here - the one from Curve25519 to Wei25519.-3 - has = degree 47. This means that specifying it involves, at a minimum, a = degree-23 polynomial w(x). This polynomial w(x) is dense, so we need to = specify (and store) 23x 32-byte coefficients. This obviously requires a = lot of space! I say "at a minimum", because two more polynomials, u(x) = and v(x), of similar degree, are required. Mathematically they can be = derived from w(x), but for algorithmic simplicity it may be more = convenient to specify them in their expanded form, as is done here. = Then, the "dual" map from Wei25519.-3 back to Curve25519 has its own = large u, v, and w. Ultimately, this means a *lot* of space: 9kB of = memory in code, and 12+ pages of this document. Reducing this size (and evaluation time) is important if this is to be = made practical. I have checked, and I agree with the author that there = is no isogeny of *prime* degree less than 47 from Curve25519 to a = short-Weierstrass curve with a=3D-3. However, there *is* such an = isogeny of composite degree 46 (I could not find any lower-degree = composite isogenies that do the job). This doesn't look like much of an = improvement on the surface, but the degree-46 isogeny is the composite = of a degree-2 isogeny (very easy to specify/compute) and a degree-23 = isogeny (roughly half the coefficients and complexity compared with the = 47-isogeny). This means that by changing the definition of Wei25519.-3 = to be the codomain of the 46-isogeny instead of the 47-isogeny, the time = and space required to encode and compute the isogeny will be literally = cut in half. Of course, half of 9kB is still quite expensive, and it = remains to be seen if anyone will consider this practical for = applications, but I think it is still an improvement that the author = might want to consider using. ## Technical remarks - "unequal to" should generally be replaced with "not equal to" - most instances of "hereof" should be "thereof", though something less = archaic than "(t)hereof" would be even better ### 1 Fostering Code Reuse with New Elliptic Curves - `we specify these curves` should probably be a bit more specific: "we = specify the CFRG curves"? ### 4 Examples - In 4.1: `Moreover, with X25519, private keys are generated in the = interval [2^251,2^252-1] rather than in the interval [1,n-1] (the = so-called "clamping") and one uses as base point G':=3Dh*G, where G, n, = and h are, respectively, the fixed base point, the order of the base = point, and the co-factor of the curve in question`: I think this is = wrong. The private keyspace for X25519 is $S =3D \{2^{254} + 8k : k \in = [0,2^{251}-1]\}$. If you use the keyspace defined here and multiply by = the cofactor 8 then this gives the same thing, but that's not how X25519 = is specified: clamping produces an element of $S$, and there is no = explicit cofactor multiplication. We should double-check the = equivalence of these schemes. - In 4.2: `One can implement the computation of the ephemeral key pair = for Ed25519 using an existing Montgomery curve implementation by (1) = generating a public-private key pair (k, R':=3Dk*G') for Curve25519;(2) = representing this public-private key as the pair (k, R:=3Dk*G) for = Ed25519.` This is confusing, because $G$ and $G'$ are not the same = point. There's also this explicit-vs-implicit question for Curve25519 = key pairs. Finally, "*key pair* for Curve25519" makes me think of = Curve25519 the protocol, rather than Curve25519 the curve, and in the = protocol the public key is only an x-coordinate. ### 5 Caveats - In 5.1: the u-coordinate-only compression of RFC7748 (X25519) is not = "lossy" (the dropped v-coordinate was never part of the protocol or = keys), unless "lossy" means that it maps the point at infinity and (0,0) = to the same value, 0. - In 5.3: "NOTE 1" is interesting, but also kind of pointless in this = kind document. - In 5.3: "NOTE 2" makes me wonder how all these isogenies were = found/computed. It might be worth noting that this 2-isogeny does not = preserve the endomorphism ring: you move one level up to the "crater" of = the 2-volcano with this isogeny. On a more basic level, the curves = don't have the same abelian group structure: the twist of Curve25519 has = a cyclic group, while the 2-isogenous curve has non-cyclic 2-torsion. = This is not an issue with the 47-isogeny from Curve25519, which = restricts to an isomorphism on groups of rational points. ### 6 Implementation considerations Clarification: `All NIST curves [FIPS-186-4] and Brainpool curves = [RFC5639] are Weierstrass curves with a=3D-3 domain parameter, thus = facilitating more efficient elliptic curve group operations (via = so-called Jacobian coordinates).` - this "more efficient" is w.r.t. = general short Weierstrass curves with a !=3D -3. ### 8 Security considerations - `...which is either an isomorphism of a low-degree isogeny`: 47 isn't = that low (well, not unless you're a CSIDH implementer)! - `the complexity of cryptographic problems (such as the discrete = logarithm problem) of curves related via a low-degree isogeny are = tightly related. Thus, the use of these techniques does not negatively = impact cryptogaphic security of elliptic curve operations.`: this can be = made more precise. The 47-isogeny is an isomorphism on the level of = groups of points (because 47 is coprime to the group order), and since = the groups are isomorphic their DLPs have equivalent difficulty. (The = 2-isogeny from the twist restricts to an isomorphism of the prime-order = subgroups, which is where all the DLP difficulty comes from in that = case, so similarly the DLPs have equivalent difficulty.) - `the use of these techniques does not negatively impact cryptogaphic = security of elliptic curve operations`: this might be true in the sense = of DLP operations, but the existence of an isomorphism doesn't mean that = things like side-channel safety extends from a Curve25519 implementation = to a Wei25519 implementation. So maybe "security of elliptic curve = operations" should be changed to something like "security of the = underlying elliptic curve discrete logarithms"? ### 14 References `[Wei-Ladder]` was published in PKC 2002, and there's no reason to cite = a preprint instead here instead of the definitive version. This = reference can be updated to: Tetsuya Izu and Tsuyoshi Takagi, "A Fast = Parallel Elliptic Curve Multiplication Resistant Against Side Channel = Attacks", PKC 2002, Lecture Notes in Computer Science Vol. 2274, = Springer-Verlag, 2002. ### Appendix B I'm not really sure why this is separate from Appendix A. - In B.1: The notation `(P)` for the subgroup generated by P is = nonstandard and has a fair potential for confusion; `

` would be more = typical. - In B.1: `The order of curve E` should be "The order of *a* curve E" - In B.1: `All curves of prime order are cyclic`: more generally, if the = order is not divisible by a square > 1 then the group is cyclic. - In B.1: `if h*P =3D O (and is a high-order point otherwise); this = point has order n` is slightly ambiguous: `the point P has order n` = would be a little clearer. - In B.1: `Random points R of (P), where P has order l, ... computing = R:=3Dk*P, where R has rder l/gcd(k,l)`: this "where" sounds like a = restriction on R, rather than a corollary. Something like `computing = R:=3Dk*P. The point R has order l/gcd(k,l)` would be clearer. - In B.1: `unless k is a multipl of n`: this `n` should be an `l`, but = then `k` cannot be a multiple of `l` unless it is zero (because it was = sampled from [0,l-1]). - In B.1: `If P is a fixed base point G of the curve...`: P is never = used again in this paragraph (or indeed, in the rest of this appendix), = so its appearance here is confusing. Maybe this could be rephrased = purely in terms of G? - In B.1: `If this representation is nonzero, R has order n`: this is = only true for `n` prime. - In B.1: `...|E| relatively close to q, where, in fact, |E|=3Dq+1-t`: = this "where" is grammatically confusing. `...|E| relatively close to q. = In fact, |E|=3Dq+1-t` would be clearer. - In B.1: `Points that are both points of E and E'` should be "Points = that are points of both E an E'", which sounds funny because of the = "Points that are points"; maybe `Points that are simultaneously in E and = in E'` would be better? - In B.1: `Two curves E and E'... are said to be isomorphic if these = have the same group structure`: **this is wrong**. They are isomorphic = if there exists an isomorphism *of elliptic curves*, not a group = isomorphism. For example, if q is fixed and large, and n is a prime in = the Hasse interval close to q, then there are O(\sqrt{q}) non-isomorphic = curves of order n, all with groups of points isomorphic to Z/nZ. These = curves are all isogenous, but they are generally connected by isogenies = of extremely large degree, which cannot be computed efficiently - so the = DLP in these curves is not necessarily equivalent, in the sense that the = DLP in one curve cannot necessarily be mapped into another in polynomial = time. There is certainly no algebraic isomorphism between the curves; = generally, mapping points homomorphically from one group into another = means solving DLPs! So even though the groups are isomorphic, I think = it is wrong (and seriously misleading) to say that these curves are = isomorphic. - In B.2: `where g^0 is the identity element 1 of GF(q)`: 1 is the = multiplicative identity element (0 is the additive identity element). = It might be clearer to just say "the multiplicative identity element 1 = of GF(q)", or even simpler "the element 1 of GF(q)". - In B.2: `the set GF(q)\{0} is cyclic`: this should be `the set = GF(q)\{0}` forms a cyclic group (a set cannot be cyclic). - In B.2: `computing square roots and inverses in GF(q) - if these = exist`: inverses always exist (except for 0). I think the "if these = exist" qualifier belongs with the square roots instead. - In B.2: `Readers not interested in this, could simply view...`: remove = the comma. ### Appendix C - In C.1: `For each point P of the Weierstrass curve W_{a,b}, the point = at infinity O serves as identity element`: the identity element is = always defined for the group, not w.r.t. each element P. This would be = clearer as `On the Weierstrass curve W_{a,b}, the point at infinity = serves as identity element`. - In C.1: `One has P + (-P) =3D O`: this is an example of somewhere = where the notation `(P)` for the subgroup generated by P causes a bad = ambiguity. - In C.1: `...let Q:=3DP1 + P2, where Q is not the identity element. = Then Q:=3D(X, Y)`: Q is being defined in `Q:=3DP1 + P2`, so you can't = restrict it in this way, and then the second definition `Q:=3D(X, Y)` is = tautological. Maybe this would be clearer as `...let Q:=3D P1 + P2. If = X1 =3D X2 and Y1 =3D -Y2, then Q is the identity element. Otherwise, Q =3D= (X,Y), where...` - In C.2: Exactly the same comments apply here as for C.1/short = Weierstrass curves. - In C.3: Same comments here as for C.1/short Weierstrass curves. ### Appendix D - In D.1: `while mapping each other point (u,v) of M_{A,B} to the point = (x,y):=3D(u/v,(u-1)/(u+1)) of E_{a,d}`: what about the two points of = order two on M_{A,B} not equal to (0,0) (i.e., the points where v =3D 0 = but u !=3D 0)? The image is not defined. This situation may be = covered/prohibited by the Note on twisted Edwards curves, but no such = condition was imposed on the Montgomery curves here... - In D.2: `Note that not all Weierstrass curves can be injectively = mapped to Montgomery curves`: I don't think the "injectively" makes any = sense here. Some Weierstrass curves cannot be transformed into = Montgomery form in any way. Also note that having a point of order 2 is = necessary *but not sufficient* for the existence of a Montgomery model. ### Appendix E - In E.2: `as a shift of (p+A)/3 for the isomorphic mapping and -(p+A)/3 = for its inverse, where delta=3D(p+A)/3 is...`: this should probably be = `as a shift of delta for the isomorphic mapping and -delta for its = inverse, where delta:=3D(p+A)/3 is...` ### Appendix H - `Point decompression... where one tries and recover` should be `where = one tries to recover` - `from its compressed representation and information on the domain = parameters of the curve`:=20 ### Appendix J It would be good if the base points on the various curves were mapped = onto each other by the isomorphisms/isogenies defined above; this is = probably the case, but it should still be mentioned explicitly here.=20 ### Appendix K - I'm really not convinced that this is necessary: it's long, it's = repetitive, it's of marginal interest, and it doesn't fit with the = code-reuse/mapping theme of the main document (except for the mapping = into the twisted Edwards curve). These maps are not operations of = primary interest, so this appendix amounts to 11 highly technical pages = worth of bloat. I really don't understand the motivation for including = this in this document.=20 - In K.2: It would be worth mentioning that the "Fermat" inversion 1/y =3D= y^{q-2} in GF(q) works also for q =3D p prime, and that it is easier to = implement in constant-time (where this is relevant/required). - In K.4.1: `If t is an element of GF(q) that is not a square... yields = an affine point P(t)... Let P0:=3D(X0,Y0) be a fixed affine point of = W_{a,b} for which neither P0, P0 + P(t), not P0 - P(t) is in the small = subgroup`: it should be made clear that this property is supposed to = hold *for all nonsquare t*. - In K.4.2: Same remark as above for K.4.1 ### Appendix L `This section illustrates how isogenies can be used to yield curves with = specific properties (here, illustrated for the "BitCoin" curve = secp256k1).` What are these specific properties in this instance? The = new curve secp256k1.m is not in Montgomery form, does not have a =3D -3 = or -1, does not have particularly nice coefficients... We have to go = back to NOTE 2 of Appendix K to find out that the objective here is just = to map from secp256k1 to a Weierstrass curve with nonzero a and b = coefficients. This can only be achieved with an isogeny, not an = isomorphism, but then why not transform into one of these more "useful" = restricted-short-Weierstrass models (e.g. a =3D 1 or a =3D -3)? That = would be more coherent with the "code re-use" motivation of the = document. If all you want is nonzero coefficients then virtually any = rational isogeny would do the job, and that reduces this entire appendix = to an extra sentence in NOTE 2 of Appendix K. ### Appendix M - In M.1: `with as base point the point (Gx, Gy)` should be `with base = point (Gx, Gy)`. - Same for the `with as base point the point (GX, GY)`. - In M.2: Same "delta" comment as for E.2. ### Appendix N What is the point of Edwards448? Is this just some intermediate curve? = Does this curve really need to be named and specified? > On 12 Nov 2021, at 08:42, Stanislav V. Smyshlyaev > wrote: >=20 > Thanks, we'll be looking forward to it. >=20 > Regards, > Stanislav >=20 > On Fri, 12 Nov 2021 at 10:35, Karthikeyan Bhargavan = > = wrote: > Sorry about this, am pushing my colleague and we=E2=80=99ll get it = done. >=20 >> On 12 Nov 2021, at 07:35, Stanislav V. Smyshlyaev > wrote: >>=20 >> Hi Karthik, >>=20 >> >> We=E2=80=99ll send our review early next week. >> The authors keep asking me about the review - could you please finish = it today (it is already later than "early this week" :) )?.. >>=20 >> Regards, >> Stanislav >>=20 >> On Sat, 6 Nov 2021 at 01:55, Stanislav V. Smyshlyaev = > wrote: >> Thank you, Karthik! >>=20 >> Regards, >> Stanislav=20 >>=20 >> On Sat, 6 Nov 2021 at 00:33, Karthikeyan Bhargavan = > = wrote: >> Hi Stanislav, >>=20 >> My colleague and I dropped the ball on this, but have made progress = this week. >> We=E2=80=99ll send our review early next week. >>=20 >> -Karthik >>=20 >>> On 5 Nov 2021, at 19:27, Stanislav V. Smyshlyaev > wrote: >>>=20 >>> (CC=E2=80=99ing the second Karthik=E2=80=99s address that I am aware = of.) >>>=20 >>> Karthik, please let me know about the status of your review. The = authors have already asked us about the status of their review today, so = my question to you yesterday was reasonable.=20 >>>=20 >>> Regards,=20 >>> Stanislav=20 >>>=20 >>> On Thu, 4 Nov 2021 at 20:50, Stanislav V. Smyshlyaev = > wrote: >>> Dear Karthik, >>>=20 >>> I may be missing something here, but could you please remind me = whether you had sent a review for that document?.. >>>=20 >>> Regards, >>> Stanislav=20 >>>=20 >>> On Wed, 11 Aug 2021 at 17:01, Stanislav V. Smyshlyaev = > wrote: >>> In my opinion, it will be absolutely fine, taking the size of the = document into account. >>>=20 >>> Thank you, Karthik! >>>=20 >>> Regards, >>> Stanislav (on behalf of the CFRG Chairs) >>>=20 >>> On Wed, 11 Aug 2021 at 16:58, Karthikeyan Bhargavan = > = wrote: >>> Is 1 month too long a wait? >>>=20 >>>> On 11 Aug 2021, at 09:52, Stanislav V. Smyshlyaev = > wrote: >>>>=20 >>>> Great, thanks! >>>>=20 >>>> How much time will you need for this (taking 146 pages into = account)=20 >>>> I would like to send a message to the authors (CC'ing crypto-panel = mailing list). >>>>=20 >>>> Regards, >>>> Stanislav >>>>=20 >>>> On Wed, 11 Aug 2021 at 16:43, Karthikeyan Bhargavan = > = wrote: >>>> Sure, I got a request on another thread a well and can do this = (with help from some colleaugues.) >>>>=20 >>>> -K. >>>>=20 >>>>> On 11 Aug 2021, at 09:39, Stanislav V. Smyshlyaev = > wrote: >>>>>=20 >>>>> Karthik, >>>>>=20 >>>>> Can you do a review of this document (as a Crypto Review Panel = member)? >>>>>=20 >>>>> Regards, >>>>> Stanislav >>>>>=20 >>>>> On Fri, 6 Aug 2021 at 12:46, Stanislav V. Smyshlyaev = > wrote: >>>>> Dear Karthik, >>>>>=20 >>>>> Nick, Alexey and I have had some discussion about reviewing the = "Alternative Elliptic Curve Representations" draft, = draft-ietf-lwig-curve-representations-21, = https://datatracker.ietf.org/doc/draft-ietf-lwig-curve-representations/ = = - may we ask you to do the review (on behalf of the Crypto Panel)? >>>>>=20 >>>>> Regards, >>>>> Stanislav >>>>>=20 >>>>> On Fri, 16 Jul 2021 at 11:50, Stanislav V. Smyshlyaev = > wrote: >>>>> Dear Crypto Panel Experts,=20 >>>>>=20 >>>>> We've obtained a request for review of the version -21 of the = "Alternative Elliptic Curve Representations" draft, = draft-ietf-lwig-curve-representations-21, = https://datatracker.ietf.org/doc/draft-ietf-lwig-curve-representations/ = >>>>>=20 >>>>> The Crypto Panel (that was my review back then) provided a review = of the -00 version three years ago: >>>>> = https://mailarchive.ietf.org/arch/msg/crypto-panel/1itH0lM9w0bZiADJXQkizr8= JTiA/ = >>>>>=20 >>>>> The document has changed significantly since then, so the authors = ask for a new review.=20 >>>>>=20 >>>>> The chairs would like to ask the Crypto Panel to provide a review = (another pair of eyes + reviewing all the changes in the document). >>>>>=20 >>>>> Any volunteers? >>>>>=20 >>>>> Regards, >>>>> Stanislav (for CFRG Chairs) >>>>=20 >>>=20 >>=20 >=20 --Apple-Mail=_D459231E-CD05-49D7-8BC2-7280F427F68A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

Hello All,

Below is = a detailed technical review of draft-ietf-lwig-curve-representations-21 by Benjamin Smith = (cc-ed).

I discussed this review = with Ben and agree with his concerns and it would be great if the = authors could address his questions.

In particular, I feel the code reuse = motivation needs to be better justified.
One way to = do this would be to extend Implementation Considerations (and/or = Implementation Status) with concrete examples of code reuse in Wei25519 = implementations, quantified in lines of code, for example.
If most of the code in these implementations is in the field = arithmetic, which can be reused between representations anyway, the = argument for this draft becomes less compelling.

Best regards,
Karthik

=3D=3D=3D
draft-ietf-lwig-curve-representations-21
=3D=3D=3D

[Curve representations draft](https://datatracker.ietf.org/doc/draft-ietf-lwig-curve-represen= tations/)

# = Review by Benjamin Smith

This draft specifies a series of new elliptic curves related = to Curve25519 and Curve448, and transformations between these new curves = and Curve25519/Curve448.  The motivation is essentially code = re-use: legacy elliptic-curve software and hardware works with the = classic "short Weierstrass form", often with the a-coefficient set to = -3, but in more recent protocols and software we might work with = Curve25519 and Curve448 in either "Montgomery form" or "twisted Edwards = form" (depending on the protocol), for efficiency reasons.  On the = surface, these equation forms are not the same, so the newer curves are = incompatible with legacy ECC code.

This document bridges the gap by = writing down isomorphisms to short Weierstrass curves with a=3D-3 where = such isomorphisms exist, and isogenies (homomorphic maps) where = isomorphisms do not exist.  It also specifies several other curves = and maps, of various levels of usefulness.

I am not entirely convinced by the code = re-use argument here.  I agree that this is an interesting goal, = given the time and effort it takes to develop and certify cryptographic = software and especially hardware.  But for a concrete example, = suppose we have an existing implementation elliptic-curve scalar = multiplication on NIST P256, and we want to use this document to re-use = that software for scalar multiplication on Curve25519:

1. The curve group = operations for P256 can be and reused, and so can the scalar = multiplication algorithm(s), insofar as they just call the curve group = operations.
2. The underlying field arithmetic = implementation must be rewritten/replaced, because these curves work = modulo different primes.  Generally this isn't just a matter of = changing a hard-coded value for the prime p: the different primes have = been chosen to allow completely different optimized modular reduction = algorithms.
3. The code to actually map points = between the two curves must be added, and in some cases this code will = be particularly large.  In particular, the code here to convert = from Curve25519 to Weierstrass with a=3D-3 involves 9kb worth of data to = define the isogeny (to say nothing of the code to evaluate the = isogeny).
4. The protocol may need to be tweaked to = deal with the implicit multiplication by the isogeny degree

Comparing the small = amount of code saved to the new code to be added, and the possible = modifications to the protocol: is this really worth it?  If you're = going to have to add a whole new field arithmetic implementation _and_ = an extremely heavy isogeny-evaluation function (specified by a massive = collection of precomputed coefficients), then maybe you would be better = off just implementing Curve25519 properly.

One might argue that the real benefit = here would be for curve implementations in hardware, where changing (and = re-certifying) designs is extremely slow, but I think that argument is = defeated by the fact that the finite field arithmetic (the lowest level) = still has to be rewritten.

Ironically, herefore, this document could be read as a = convincing argument **against** code re-use.  Of course, I might = just be totally missing the point. In that case, since I have read all = 150 pages and still missed the point, I think this means that the author = hasn't fully explained the point.

The document is _extremely_ long, and = often quite repetitive.  There is too much repetition of = boilerplate text blocks for the various transformations applied to = different concrete instances.  To give just one example: Appendix M = is essentially the same as Appendix E, but with different curve = parameters.  There must be a way to minimise this repetition = (especially given the focus on code re-use!).

More structural/editorial = issues:

- = Appendix I (data conversions) must already be covered elsewhere: it = could probably be removed.
- Appendices P, and Q = are basically out of scope, and should be removed.
- = Appendix K is also essentially out of scope.
- = Appendix L can also be removed: it is a long and unneccessary = elaboration on a remark in Appendix K, and therefore out of = scope.
- Appendix N seems mostly superfluous: I = don't understand why this Edwards448 curve needs to be defined and named = (we already have Ed448...)

Most of the technical content is uncontroversial, and it is = mostly correct (detailed technical comments follow).  I am not = competent to evaluate Sections 10, 11, and 12, but I have checked the = rest in detail.

One key technical point: as mentioned above, the transfer = between many of the curves here requires an isogeny (a homomorphic map) = rather than an isomorphism (essentially a change of coordinates). =  One of the most important isogenies here - the one from Curve25519 = to Wei25519.-3 - has degree 47.  This means that specifying it = involves, at a minimum, a degree-23 polynomial w(x).  This = polynomial w(x) is dense, so we need to specify (and store) 23x 32-byte = coefficients.  This obviously requires a lot of space!  I say = "at a minimum", because two more polynomials, u(x) and v(x), of similar = degree, are required. Mathematically they can be derived from w(x), but = for algorithmic simplicity it may be more convenient to specify them in = their expanded form, as is done here.  Then, the "dual" map from = Wei25519.-3 back to Curve25519 has its own large u, v, and w. =  Ultimately, this means a *lot* of space: 9kB of memory in code, = and 12+ pages of this document.

Reducing this size (and evaluation = time) is important if this is to be made practical.  I have = checked, and I agree with the author that there is no isogeny of *prime* = degree less than 47 from Curve25519 to a short-Weierstrass curve with = a=3D-3.  However, there *is* such an isogeny of composite degree 46 = (I could not find any lower-degree composite isogenies that do the job). =  This doesn't look like much of an improvement on the surface, but = the degree-46 isogeny is the composite of a degree-2 isogeny (very easy = to specify/compute) and a degree-23 isogeny (roughly half the = coefficients and complexity compared with the 47-isogeny).  This = means that by changing the definition of Wei25519.-3 to be the codomain = of the 46-isogeny instead of the 47-isogeny, the time and space required = to encode and compute the isogeny will be literally cut in half. =  Of course, half of 9kB is still quite expensive, and it remains to = be seen if anyone will consider this practical for applications, but I = think it is still an improvement that the author might want to consider = using.

## = Technical remarks

- "unequal to" should generally be replaced with "not equal = to"
- most instances of "hereof" should be = "thereof", though something less archaic than "(t)hereof" would be even = better

### 1 = Fostering Code Reuse with New Elliptic Curves

- `we specify these curves` should = probably be a bit more specific: "we specify the CFRG curves"?

### 4 Examples

- In 4.1: `Moreover, = with X25519, private keys are generated in the interval [2^251,2^252-1] = rather than in the interval [1,n-1] (the so-called "clamping") and one = uses as base point G':=3Dh*G, where G, n, and h are, respectively, the = fixed base point, the order of the base point, and the co-factor of the = curve in question`: I think this is wrong.  The private keyspace = for X25519 is $S =3D \{2^{254} + 8k : k \in [0,2^{251}-1]\}$.  If = you use the keyspace defined here and multiply by the cofactor 8 then = this gives the same thing, but that's not how X25519 is specified: = clamping produces an element of $S$, and there is no explicit cofactor = multiplication.  We should double-check the equivalence of these = schemes.
- In 4.2: `One can implement the = computation of the ephemeral key pair for Ed25519 using an existing = Montgomery curve implementation by (1) generating a public-private key = pair (k, R':=3Dk*G') for Curve25519;(2) representing this public-private = key as the pair (k, R:=3Dk*G) for Ed25519.`  This is confusing, = because $G$ and $G'$ are not the same point.  There's also this = explicit-vs-implicit question for Curve25519 key pairs.  Finally, = "*key pair* for Curve25519" makes me think of Curve25519 the protocol, = rather than Curve25519 the curve, and in the protocol the public key is = only an x-coordinate.

### 5 Caveats

- In 5.1: the u-coordinate-only compression of RFC7748 = (X25519) is not "lossy" (the dropped v-coordinate was never part of the = protocol or keys), unless "lossy" means that it maps the point at = infinity and (0,0) to the same value, 0.
- In 5.3: = "NOTE 1" is interesting, but also kind of pointless in this kind = document.
- In 5.3: "NOTE 2" makes me wonder how = all these isogenies were found/computed.  It might be worth noting = that this 2-isogeny does not preserve the endomorphism ring: you move = one level up to the "crater" of the 2-volcano with this isogeny. =  On a more basic level, the curves don't have the same abelian = group structure: the twist of Curve25519 has a cyclic group, while the = 2-isogenous curve has non-cyclic 2-torsion.  This is not an issue = with the 47-isogeny from Curve25519, which restricts to an isomorphism = on groups of rational points.

### 6 Implementation = considerations

Clarification: `All NIST curves [FIPS-186-4] and Brainpool = curves [RFC5639] are Weierstrass curves with a=3D-3 domain parameter, = thus facilitating more efficient elliptic curve group operations (via = so-called Jacobian coordinates).` - this "more efficient" is w.r.t. = general short Weierstrass curves with a !=3D -3.

### 8 Security considerations

- `...which is either an = isomorphism of a low-degree isogeny`: 47 isn't that low (well, not = unless you're a CSIDH implementer)!
- `the = complexity of cryptographic problems (such as the discrete logarithm = problem) of curves related via a low-degree isogeny are tightly related. =  Thus, the use of these techniques does not negatively impact = cryptogaphic security of elliptic curve operations.`: this can be made = more precise.  The 47-isogeny is an isomorphism on the level of = groups of points (because 47 is coprime to the group order), and since = the groups are isomorphic their DLPs have equivalent difficulty. =  (The 2-isogeny from the twist restricts to an isomorphism of the = prime-order subgroups, which is where all the DLP difficulty comes from = in that case, so similarly the DLPs have equivalent = difficulty.)
- `the use of these techniques does = not negatively impact cryptogaphic security of elliptic curve = operations`: this might be true in the sense of DLP operations, but the = existence of an isomorphism doesn't mean that things like side-channel = safety extends from a Curve25519 implementation to a Wei25519 = implementation.  So maybe "security of elliptic curve operations" = should be changed to something like "security of the underlying elliptic = curve discrete logarithms"?

### 14 References

`[Wei-Ladder]` was published in PKC = 2002, and there's no reason to cite a preprint instead here instead of = the definitive version.  This reference can be updated to: Tetsuya = Izu and Tsuyoshi Takagi, "A Fast Parallel Elliptic Curve Multiplication = Resistant Against Side Channel Attacks", PKC 2002, Lecture Notes in = Computer Science Vol. 2274, Springer-Verlag, 2002.

### Appendix B

I'm not really sure why = this is separate from Appendix A.

- In B.1: The notation `(P)` for the = subgroup generated by P is nonstandard and has a fair potential for = confusion; `<P>` would be more typical.
- In = B.1: `The order of curve E` should be "The order of *a* curve = E"
- In B.1: `All curves of prime order are = cyclic`: more generally, if the order is not divisible by a square > = 1 then the group is cyclic.
- In B.1: `if h*P =3D O = (and is a high-order point otherwise); this point has order n` is = slightly ambiguous: `the point P has order n` would be a little = clearer.
- In B.1: `Random points R of (P), where P = has order l, ... computing R:=3Dk*P, where R has rder l/gcd(k,l)`: this = "where" sounds like a restriction on R, rather than a corollary. =  Something like `computing R:=3Dk*P. The point R has order = l/gcd(k,l)` would be clearer.
- In B.1: `unless k = is a multipl of n`: this `n` should be an `l`, but then `k` cannot be a = multiple of `l` unless it is zero (because it was sampled from = [0,l-1]).
- In B.1: `If P is a fixed base point G = of the curve...`: P is never used again in this paragraph (or indeed, in = the rest of this appendix), so its appearance here is confusing. Maybe = this could be rephrased purely in terms of G?
- In = B.1: `If this representation is nonzero, R has order n`: this is only = true for `n` prime.
- In B.1: `...|E| relatively = close to q, where, in fact, |E|=3Dq+1-t`: this "where" is grammatically = confusing.  `...|E| relatively close to q. In fact, |E|=3Dq+1-t` = would be clearer.
- In B.1: `Points that are both = points of E and E'` should be "Points that are points of both E an E'", = which sounds funny because of the "Points that are points"; maybe = `Points that are simultaneously in E and in E'` would be = better?
- In B.1: `Two curves E and E'... are said = to be isomorphic if these have the same group structure`: **this is = wrong**.  They are isomorphic if there exists an isomorphism *of = elliptic curves*, not a group isomorphism.  For example, if q is = fixed and large, and n is a prime in the Hasse interval close to q, then = there are O(\sqrt{q}) non-isomorphic curves of order n, all with groups = of points isomorphic to Z/nZ.  These curves are all isogenous, but = they are generally connected by isogenies of extremely large degree, = which cannot be computed efficiently - so the DLP in these curves is not = necessarily equivalent, in the sense that the DLP in one curve cannot = necessarily be mapped into another in polynomial time.  There is = certainly no algebraic isomorphism between the curves; generally, = mapping points homomorphically from one group into another means solving = DLPs!  So even though the groups are isomorphic, I think it is = wrong (and seriously misleading) to say that these curves are = isomorphic.
- In B.2: `where g^0 is the identity = element 1 of GF(q)`: 1 is the multiplicative identity element (0 is the = additive identity element).  It might be clearer to just say "the = multiplicative identity element 1 of GF(q)", or even simpler "the = element 1 of GF(q)".
- In B.2: `the set GF(q)\{0} = is cyclic`: this should be `the set GF(q)\{0}` forms a cyclic group (a = set cannot be cyclic).
- In B.2: `computing square = roots and inverses in GF(q) - if these exist`: inverses always exist = (except for 0).  I think the "if these exist" qualifier belongs = with the square roots instead.
- In B.2: `Readers = not interested in this, could simply view...`: remove the = comma.

### = Appendix C

- = In C.1: `For each point P of the Weierstrass curve W_{a,b}, the point at = infinity O serves as identity element`: the identity element is always = defined for the group, not w.r.t. each element P.  This would be = clearer as `On the Weierstrass curve W_{a,b}, the point at infinity = serves as identity element`.
- In C.1: `One has P + = (-P) =3D O`: this is an example of somewhere where the notation `(P)` = for the subgroup generated by P causes a bad ambiguity.
- In C.1: `...let Q:=3DP1 + P2, where Q is not the identity = element.  Then Q:=3D(X, Y)`: Q is being defined in `Q:=3DP1 + P2`, = so you can't restrict it in this way, and then the second definition = `Q:=3D(X, Y)` is tautological.  Maybe this would be clearer as = `...let Q:=3D P1 + P2.  If X1 =3D X2 and Y1 =3D -Y2, then Q is the = identity element. Otherwise, Q =3D (X,Y), where...`
-= In C.2: Exactly the same comments apply here as for C.1/short = Weierstrass curves.
- In C.3: Same comments here as = for C.1/short Weierstrass curves.

### Appendix D

- In D.1: `while mapping each other = point (u,v) of M_{A,B} to the point (x,y):=3D(u/v,(u-1)/(u+1)) of = E_{a,d}`: what about the two points of order two on M_{A,B} not equal to = (0,0) (i.e., the points where v =3D 0 but u !=3D 0)?  The image is = not defined.  This situation may be covered/prohibited by the Note = on twisted Edwards curves, but no such condition was imposed on the = Montgomery curves here...
- In D.2: `Note that not = all Weierstrass curves can be injectively mapped to Montgomery curves`: = I don't think the "injectively" makes any sense here.  Some = Weierstrass curves cannot be transformed into Montgomery form in any = way.  Also note that having a point of order 2 is necessary *but = not sufficient* for the existence of a Montgomery model.

### Appendix E

- In E.2: `as a shift of = (p+A)/3 for the isomorphic mapping and -(p+A)/3 for its inverse, where = delta=3D(p+A)/3 is...`: this should probably be `as a shift of delta for = the isomorphic mapping and -delta for its inverse, where delta:=3D(p+A)/3 = is...`

### = Appendix H

- = `Point decompression... where one tries and recover` should be `where = one tries to recover`
- `from its compressed = representation and information on the domain parameters of the = curve`: 

### Appendix J

It would be good if the base points on the various curves = were mapped onto each other by the isomorphisms/isogenies defined above; = this is probably the case, but it should still be mentioned explicitly = here. 

### = Appendix K

- = I'm really not convinced that this is necessary: it's long, it's = repetitive, it's of marginal interest, and it doesn't fit with the = code-reuse/mapping theme of the main document (except for the mapping = into the twisted Edwards curve).  These maps are not operations of = primary interest, so this appendix amounts to 11 highly technical pages = worth of bloat. I really don't understand the motivation for including = this in this document. 
- In K.2: It would be = worth mentioning that the "Fermat" inversion 1/y =3D y^{q-2} in GF(q) = works also for q =3D p prime, and that it is easier to implement in = constant-time (where this is relevant/required).
- = In K.4.1: `If t is an element of GF(q) that is not a square... yields an = affine point P(t)... Let P0:=3D(X0,Y0) be a fixed affine point of = W_{a,b} for which neither P0, P0 + P(t), not P0 - P(t) is in the small = subgroup`: it should be made clear that this property is supposed to = hold *for all nonsquare t*.
- In K.4.2: Same remark = as above for K.4.1

### Appendix L

`This section illustrates how isogenies can be used to yield = curves with specific properties (here, illustrated for the "BitCoin" = curve secp256k1).`  What are these specific properties in this = instance?  The new curve secp256k1.m is not in Montgomery form, = does not have a =3D -3 or -1, does not have particularly nice = coefficients...  We have to go back to NOTE 2 of Appendix K to find = out that the objective here is just to map from secp256k1 to a = Weierstrass curve with nonzero a and b coefficients.  This can only = be achieved with an isogeny, not an isomorphism, but then why not = transform into one of these more "useful" restricted-short-Weierstrass = models (e.g. a =3D 1 or a =3D -3)?  That would be more coherent = with the "code re-use" motivation of the document.  If all you want = is nonzero coefficients then virtually any rational isogeny would do the = job, and that reduces this entire appendix to an extra sentence in NOTE = 2 of Appendix K.

### Appendix M

- In M.1: `with as base point the point (Gx, Gy)` should be = `with base point (Gx, Gy)`.
- Same for the `with as = base point the point (GX, GY)`.
- In M.2: Same = "delta" comment as for E.2.

### Appendix N

What is the point of Edwards448? Is this just some = intermediate curve?  Does this curve really need to be named and = specified?


On 12 = Nov 2021, at 08:42, Stanislav V. Smyshlyaev <smyshsv@gmail.com> = wrote:

Thanks, we'll be looking forward to it.

Regards,
Stanislav

On Fri, 12 = Nov 2021 at 10:35, Karthikeyan Bhargavan <karthik.bhargavan@gmail.com> wrote:
Sorry about this, am pushing my colleague and = we=E2=80=99ll get it done.

On 12 = Nov 2021, at 07:35, Stanislav V. Smyshlyaev <smyshsv@gmail.com> wrote:

Hi Karthik,

>> We=E2=80=99ll send our review = early next week.
The authors keep asking me about = the review - could you please finish it today (it is already later than = "early this week" :) )?..

Regards,
Stanislav

On Sat, 6 Nov 2021 at 01:55, Stanislav V. = Smyshlyaev <smyshsv@gmail.com> wrote:
Thank = you, Karthik!

Regards,
Stanislav 

On Sat, 6 = Nov 2021 at 00:33, Karthikeyan Bhargavan <karthik.bhargavan@gmail.com> wrote:
Hi Stanislav,

My colleague and I = dropped the ball on this, but have made progress this week.
We=E2=80=99ll send our review early next week.

-Karthik

On 5 Nov 2021, at 19:27, Stanislav V. = Smyshlyaev <smyshsv@gmail.com> wrote:

(CC=E2=80=99ing the second = Karthik=E2=80=99s address that I am aware of.)

Karthik, = please let me know about the status of your review. The authors have = already asked us about the status of their review today, so my question = to you yesterday was reasonable. 

Regards, 
Stanislav 

On Thu, 4 = Nov 2021 at 20:50, Stanislav V. Smyshlyaev <smyshsv@gmail.com> wrote:
Dear = Karthik,

I may be missing something here, but could you = please remind me whether you had sent a review for that = document?..

Regards,
Stanislav 

On Wed, 11 = Aug 2021 at 17:01, Stanislav V. Smyshlyaev <smyshsv@gmail.com> wrote:
In my = opinion, it will be absolutely fine, taking the size of the = document into account.

Thank you, Karthik!

Regards,
Stanislav = (on behalf of the CFRG Chairs)

On Wed, 11 = Aug 2021 at 16:58, Karthikeyan Bhargavan <karthik.bhargavan@gmail.com> wrote:
Is 1 month too long a = wait?

On 11 Aug 2021, at 09:52, = Stanislav V. Smyshlyaev <smyshsv@gmail.com> wrote:

Great, = thanks!

How much = time will you need for this (taking 146 pages into = account) 
I would like to send a message to = the authors (CC'ing crypto-panel mailing list).

Regards,
Stanislav

On Wed, 11 = Aug 2021 at 16:43, Karthikeyan Bhargavan <karthik.bhargavan@gmail.com> wrote:
Sure, I got a request = on another thread a well and can do this (with help from some = colleaugues.)

-K.

On 11 Aug 2021, at 09:39, Stanislav V. = Smyshlyaev <smyshsv@gmail.com> wrote:

Karthik,

Can you do a review of this document (as a Crypto Review = Panel member)?

Regards,
Stanislav

On Fri, 6 Aug 2021 at 12:46, Stanislav V. = Smyshlyaev <smyshsv@gmail.com> wrote:
Dear Karthik,

Nick, Alexey and I have had some discussion about reviewing = the "Alternative Elliptic Curve Representations" draft, = draft-ietf-lwig-curve-representations-21, https://datatracker.ietf.org/doc/draft-ietf-lwig-curve-represen= tations/ - may we ask you to do the review (on behalf of = the Crypto Panel)?

Regards,
Stanislav

On Fri, 16 Jul 2021 at 11:50, Stanislav V. = Smyshlyaev <smyshsv@gmail.com> wrote:
Dear = Crypto Panel Experts, 

We've obtained a request for review of the version -21 of the = "Alternative Elliptic Curve Representations" draft, = draft-ietf-lwig-curve-representations-21, https://datatracker.ietf.org/doc/draft-ietf-lwig-curve-represen= tations/

The = Crypto Panel (that was my review back then) provided a review of the -00 = version three years ago:
https://mailarchive.ietf.org/arch/msg/crypto-panel/1itH0lM9w0bZ= iADJXQkizr8JTiA/

The document has changed significantly = since then, so the authors ask for a new review. 

The chairs would like to = ask the Crypto Panel to provide a review (another pair of eyes + = reviewing all the changes in the document).

Any volunteers?

Regards,
Stanislav = (for CFRG Chairs)






= --Apple-Mail=_D459231E-CD05-49D7-8BC2-7280F427F68A-- From nobody Mon Nov 15 09:11:15 2021 Return-Path: X-Original-To: crypto-panel@ietfa.amsl.com Delivered-To: crypto-panel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 283EE3A0E91 for ; Mon, 15 Nov 2021 09:11:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 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, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A5tfEwVg4bDm for ; Mon, 15 Nov 2021 09:11:07 -0800 (PST) Received: from mail-oi1-x22c.google.com (mail-oi1-x22c.google.com [IPv6:2607:f8b0:4864:20::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 48C553A0E93 for ; Mon, 15 Nov 2021 09:11:07 -0800 (PST) Received: by mail-oi1-x22c.google.com with SMTP id be32so36124924oib.11 for ; Mon, 15 Nov 2021 09:11:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=cQVxn9Qv6yQ95dn9ZwnUQM+A3dlWeCjS1meTG2yX4jk=; b=p1Sc4ge4nRAWoWFfKWK7gFmWldhydjGWaojCJGJbep1xpo+f5WjmMu83CHPSgjTqj4 xiMWcfr1C7Be6RWCqe1EBKUio+kXHb257lpXSZMPHmbOvRIbpiSeuYTBqV0Hwi37e5Bh Okwszc38XXT6msDXnPimY58Hd2vTP1n1LwIraez19zsqwsGgUufvqvLRyOWZuqhSRyDs 9JOK6doW24qhowDgOYejNq675poKvnBzyaZQJhNIB+t8CtFobiuGfj1qbxcT5MzQkpji Qhp0o0MCZXk+wdA56Y31sEZLfPWxr9Ah4Xj73wGHNSYDoH4592r0+/oVf0g3djkstWf1 egLA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=cQVxn9Qv6yQ95dn9ZwnUQM+A3dlWeCjS1meTG2yX4jk=; b=wnQVWyZGT22ujZNylfujDIyxCGxZksQ1A+b0xszpZX2S1W4Rb1ZYlRpdH7akSUcAJm UJLbD1maGwt3NkydnNC9Kn3HMJmMd69takrdWM3nb6anjOM75nS9K+CCyRi+oWqC2L4X +2/t2ZQ3xZuROBSZRvSKAKFp4DEJ0Oo2iqZypWttInCUJm8eudEeoVKt6vplrDEyFFKm o64XVtRF2MnBIJ/h8gAlYmbNppkKVEdC7W2dghvoi7LUiqZ6Aw+OikWH7uX7giwny/oL 6acdcT1+AA7vU4LDhvE/YS7v0FIMuQqlLrx/KkT9Y3jw6I0JRJNTxKrqK/KVg7HFWcx/ +X0Q== X-Gm-Message-State: AOAM533vkl+pHOGQPuU/ghmGS5ywTrPCGBXkOVETrNI5JpYF00M9VXYe 0n8lrgzvQDMgSGssyoiymzTtKCXy1sk3xpQmPzI= X-Google-Smtp-Source: ABdhPJyhpQU26hJy6NRZr+fs8ixESKrjC7NsYauVO/9+CxMMb/IyLtTNCw01pWVnR2VGEEsRXootonaE0xBcq6W9nn4= X-Received: by 2002:aca:3bd5:: with SMTP id i204mr265174oia.100.1636996265231; Mon, 15 Nov 2021 09:11:05 -0800 (PST) MIME-Version: 1.0 References: <5915C771-DCCF-4186-AD78-81A11A739160@gmail.com> <8B6AC27E-2483-4939-8813-9BC9F2F0C352@gmail.com> <3B440D27-2490-4050-BDA0-4D0700FB8944@gmail.com> In-Reply-To: <3B440D27-2490-4050-BDA0-4D0700FB8944@gmail.com> From: Erik Kline Date: Mon, 15 Nov 2021 09:10:54 -0800 Message-ID: To: Karthikeyan Bhargavan Cc: crypto-panel@irtf.org, sec-ads@ietf.org, draft-ietf-lwig-curve-representations.all@ietf.org, cfrg-chairs@ietf.org, Benjamin Smith Content-Type: multipart/alternative; boundary="000000000000e349bf05d0d6e4ea" Archived-At: Subject: Re: [Crypto-panel] Request for review: "Alternative Elliptic Curve Representations" X-BeenThere: crypto-panel@irtf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Nov 2021 17:11:13 -0000 --000000000000e349bf05d0d6e4ea Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Karthikeyan, Thank you so much for taking the time and giving such a detailed review! Much appreciated, -Erik On Fri, Nov 12, 2021 at 5:28 AM Karthikeyan Bhargavan < karthik.bhargavan@gmail.com> wrote: > > Hello All, > > Below is a detailed technical review of draft-ietf-lwig-curve-representat= ions-21 > by Benjamin Smith (cc-ed). > > I discussed this review with Ben and agree with his concerns and it would > be great if the authors could address his questions. > > In particular, I feel the code reuse motivation needs to be better > justified. > One way to do this would be to extend Implementation Considerations > (and/or Implementation Status) with concrete examples of code reuse in > Wei25519 implementations, quantified in lines of code, for example. > If most of the code in these implementations is in the field arithmetic, > which can be reused between representations anyway, the argument for this > draft becomes less compelling. > > Best regards, > Karthik > > =3D=3D=3D > draft-ietf-lwig-curve-representations-21 > =3D=3D=3D > > [Curve representations draft]( > https://datatracker.ietf.org/doc/draft-ietf-lwig-curve-representations/) > > # Review by Benjamin Smith > > This draft specifies a series of new elliptic curves related to Curve2551= 9 > and Curve448, and transformations between these new curves and > Curve25519/Curve448. The motivation is essentially code re-use: legacy > elliptic-curve software and hardware works with the classic "short > Weierstrass form", often with the a-coefficient set to -3, but in more > recent protocols and software we might work with Curve25519 and Curve448 = in > either "Montgomery form" or "twisted Edwards form" (depending on the > protocol), for efficiency reasons. On the surface, these equation forms > are not the same, so the newer curves are incompatible with legacy ECC co= de. > > This document bridges the gap by writing down isomorphisms to short > Weierstrass curves with a=3D-3 where such isomorphisms exist, and isogeni= es > (homomorphic maps) where isomorphisms do not exist. It also specifies > several other curves and maps, of various levels of usefulness. > > I am not entirely convinced by the code re-use argument here. I agree > that this is an interesting goal, given the time and effort it takes to > develop and certify cryptographic software and especially hardware. But > for a concrete example, suppose we have an existing implementation > elliptic-curve scalar multiplication on NIST P256, and we want to use thi= s > document to re-use that software for scalar multiplication on Curve25519: > > 1. The curve group operations for P256 can be and reused, and so can the > scalar multiplication algorithm(s), insofar as they just call the curve > group operations. > 2. The underlying field arithmetic implementation must be > rewritten/replaced, because these curves work modulo different primes. > Generally this isn't just a matter of changing a hard-coded value for the > prime p: the different primes have been chosen to allow completely > different optimized modular reduction algorithms. > 3. The code to actually map points between the two curves must be added, > and in some cases this code will be particularly large. In particular, t= he > code here to convert from Curve25519 to Weierstrass with a=3D-3 involves = 9kb > worth of data to define the isogeny (to say nothing of the code to evalua= te > the isogeny). > 4. The protocol may need to be tweaked to deal with the implicit > multiplication by the isogeny degree > > Comparing the small amount of code saved to the new code to be added, and > the possible modifications to the protocol: is this really worth it? If > you're going to have to add a whole new field arithmetic implementation > _and_ an extremely heavy isogeny-evaluation function (specified by a > massive collection of precomputed coefficients), then maybe you would be > better off just implementing Curve25519 properly. > > One might argue that the real benefit here would be for curve > implementations in hardware, where changing (and re-certifying) designs i= s > extremely slow, but I think that argument is defeated by the fact that th= e > finite field arithmetic (the lowest level) still has to be rewritten. > > Ironically, herefore, this document could be read as a convincing argumen= t > **against** code re-use. Of course, I might just be totally missing the > point. In that case, since I have read all 150 pages and still missed the > point, I think this means that the author hasn't fully explained the poin= t. > > The document is _extremely_ long, and often quite repetitive. There is > too much repetition of boilerplate text blocks for the various > transformations applied to different concrete instances. To give just on= e > example: Appendix M is essentially the same as Appendix E, but with > different curve parameters. There must be a way to minimise this > repetition (especially given the focus on code re-use!). > > More structural/editorial issues: > > - Appendix I (data conversions) must already be covered elsewhere: it > could probably be removed. > - Appendices P, and Q are basically out of scope, and should be removed. > - Appendix K is also essentially out of scope. > - Appendix L can also be removed: it is a long and unneccessary > elaboration on a remark in Appendix K, and therefore out of scope. > - Appendix N seems mostly superfluous: I don't understand why this > Edwards448 curve needs to be defined and named (we already have Ed448...) > > Most of the technical content is uncontroversial, and it is mostly correc= t > (detailed technical comments follow). I am not competent to evaluate > Sections 10, 11, and 12, but I have checked the rest in detail. > > One key technical point: as mentioned above, the transfer between many of > the curves here requires an isogeny (a homomorphic map) rather than an > isomorphism (essentially a change of coordinates). One of the most > important isogenies here - the one from Curve25519 to Wei25519.-3 - has > degree 47. This means that specifying it involves, at a minimum, a > degree-23 polynomial w(x). This polynomial w(x) is dense, so we need to > specify (and store) 23x 32-byte coefficients. This obviously requires a > lot of space! I say "at a minimum", because two more polynomials, u(x) a= nd > v(x), of similar degree, are required. Mathematically they can be derived > from w(x), but for algorithmic simplicity it may be more convenient to > specify them in their expanded form, as is done here. Then, the "dual" m= ap > from Wei25519.-3 back to Curve25519 has its own large u, v, and w. > Ultimately, this means a *lot* of space: 9kB of memory in code, and 12+ > pages of this document. > > Reducing this size (and evaluation time) is important if this is to be > made practical. I have checked, and I agree with the author that there i= s > no isogeny of *prime* degree less than 47 from Curve25519 to a > short-Weierstrass curve with a=3D-3. However, there *is* such an isogeny= of > composite degree 46 (I could not find any lower-degree composite isogenie= s > that do the job). This doesn't look like much of an improvement on the > surface, but the degree-46 isogeny is the composite of a degree-2 isogeny > (very easy to specify/compute) and a degree-23 isogeny (roughly half the > coefficients and complexity compared with the 47-isogeny). This means th= at > by changing the definition of Wei25519.-3 to be the codomain of the > 46-isogeny instead of the 47-isogeny, the time and space required to enco= de > and compute the isogeny will be literally cut in half. Of course, half o= f > 9kB is still quite expensive, and it remains to be seen if anyone will > consider this practical for applications, but I think it is still an > improvement that the author might want to consider using. > > ## Technical remarks > > - "unequal to" should generally be replaced with "not equal to" > - most instances of "hereof" should be "thereof", though something less > archaic than "(t)hereof" would be even better > > ### 1 Fostering Code Reuse with New Elliptic Curves > > - `we specify these curves` should probably be a bit more specific: "we > specify the CFRG curves"? > > ### 4 Examples > > - In 4.1: `Moreover, with X25519, private keys are generated in the > interval [2^251,2^252-1] rather than in the interval [1,n-1] (the so-call= ed > "clamping") and one uses as base point G':=3Dh*G, where G, n, and h are, > respectively, the fixed base point, the order of the base point, and the > co-factor of the curve in question`: I think this is wrong. The private > keyspace for X25519 is $S =3D \{2^{254} + 8k : k \in [0,2^{251}-1]\}$. I= f > you use the keyspace defined here and multiply by the cofactor 8 then thi= s > gives the same thing, but that's not how X25519 is specified: clamping > produces an element of $S$, and there is no explicit cofactor > multiplication. We should double-check the equivalence of these schemes. > - In 4.2: `One can implement the computation of the ephemeral key pair fo= r > Ed25519 using an existing Montgomery curve implementation by (1) generati= ng > a public-private key pair (k, R':=3Dk*G') for Curve25519;(2) representing > this public-private key as the pair (k, R:=3Dk*G) for Ed25519.` This is > confusing, because $G$ and $G'$ are not the same point. There's also thi= s > explicit-vs-implicit question for Curve25519 key pairs. Finally, "*key > pair* for Curve25519" makes me think of Curve25519 the protocol, rather > than Curve25519 the curve, and in the protocol the public key is only an > x-coordinate. > > ### 5 Caveats > > - In 5.1: the u-coordinate-only compression of RFC7748 (X25519) is not > "lossy" (the dropped v-coordinate was never part of the protocol or keys)= , > unless "lossy" means that it maps the point at infinity and (0,0) to the > same value, 0. > - In 5.3: "NOTE 1" is interesting, but also kind of pointless in this kin= d > document. > - In 5.3: "NOTE 2" makes me wonder how all these isogenies were > found/computed. It might be worth noting that this 2-isogeny does not > preserve the endomorphism ring: you move one level up to the "crater" of > the 2-volcano with this isogeny. On a more basic level, the curves don't > have the same abelian group structure: the twist of Curve25519 has a cycl= ic > group, while the 2-isogenous curve has non-cyclic 2-torsion. This is not > an issue with the 47-isogeny from Curve25519, which restricts to an > isomorphism on groups of rational points. > > ### 6 Implementation considerations > > Clarification: `All NIST curves [FIPS-186-4] and Brainpool curves > [RFC5639] are Weierstrass curves with a=3D-3 domain parameter, thus > facilitating more efficient elliptic curve group operations (via so-calle= d > Jacobian coordinates).` - this "more efficient" is w.r.t. general short > Weierstrass curves with a !=3D -3. > > ### 8 Security considerations > > - `...which is either an isomorphism of a low-degree isogeny`: 47 isn't > that low (well, not unless you're a CSIDH implementer)! > - `the complexity of cryptographic problems (such as the discrete > logarithm problem) of curves related via a low-degree isogeny are tightly > related. Thus, the use of these techniques does not negatively impact > cryptogaphic security of elliptic curve operations.`: this can be made mo= re > precise. The 47-isogeny is an isomorphism on the level of groups of poin= ts > (because 47 is coprime to the group order), and since the groups are > isomorphic their DLPs have equivalent difficulty. (The 2-isogeny from th= e > twist restricts to an isomorphism of the prime-order subgroups, which is > where all the DLP difficulty comes from in that case, so similarly the DL= Ps > have equivalent difficulty.) > - `the use of these techniques does not negatively impact cryptogaphic > security of elliptic curve operations`: this might be true in the sense o= f > DLP operations, but the existence of an isomorphism doesn't mean that > things like side-channel safety extends from a Curve25519 implementation = to > a Wei25519 implementation. So maybe "security of elliptic curve > operations" should be changed to something like "security of the underlyi= ng > elliptic curve discrete logarithms"? > > ### 14 References > > `[Wei-Ladder]` was published in PKC 2002, and there's no reason to cite a > preprint instead here instead of the definitive version. This reference > can be updated to: Tetsuya Izu and Tsuyoshi Takagi, "A Fast Parallel > Elliptic Curve Multiplication Resistant Against Side Channel Attacks", PK= C > 2002, Lecture Notes in Computer Science Vol. 2274, Springer-Verlag, 2002. > > ### Appendix B > > I'm not really sure why this is separate from Appendix A. > > - In B.1: The notation `(P)` for the subgroup generated by P is > nonstandard and has a fair potential for confusion; `

` would be more > typical. > - In B.1: `The order of curve E` should be "The order of *a* curve E" > - In B.1: `All curves of prime order are cyclic`: more generally, if the > order is not divisible by a square > 1 then the group is cyclic. > - In B.1: `if h*P =3D O (and is a high-order point otherwise); this point > has order n` is slightly ambiguous: `the point P has order n` would be a > little clearer. > - In B.1: `Random points R of (P), where P has order l, ... computing > R:=3Dk*P, where R has rder l/gcd(k,l)`: this "where" sounds like a > restriction on R, rather than a corollary. Something like `computing > R:=3Dk*P. The point R has order l/gcd(k,l)` would be clearer. > - In B.1: `unless k is a multipl of n`: this `n` should be an `l`, but > then `k` cannot be a multiple of `l` unless it is zero (because it was > sampled from [0,l-1]). > - In B.1: `If P is a fixed base point G of the curve...`: P is never used > again in this paragraph (or indeed, in the rest of this appendix), so its > appearance here is confusing. Maybe this could be rephrased purely in ter= ms > of G? > - In B.1: `If this representation is nonzero, R has order n`: this is onl= y > true for `n` prime. > - In B.1: `...|E| relatively close to q, where, in fact, |E|=3Dq+1-t`: th= is > "where" is grammatically confusing. `...|E| relatively close to q. In > fact, |E|=3Dq+1-t` would be clearer. > - In B.1: `Points that are both points of E and E'` should be "Points tha= t > are points of both E an E'", which sounds funny because of the "Points th= at > are points"; maybe `Points that are simultaneously in E and in E'` would = be > better? > - In B.1: `Two curves E and E'... are said to be isomorphic if these have > the same group structure`: **this is wrong**. They are isomorphic if the= re > exists an isomorphism *of elliptic curves*, not a group isomorphism. For > example, if q is fixed and large, and n is a prime in the Hasse interval > close to q, then there are O(\sqrt{q}) non-isomorphic curves of order n, > all with groups of points isomorphic to Z/nZ. These curves are all > isogenous, but they are generally connected by isogenies of extremely lar= ge > degree, which cannot be computed efficiently - so the DLP in these curves > is not necessarily equivalent, in the sense that the DLP in one curve > cannot necessarily be mapped into another in polynomial time. There is > certainly no algebraic isomorphism between the curves; generally, mapping > points homomorphically from one group into another means solving DLPs! S= o > even though the groups are isomorphic, I think it is wrong (and seriously > misleading) to say that these curves are isomorphic. > - In B.2: `where g^0 is the identity element 1 of GF(q)`: 1 is the > multiplicative identity element (0 is the additive identity element). It > might be clearer to just say "the multiplicative identity element 1 of > GF(q)", or even simpler "the element 1 of GF(q)". > - In B.2: `the set GF(q)\{0} is cyclic`: this should be `the set > GF(q)\{0}` forms a cyclic group (a set cannot be cyclic). > - In B.2: `computing square roots and inverses in GF(q) - if these exist`= : > inverses always exist (except for 0). I think the "if these exist" > qualifier belongs with the square roots instead. > - In B.2: `Readers not interested in this, could simply view...`: remove > the comma. > > ### Appendix C > > - In C.1: `For each point P of the Weierstrass curve W_{a,b}, the point a= t > infinity O serves as identity element`: the identity element is always > defined for the group, not w.r.t. each element P. This would be clearer = as > `On the Weierstrass curve W_{a,b}, the point at infinity serves as identi= ty > element`. > - In C.1: `One has P + (-P) =3D O`: this is an example of somewhere where > the notation `(P)` for the subgroup generated by P causes a bad ambiguity= . > - In C.1: `...let Q:=3DP1 + P2, where Q is not the identity element. The= n > Q:=3D(X, Y)`: Q is being defined in `Q:=3DP1 + P2`, so you can't restrict= it in > this way, and then the second definition `Q:=3D(X, Y)` is tautological. > Maybe this would be clearer as `...let Q:=3D P1 + P2. If X1 =3D X2 and Y= 1 =3D > -Y2, then Q is the identity element. Otherwise, Q =3D (X,Y), where...` > - In C.2: Exactly the same comments apply here as for C.1/short > Weierstrass curves. > - In C.3: Same comments here as for C.1/short Weierstrass curves. > > ### Appendix D > > - In D.1: `while mapping each other point (u,v) of M_{A,B} to the point > (x,y):=3D(u/v,(u-1)/(u+1)) of E_{a,d}`: what about the two points of orde= r > two on M_{A,B} not equal to (0,0) (i.e., the points where v =3D 0 but u != =3D > 0)? The image is not defined. This situation may be covered/prohibited = by > the Note on twisted Edwards curves, but no such condition was imposed on > the Montgomery curves here... > - In D.2: `Note that not all Weierstrass curves can be injectively mapped > to Montgomery curves`: I don't think the "injectively" makes any sense > here. Some Weierstrass curves cannot be transformed into Montgomery form > in any way. Also note that having a point of order 2 is necessary *but n= ot > sufficient* for the existence of a Montgomery model. > > ### Appendix E > > - In E.2: `as a shift of (p+A)/3 for the isomorphic mapping and -(p+A)/3 > for its inverse, where delta=3D(p+A)/3 is...`: this should probably be `a= s a > shift of delta for the isomorphic mapping and -delta for its inverse, whe= re > delta:=3D(p+A)/3 is...` > > ### Appendix H > > - `Point decompression... where one tries and recover` should be `where > one tries to recover` > - `from its compressed representation and information on the domain > parameters of the curve`: > > ### Appendix J > > It would be good if the base points on the various curves were mapped ont= o > each other by the isomorphisms/isogenies defined above; this is probably > the case, but it should still be mentioned explicitly here. > > ### Appendix K > > - I'm really not convinced that this is necessary: it's long, it's > repetitive, it's of marginal interest, and it doesn't fit with the > code-reuse/mapping theme of the main document (except for the mapping int= o > the twisted Edwards curve). These maps are not operations of primary > interest, so this appendix amounts to 11 highly technical pages worth of > bloat. I really don't understand the motivation for including this in thi= s > document. > - In K.2: It would be worth mentioning that the "Fermat" inversion 1/y = =3D > y^{q-2} in GF(q) works also for q =3D p prime, and that it is easier to > implement in constant-time (where this is relevant/required). > - In K.4.1: `If t is an element of GF(q) that is not a square... yields a= n > affine point P(t)... Let P0:=3D(X0,Y0) be a fixed affine point of W_{a,b}= for > which neither P0, P0 + P(t), not P0 - P(t) is in the small subgroup`: it > should be made clear that this property is supposed to hold *for all > nonsquare t*. > - In K.4.2: Same remark as above for K.4.1 > > ### Appendix L > > `This section illustrates how isogenies can be used to yield curves with > specific properties (here, illustrated for the "BitCoin" curve secp256k1)= .` > What are these specific properties in this instance? The new curve > secp256k1.m is not in Montgomery form, does not have a =3D -3 or -1, does= not > have particularly nice coefficients... We have to go back to NOTE 2 of > Appendix K to find out that the objective here is just to map from > secp256k1 to a Weierstrass curve with nonzero a and b coefficients. This > can only be achieved with an isogeny, not an isomorphism, but then why no= t > transform into one of these more "useful" restricted-short-Weierstrass > models (e.g. a =3D 1 or a =3D -3)? That would be more coherent with the = "code > re-use" motivation of the document. If all you want is nonzero > coefficients then virtually any rational isogeny would do the job, and th= at > reduces this entire appendix to an extra sentence in NOTE 2 of Appendix K= . > > ### Appendix M > > - In M.1: `with as base point the point (Gx, Gy)` should be `with base > point (Gx, Gy)`. > - Same for the `with as base point the point (GX, GY)`. > - In M.2: Same "delta" comment as for E.2. > > ### Appendix N > > What is the point of Edwards448? Is this just some intermediate curve? > Does this curve really need to be named and specified? > > > On 12 Nov 2021, at 08:42, Stanislav V. Smyshlyaev > wrote: > > Thanks, we'll be looking forward to it. > > Regards, > Stanislav > > On Fri, 12 Nov 2021 at 10:35, Karthikeyan Bhargavan < > karthik.bhargavan@gmail.com> wrote: > >> Sorry about this, am pushing my colleague and we=E2=80=99ll get it done. >> >> On 12 Nov 2021, at 07:35, Stanislav V. Smyshlyaev >> wrote: >> >> Hi Karthik, >> >> >> We=E2=80=99ll send our review early next week. >> The authors keep asking me about the review - could you please finish it >> today (it is already later than "early this week" :) )?.. >> >> Regards, >> Stanislav >> >> On Sat, 6 Nov 2021 at 01:55, Stanislav V. Smyshlyaev >> wrote: >> >>> Thank you, Karthik! >>> >>> Regards, >>> Stanislav >>> >>> On Sat, 6 Nov 2021 at 00:33, Karthikeyan Bhargavan < >>> karthik.bhargavan@gmail.com> wrote: >>> >>>> Hi Stanislav, >>>> >>>> My colleague and I dropped the ball on this, but have made progress >>>> this week. >>>> We=E2=80=99ll send our review early next week. >>>> >>>> -Karthik >>>> >>>> On 5 Nov 2021, at 19:27, Stanislav V. Smyshlyaev >>>> wrote: >>>> >>>> (CC=E2=80=99ing the second Karthik=E2=80=99s address that I am aware o= f.) >>>> >>>> Karthik, please let me know about the status of your review. The >>>> authors have already asked us about the status of their review today, = so my >>>> question to you yesterday was reasonable. >>>> >>>> Regards, >>>> Stanislav >>>> >>>> On Thu, 4 Nov 2021 at 20:50, Stanislav V. Smyshlyaev >>>> wrote: >>>> >>>>> Dear Karthik, >>>>> >>>>> I may be missing something here, but could you please remind me >>>>> whether you had sent a review for that document?.. >>>>> >>>>> Regards, >>>>> Stanislav >>>>> >>>>> On Wed, 11 Aug 2021 at 17:01, Stanislav V. Smyshlyaev < >>>>> smyshsv@gmail.com> wrote: >>>>> >>>>>> In my opinion, it will be absolutely fine, taking the size of the >>>>>> document into account. >>>>>> >>>>>> Thank you, Karthik! >>>>>> >>>>>> Regards, >>>>>> Stanislav (on behalf of the CFRG Chairs) >>>>>> >>>>>> On Wed, 11 Aug 2021 at 16:58, Karthikeyan Bhargavan < >>>>>> karthik.bhargavan@gmail.com> wrote: >>>>>> >>>>>>> Is 1 month too long a wait? >>>>>>> >>>>>>> On 11 Aug 2021, at 09:52, Stanislav V. Smyshlyaev >>>>>>> wrote: >>>>>>> >>>>>>> Great, thanks! >>>>>>> >>>>>>> How much time will you need for this (taking 146 pages into account= ) >>>>>>> I would like to send a message to the authors (CC'ing crypto-panel >>>>>>> mailing list). >>>>>>> >>>>>>> Regards, >>>>>>> Stanislav >>>>>>> >>>>>>> On Wed, 11 Aug 2021 at 16:43, Karthikeyan Bhargavan < >>>>>>> karthik.bhargavan@gmail.com> wrote: >>>>>>> >>>>>>>> Sure, I got a request on another thread a well and can do this >>>>>>>> (with help from some colleaugues.) >>>>>>>> >>>>>>>> -K. >>>>>>>> >>>>>>>> On 11 Aug 2021, at 09:39, Stanislav V. Smyshlyaev < >>>>>>>> smyshsv@gmail.com> wrote: >>>>>>>> >>>>>>>> Karthik, >>>>>>>> >>>>>>>> Can you do a review of this document (as a Crypto Review Panel >>>>>>>> member)? >>>>>>>> >>>>>>>> Regards, >>>>>>>> Stanislav >>>>>>>> >>>>>>>> On Fri, 6 Aug 2021 at 12:46, Stanislav V. Smyshlyaev < >>>>>>>> smyshsv@gmail.com> wrote: >>>>>>>> >>>>>>>>> Dear Karthik, >>>>>>>>> >>>>>>>>> Nick, Alexey and I have had some discussion about reviewing the >>>>>>>>> "Alternative Elliptic Curve Representations" draft, >>>>>>>>> draft-ietf-lwig-curve-representations-21, >>>>>>>>> https://datatracker.ietf.org/doc/draft-ietf-lwig-curve-representa= tions/ - >>>>>>>>> may we ask you to do the review (on behalf of the Crypto Panel)? >>>>>>>>> >>>>>>>>> Regards, >>>>>>>>> Stanislav >>>>>>>>> >>>>>>>>> On Fri, 16 Jul 2021 at 11:50, Stanislav V. Smyshlyaev < >>>>>>>>> smyshsv@gmail.com> wrote: >>>>>>>>> >>>>>>>>>> Dear Crypto Panel Experts, >>>>>>>>>> >>>>>>>>>> We've obtained a request for review of the version -21 of the >>>>>>>>>> "Alternative Elliptic Curve Representations" draft, >>>>>>>>>> draft-ietf-lwig-curve-representations-21, >>>>>>>>>> https://datatracker.ietf.org/doc/draft-ietf-lwig-curve-represent= ations/ >>>>>>>>>> >>>>>>>>>> The Crypto Panel (that was my review back then) provided a revie= w >>>>>>>>>> of the -00 version three years ago: >>>>>>>>>> >>>>>>>>>> https://mailarchive.ietf.org/arch/msg/crypto-panel/1itH0lM9w0bZi= ADJXQkizr8JTiA/ >>>>>>>>>> >>>>>>>>>> The document has changed significantly since then, so the author= s >>>>>>>>>> ask for a new review. >>>>>>>>>> >>>>>>>>>> The chairs would like to ask the Crypto Panel to provide a revie= w >>>>>>>>>> (another pair of eyes + reviewing all the changes in the documen= t). >>>>>>>>>> >>>>>>>>>> Any volunteers? >>>>>>>>>> >>>>>>>>>> Regards, >>>>>>>>>> Stanislav (for CFRG Chairs) >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>> >> > > --000000000000e349bf05d0d6e4ea Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Karthikeyan,

Thank you so much for taki= ng the time and giving such a detailed review!

Muc= h=C2=A0appreciated,
-Erik

On Fri, Nov 12, 2021 at 5:28 AM Ka= rthikeyan Bhargavan <kart= hik.bhargavan@gmail.com> wrote:

H= ello All,

Below is a detailed technical review of= =C2=A0draft-ietf-lwig-curve-representation= s-21 by Benjamin Smith (cc-ed).

I discussed this review with Ben and ag= ree with his concerns and it would be great if the authors could address hi= s questions.

In particular, I feel the code reuse = motivation needs to be better justified.
One way to do this would= be to extend Implementation Considerations (and/or Implementation Status) = with concrete examples of code reuse in Wei25519 implementations, quantifie= d in lines of code, for example.
If most of the code in these imp= lementations is in the field arithmetic, which can be reused between repres= entations anyway, the argument for this draft becomes less compelling.

Best regards,
Karthik

=3D=3D=3D
draft-ietf-lwig-curve-representations-21
= =3D=3D=3D


# Review by Benjamin Smith=

This draft specifies a series of new elliptic cur= ves related to Curve25519 and Curve448, and transformations between these n= ew curves and Curve25519/Curve448.=C2=A0 The motivation is essentially code= re-use: legacy elliptic-curve software and hardware works with the classic= "short Weierstrass form", often with the a-coefficient set to -3= , but in more recent protocols and software we might work with Curve25519 a= nd Curve448 in either "Montgomery form" or "twisted Edwards = form" (depending on the protocol), for efficiency reasons.=C2=A0 On th= e surface, these equation forms are not the same, so the newer curves are i= ncompatible with legacy ECC code.

This document br= idges the gap by writing down isomorphisms to short Weierstrass curves with= a=3D-3 where such isomorphisms exist, and isogenies (homomorphic maps) whe= re isomorphisms do not exist.=C2=A0 It also specifies several other curves = and maps, of various levels of usefulness.

I am no= t entirely convinced by the code re-use argument here.=C2=A0 I agree that t= his is an interesting goal, given the time and effort it takes to develop a= nd certify cryptographic software and especially hardware.=C2=A0 But for a = concrete example, suppose we have an existing implementation elliptic-curve= scalar multiplication on NIST P256, and we want to use this document to re= -use that software for scalar multiplication on Curve25519:

<= /div>
1. The curve group operations for P256 can be and reused, and so = can the scalar multiplication algorithm(s), insofar as they just call the c= urve group operations.
2. The underlying field arithmetic impleme= ntation must be rewritten/replaced, because these curves work modulo differ= ent primes.=C2=A0 Generally this isn't just a matter of changing a hard= -coded value for the prime p: the different primes have been chosen to allo= w completely different optimized modular reduction algorithms.
3.= The code to actually map points between the two curves must be added, and = in some cases this code will be particularly large.=C2=A0 In particular, th= e code here to convert from Curve25519 to Weierstrass with a=3D-3 involves = 9kb worth of data to define the isogeny (to say nothing of the code to eval= uate the isogeny).
4. The protocol may need to be tweaked to deal= with the implicit multiplication by the isogeny degree

Comparing the small amount of code saved to the new code to be added,= and the possible modifications to the protocol: is this really worth it?= =C2=A0 If you're going to have to add a whole new field arithmetic impl= ementation _and_ an extremely heavy isogeny-evaluation function (specified = by a massive collection of precomputed coefficients), then maybe you would = be better off just implementing Curve25519 properly.

One might argue that the real benefit here would be for curve implementa= tions in hardware, where changing (and re-certifying) designs is extremely = slow, but I think that argument is defeated by the fact that the finite fie= ld arithmetic (the lowest level) still has to be rewritten.

<= /div>
Ironically, herefore, this document could be read as a convincing= argument **against** code re-use.=C2=A0 Of course, I might just be totally= missing the point. In that case, since I have read all 150 pages and still= missed the point, I think this means that the author hasn't fully expl= ained the point.

The document is _extremely_ long,= and often quite repetitive.=C2=A0 There is too much repetition of boilerpl= ate text blocks for the various transformations applied to different concre= te instances.=C2=A0 To give just one example: Appendix M is essentially the= same as Appendix E, but with different curve parameters.=C2=A0 There must = be a way to minimise this repetition (especially given the focus on code re= -use!).

More structural/editorial issues:

- Appendix I (data conversions) must already be covered el= sewhere: it could probably be removed.
- Appendices P, and Q are = basically out of scope, and should be removed.
- Appendix K is al= so essentially out of scope.
- Appendix L can also be removed: it= is a long and unneccessary elaboration on a remark in Appendix K, and ther= efore out of scope.
- Appendix N seems mostly superfluous: I don&= #39;t understand why this Edwards448 curve needs to be defined and named (w= e already have Ed448...)

Most of the technical con= tent is uncontroversial, and it is mostly correct (detailed technical comme= nts follow).=C2=A0 I am not competent to evaluate Sections 10, 11, and 12, = but I have checked the rest in detail.

One key tec= hnical point: as mentioned above, the transfer between many of the curves h= ere requires an isogeny (a homomorphic map) rather than an isomorphism (ess= entially a change of coordinates).=C2=A0 One of the most important isogenie= s here - the one from Curve25519 to Wei25519.-3 - has degree 47.=C2=A0 This= means that specifying it involves, at a minimum, a degree-23 polynomial w(= x).=C2=A0 This polynomial w(x) is dense, so we need to specify (and store) = 23x 32-byte coefficients.=C2=A0 This obviously requires a lot of space!=C2= =A0 I say "at a minimum", because two more polynomials, u(x) and = v(x), of similar degree, are required. Mathematically they can be derived f= rom w(x), but for algorithmic simplicity it may be more convenient to speci= fy them in their expanded form, as is done here.=C2=A0 Then, the "dual= " map from Wei25519.-3 back to Curve25519 has its own large u, v, and = w.=C2=A0 Ultimately, this means a *lot* of space: 9kB of memory in code, an= d 12+ pages of this document.

Reducing this size (= and evaluation time) is important if this is to be made practical.=C2=A0 I = have checked, and I agree with the author that there is no isogeny of *prim= e* degree less than 47 from Curve25519 to a short-Weierstrass curve with a= =3D-3.=C2=A0 However, there *is* such an isogeny of composite degree 46 (I = could not find any lower-degree composite isogenies that do the job).=C2=A0= This doesn't look like much of an improvement on the surface, but the = degree-46 isogeny is the composite of a degree-2 isogeny (very easy to spec= ify/compute) and a degree-23 isogeny (roughly half the coefficients and com= plexity compared with the 47-isogeny).=C2=A0 This means that by changing th= e definition of Wei25519.-3 to be the codomain of the 46-isogeny instead of= the 47-isogeny, the time and space required to encode and compute the isog= eny will be literally cut in half.=C2=A0 Of course, half of 9kB is still qu= ite expensive, and it remains to be seen if anyone will consider this pract= ical for applications, but I think it is still an improvement that the auth= or might want to consider using.

## Technical rema= rks

- "unequal to" should generally be r= eplaced with "not equal to"
- most instances of "h= ereof" should be "thereof", though something less archaic th= an "(t)hereof" would be even better

### = 1 Fostering Code Reuse with New Elliptic Curves

- = `we specify these curves` should probably be a bit more specific: "we = specify the CFRG curves"?

### 4 Examples

- In 4.1: `Moreover, with X25519, private keys are gen= erated in the interval [2^251,2^252-1] rather than in the interval [1,n-1] = (the so-called "clamping") and one uses as base point G':=3Dh= *G, where G, n, and h are, respectively, the fixed base point, the order of= the base point, and the co-factor of the curve in question`: I think this = is wrong.=C2=A0 The private keyspace for X25519 is $S =3D \{2^{254} + 8k : = k \in [0,2^{251}-1]\}$.=C2=A0 If you use the keyspace defined here and mult= iply by the cofactor 8 then this gives the same thing, but that's not h= ow X25519 is specified: clamping produces an element of $S$, and there is n= o explicit cofactor multiplication.=C2=A0 We should double-check the equiva= lence of these schemes.
- In 4.2: `One can implement the computat= ion of the ephemeral key pair for Ed25519 using an existing Montgomery curv= e implementation by (1) generating a public-private key pair (k, R':=3D= k*G') for Curve25519;(2) representing this public-private key as the pa= ir (k, R:=3Dk*G) for Ed25519.` =C2=A0This is confusing, because $G$ and $G&= #39;$ are not the same point.=C2=A0 There's also this explicit-vs-impli= cit question for Curve25519 key pairs.=C2=A0 Finally, "*key pair* for = Curve25519" makes me think of Curve25519 the protocol, rather than Cur= ve25519 the curve, and in the protocol the public key is only an x-coordina= te.

### 5 Caveats

- In 5.= 1: the u-coordinate-only compression of RFC7748 (X25519) is not "lossy= " (the dropped v-coordinate was never part of the protocol or keys), u= nless "lossy" means that it maps the point at infinity and (0,0) = to the same value, 0.
- In 5.3: "NOTE 1" is interesting= , but also kind of pointless in this kind document.
- In 5.3: &qu= ot;NOTE 2" makes me wonder how all these isogenies were found/computed= .=C2=A0 It might be worth noting that this 2-isogeny does not preserve the = endomorphism ring: you move one level up to the "crater" of the 2= -volcano with this isogeny.=C2=A0 On a more basic level, the curves don'= ;t have the same abelian group structure: the twist of Curve25519 has a cyc= lic group, while the 2-isogenous curve has non-cyclic 2-torsion.=C2=A0 This= is not an issue with the 47-isogeny from Curve25519, which restricts to an= isomorphism on groups of rational points.

### 6 I= mplementation considerations

Clarification: `All N= IST curves [FIPS-186-4] and Brainpool curves [RFC5639] are Weierstrass curv= es with a=3D-3 domain parameter, thus facilitating more efficient elliptic = curve group operations (via so-called Jacobian coordinates).` - this "= more efficient" is w.r.t. general short Weierstrass curves with a !=3D= -3.

### 8 Security considerations

<= /div>
- `...which is either an isomorphism of a low-degree isogeny`: 47= isn't that low (well, not unless you're a CSIDH implementer)!
- `the complexity of cryptographic problems (such as the discrete log= arithm problem) of curves related via a low-degree isogeny are tightly rela= ted.=C2=A0 Thus, the use of these techniques does not negatively impact cry= ptogaphic security of elliptic curve operations.`: this can be made more pr= ecise.=C2=A0 The 47-isogeny is an isomorphism on the level of groups of poi= nts (because 47 is coprime to the group order), and since the groups are is= omorphic their DLPs have equivalent difficulty. =C2=A0(The 2-isogeny from t= he twist restricts to an isomorphism of the prime-order subgroups, which is= where all the DLP difficulty comes from in that case, so similarly the DLP= s have equivalent difficulty.)
- `the use of these techniques doe= s not negatively impact cryptogaphic security of elliptic curve operations`= : this might be true in the sense of DLP operations, but the existence of a= n isomorphism doesn't mean that things like side-channel safety extends= from a Curve25519 implementation to a Wei25519 implementation.=C2=A0 So ma= ybe "security of elliptic curve operations" should be changed to = something like "security of the underlying elliptic curve discrete log= arithms"?

### 14 References

`[Wei-Ladder]` was published in PKC 2002, and there's no reason= to cite a preprint instead here instead of the definitive version.=C2=A0 T= his reference can be updated to: Tetsuya Izu and Tsuyoshi Takagi, "A F= ast Parallel Elliptic Curve Multiplication Resistant Against Side Channel A= ttacks", PKC 2002, Lecture Notes in Computer Science Vol. 2274, Spring= er-Verlag, 2002.

### Appendix B

I'm not really sure why this is separate from Appendix A.
<= div>
- In B.1: The notation `(P)` for the subgroup generated = by P is nonstandard and has a fair potential for confusion; `<P>` wou= ld be more typical.
- In B.1: `The order of curve E` should be &q= uot;The order of *a* curve E"
- In B.1: `All curves of prime= order are cyclic`: more generally, if the order is not divisible by a squa= re > 1 then the group is cyclic.
- In B.1: `if h*P =3D O (and = is a high-order point otherwise); this point has order n` is slightly ambig= uous: `the point P has order n` would be a little clearer.
- In B= .1: `Random points R of (P), where P has order l, ... computing R:=3Dk*P, w= here R has rder l/gcd(k,l)`: this "where" sounds like a restricti= on on R, rather than a corollary.=C2=A0 Something like `computing R:=3Dk*P.= The point R has order l/gcd(k,l)` would be clearer.
- In B.1: `u= nless k is a multipl of n`: this `n` should be an `l`, but then `k` cannot = be a multiple of `l` unless it is zero (because it was sampled from [0,l-1]= ).
- In B.1: `If P is a fixed base point G of the curve...`: P is= never used again in this paragraph (or indeed, in the rest of this appendi= x), so its appearance here is confusing. Maybe this could be rephrased pure= ly in terms of G?
- In B.1: `If this representation is nonzero, R= has order n`: this is only true for `n` prime.
- In B.1: `...|E|= relatively close to q, where, in fact, |E|=3Dq+1-t`: this "where"= ; is grammatically confusing. =C2=A0`...|E| relatively close to q. In fact,= |E|=3Dq+1-t` would be clearer.
- In B.1: `Points that are both p= oints of E and E'` should be "Points that are points of both E an = E'", which sounds funny because of the "Points that are point= s"; maybe `Points that are simultaneously in E and in E'` would be= better?
- In B.1: `Two curves E and E'... are said to be iso= morphic if these have the same group structure`: **this is wrong**.=C2=A0 T= hey are isomorphic if there exists an isomorphism *of elliptic curves*, not= a group isomorphism.=C2=A0 For example, if q is fixed and large, and n is = a prime in the Hasse interval close to q, then there are O(\sqrt{q}) non-is= omorphic curves of order n, all with groups of points isomorphic to Z/nZ.= =C2=A0 These curves are all isogenous, but they are generally connected by = isogenies of extremely large degree, which cannot be computed efficiently -= so the DLP in these curves is not necessarily equivalent, in the sense tha= t the DLP in one curve cannot necessarily be mapped into another in polynom= ial time.=C2=A0 There is certainly no algebraic isomorphism between the cur= ves; generally, mapping points homomorphically from one group into another = means solving DLPs!=C2=A0 So even though the groups are isomorphic, I think= it is wrong (and seriously misleading) to say that these curves are isomor= phic.
- In B.2: `where g^0 is the identity element 1 of GF(q)`: 1= is the multiplicative identity element (0 is the additive identity element= ).=C2=A0 It might be clearer to just say "the multiplicative identity = element 1 of GF(q)", or even simpler "the element 1 of GF(q)"= ;.
- In B.2: `the set GF(q)\{0} is cyclic`: this should be `the s= et GF(q)\{0}` forms a cyclic group (a set cannot be cyclic).
- In= B.2: `computing square roots and inverses in GF(q) - if these exist`: inve= rses always exist (except for 0).=C2=A0 I think the "if these exist&qu= ot; qualifier belongs with the square roots instead.
- In B.2: `R= eaders not interested in this, could simply view...`: remove the comma.

### Appendix C

- In C.1: `Fo= r each point P of the Weierstrass curve W_{a,b}, the point at infinity O se= rves as identity element`: the identity element is always defined for the g= roup, not w.r.t. each element P.=C2=A0 This would be clearer as `On the Wei= erstrass curve W_{a,b}, the point at infinity serves as identity element`.<= /div>
- In C.1: `One has P + (-P) =3D O`: this is an example of somewhe= re where the notation `(P)` for the subgroup generated by P causes a bad am= biguity.
- In C.1: `...let Q:=3DP1 + P2, where Q is not the ident= ity element.=C2=A0 Then Q:=3D(X, Y)`: Q is being defined in `Q:=3DP1 + P2`,= so you can't restrict it in this way, and then the second definition `= Q:=3D(X, Y)` is tautological.=C2=A0 Maybe this would be clearer as `...let = Q:=3D P1 + P2.=C2=A0 If X1 =3D X2 and Y1 =3D -Y2, then Q is the identity el= ement. Otherwise, Q =3D (X,Y), where...`
- In C.2: Exactly the sa= me comments apply here as for C.1/short Weierstrass curves.
- In = C.3: Same comments here as for C.1/short Weierstrass curves.

=
### Appendix D

- In D.1: `while mapping= each other point (u,v) of M_{A,B} to the point (x,y):=3D(u/v,(u-1)/(u+1)) = of E_{a,d}`: what about the two points of order two on M_{A,B} not equal to= (0,0) (i.e., the points where v =3D 0 but u !=3D 0)?=C2=A0 The image is no= t defined.=C2=A0 This situation may be covered/prohibited by the Note on tw= isted Edwards curves, but no such condition was imposed on the Montgomery c= urves here...
- In D.2: `Note that not all Weierstrass curves can= be injectively mapped to Montgomery curves`: I don't think the "i= njectively" makes any sense here.=C2=A0 Some Weierstrass curves cannot= be transformed into Montgomery form in any way.=C2=A0 Also note that havin= g a point of order 2 is necessary *but not sufficient* for the existence of= a Montgomery model.

### Appendix E

=
- In E.2: `as a shift of (p+A)/3 for the isomorphic mapping and = -(p+A)/3 for its inverse, where delta=3D(p+A)/3 is...`: this should probabl= y be `as a shift of delta for the isomorphic mapping and -delta for its inv= erse, where delta:=3D(p+A)/3 is...`

### Appendix H=

- `Point decompression... where one tries and rec= over` should be `where one tries to recover`
- `from its compress= ed representation and information on the domain parameters of the curve`:= =C2=A0

### Appendix J

It = would be good if the base points on the various curves were mapped onto eac= h other by the isomorphisms/isogenies defined above; this is probably the c= ase, but it should still be mentioned explicitly here.=C2=A0

=
### Appendix K

- I'm really not con= vinced that this is necessary: it's long, it's repetitive, it's= of marginal interest, and it doesn't fit with the code-reuse/mapping t= heme of the main document (except for the mapping into the twisted Edwards = curve).=C2=A0 These maps are not operations of primary interest, so this ap= pendix amounts to 11 highly technical pages worth of bloat. I really don= 9;t understand the motivation for including this in this document.=C2=A0
- In K.2: It would be worth mentioning that the "Fermat" = inversion 1/y =3D y^{q-2} in GF(q) works also for q =3D p prime, and that i= t is easier to implement in constant-time (where this is relevant/required)= .
- In K.4.1: `If t is an element of GF(q) that is not a square..= . yields an affine point P(t)... Let P0:=3D(X0,Y0) be a fixed affine point = of W_{a,b} for which neither P0, P0 + P(t), not P0 - P(t) is in the small s= ubgroup`: it should be made clear that this property is supposed to hold *f= or all nonsquare t*.
- In K.4.2: Same remark as above for K.4.1

### Appendix L

`This secti= on illustrates how isogenies can be used to yield curves with specific prop= erties (here, illustrated for the "BitCoin" curve secp256k1).` = =C2=A0What are these specific properties in this instance?=C2=A0 The new cu= rve secp256k1.m is not in Montgomery form, does not have a =3D -3 or -1, do= es not have particularly nice coefficients...=C2=A0 We have to go back to N= OTE 2 of Appendix K to find out that the objective here is just to map from= secp256k1 to a Weierstrass curve with nonzero a and b coefficients.=C2=A0 = This can only be achieved with an isogeny, not an isomorphism, but then why= not transform into one of these more "useful" restricted-short-W= eierstrass models (e.g. a =3D 1 or a =3D -3)?=C2=A0 That would be more cohe= rent with the "code re-use" motivation of the document.=C2=A0 If = all you want is nonzero coefficients then virtually any rational isogeny wo= uld do the job, and that reduces this entire appendix to an extra sentence = in NOTE 2 of Appendix K.

### Appendix M
=
- In M.1: `with as base point the point (Gx, Gy)` should be = `with base point (Gx, Gy)`.
- Same for the `with as base point th= e point (GX, GY)`.
- In M.2: Same "delta" comment as fo= r E.2.

### Appendix N

Wha= t is the point of Edwards448? Is this just some intermediate curve?=C2=A0 D= oes this curve really need to be named and specified?

<= div>
On 12 Nov 2021, at 08:42, Stanislav = V. Smyshlyaev <sm= yshsv@gmail.com> wrote:

Thanks, we= 9;ll be looking forward to it.

Regards,
Stanis= lav

On Fri, 12 Nov 2021 at 10:35, Karthikeyan Bhargavan <karthik.bhargavan@gm= ail.com> wrote:
Sorry about this, am pushing my colleague and we=E2=80=99ll get= it done.

On 12 Nov 2021, at 07:= 35, Stanislav V. Smyshlyaev <smyshsv@gmail.com> wrote:

Hi Karthik,

>> We=E2=80=99ll send our review earl= y next week.
The authors keep asking me about the review - could = you please finish it today (it is already later than "early this week&= quot; :) )?..

Regards,
Stanislav

On= Sat, 6 Nov 2021 at 01:55, Stanislav V. Smyshlyaev <smyshsv@gmail.com> wrote:
Thank= you, Karthik!

Regards,<= /div>
Stanislav=C2=A0

On Sat, 6 Nov 2021 at 00:33, Kar= thikeyan Bhargavan <karthik.bhargavan@gmail.com> wrote:
Hi Stanislav,

My colleague and I dropped the ball on this, but have made progress this= week.
We=E2=80=99ll send our review early next week.
<= br>
-Karthik

On= 5 Nov 2021, at 19:27, Stanislav V. Smyshlyaev <smyshsv@gmail.com> wrote:

(CC=E2=80=99ing the second Karthik=E2=80=99s address t= hat I am aware of.)

Kart= hik, please let me know about the status of your review. The authors have a= lready asked us about the status of their review today, so my question to y= ou yesterday was reasonable.=C2=A0

Regards,=C2=A0
Stanislav=C2=A0
=
On Thu= , 4 Nov 2021 at 20:50, Stanislav V. Smyshlyaev <smyshsv@gmail.com> wrote:
Dear Kart= hik,

I may be missing so= mething here, but could you please remind me whether you had sent a review = for that document?..

Reg= ards,
Stanislav=C2=A0

On Wed, 11 Aug 2021 at 17:= 01, Stanislav V. Smyshlyaev <smyshsv@gmail.com> wrote:
In my opinion, it will be abs= olutely fine, taking the=C2=A0size of the document into account.

Thank you, Karthik!

Regards,
St= anislav (on behalf of the CFRG Chairs)

On Wed, 11 Aug 2021 at 16:58, K= arthikeyan Bhargavan <karthik.bhargavan@gmail.com> wrote:
Is 1 month too long a wait?<= br>

On 11 Aug 2021, at 09:52, Stanis= lav V. Smyshlyaev <smyshsv@gmail.com> wrote:

Great, th= anks!

How much time will=C2=A0you need for this (taking = 146 pages into account)=C2=A0
I would like to send a message to t= he authors (CC'ing crypto-panel mailing list).

Regards,
Stanislav

On Wed, 11 Aug 2021 at 16:43, Karthikeyan Bha= rgavan <karthik.bhargavan@gmail.com> wrote:
Sure, I got a request on another thread a = well and can do this (with help from some colleaugues.)

= -K.

On 11 Aug 2021, at 09:39, St= anislav V. Smyshlyaev <smyshsv@gmail.com> wrote:

Karthik,

Can you do a review of this documen= t (as a Crypto Review Panel member)?

Regards,
Stanislav

On Fri, 6 Aug 2021 at 12:46, Stanislav V. Smyshlyaev &= lt;smyshsv@gmail.com= > wrote:
=
Dear=C2=A0Karthik,

Nick, Alexey and I h= ave had some discussion about reviewing the "Alternative Elliptic Curv= e Representations" draft, draft-ietf-lwig-curve-representations-21,=C2= =A0https://datatracker.ietf.org/doc/draft-ietf-l= wig-curve-representations/=C2=A0- may we ask you=C2=A0to do the review = (on behalf of the Crypto Panel)?

Regards,
Stanislav

On Fri, 16 Jul 2021 at 11:50, Stanislav V. Smyshlyaev <= smyshsv@gmail.com> wrote:
Dear Crypto Panel Experts,=C2=A0

We've= obtained a request for review of the version -21 of the "Alternative = Elliptic Curve Representations" draft, draft-ietf-lwig-curve-represent= ations-21,=C2=A0https://datatracker.ietf.org/doc= /draft-ietf-lwig-curve-representations/

The Crypto P= anel (that was my review back then) provided a review of the -00 version th= ree years ago:

The document has changed significantly since t= hen, so the authors ask for a new review.=C2=A0

Th= e chairs would like to ask the Crypto Panel to provide a review (another pa= ir of eyes + reviewing all the changes in the document).

Any volunteers?

Regards,
Stanisla= v (for CFRG Chairs)






--000000000000e349bf05d0d6e4ea--