Re: [CFRG] NSA vs. hybrid

"Blumenthal, Uri - 0553 - MITLL" <uri@ll.mit.edu> Thu, 02 December 2021 12:55 UTC

Return-Path: <prvs=897035456e=uri@ll.mit.edu>
X-Original-To: cfrg@ietfa.amsl.com
Delivered-To: cfrg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5CBE3A10BF for <cfrg@ietfa.amsl.com>; Thu, 2 Dec 2021 04:55:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.895
X-Spam-Level:
X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 nwZI8eWgrf3q for <cfrg@ietfa.amsl.com>; Thu, 2 Dec 2021 04:55:12 -0800 (PST)
Received: from MX2.LL.MIT.EDU (mx2.ll.mit.edu [129.55.12.51]) (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 F3F263A10A3 for <cfrg@irtf.org>; Thu, 2 Dec 2021 04:55:11 -0800 (PST)
Received: from LLEX2019-2.mitll.ad.local ([172.25.4.124]) by MX2.LL.MIT.EDU (8.16.1.2/8.16.1.2) with ESMTPS id 1B2Ct92u415919 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for <cfrg@irtf.org>; Thu, 2 Dec 2021 07:55:09 -0500
ARC-Seal: i=1; a=rsa-sha256; s=arcselector5401; d=microsoft.com; cv=none; b=MsrRdbYs2L4Geg04i38mmtQhdPafr02g648iDefNGC+vqBRNvm3nkLFnICN1E3bUmLQeVFvEuUHGzgBKMweFXqw8P+lhRNxT1Av67U5dDIfTkY3mxX5afIWCZ7DJF1p2VC+L+GoaQ5u+Qn2LRmICpEz4reHdhrpr0X6H8zYcsP/nTW9Oy68cTRA3q3O1SKTWxLCzJJn54ExcvuWXQeHB1cLe5Ck3hyXsBaxOtrsOn69zzJQuDJlUOGd6LuV7BR2/e1yv2eld+MgqBkihtbM1AEhFnH3dBmLMGaqI8w+aKMXZhx2r1iXc0UKjUUwZ85uLlyN4QRtmi8T7wFuQcFI6kA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector5401; 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=tWIDQ6e+T6q1DPDDx2rao5+SLfkjWknVQ3Co87M/qrY=; b=hcf1Wga0+g6XBAwujrRsnFQ3koVYArE6JqjyrUjaUIbnqySOhV6qomPYfDL8qGLZo625V6OpJ927RyNl6UplX7lrAEJdeMQ5t/Qws0AJQTMULIaR12GLYuSeouF8YxcrnCdBHwksOE6d5fIT7ugZEdQy0K+xfDEPhEgy2nQlq0AWO6xBC4YJ5yWCEnQIkNBw4T454wtcTEbov8/fApyMcqKqnJ66f65Eb6icig2ceTnzbZ4PWoWwHfWn43HNEHjJH3Zo+uxWaM7jv2O/kwmUEDH0ejN6FJqGpcNBaQUU/XIsiS1Enf5Xb98hqDcN3uA0iUjo1w2N3OyqPvibYIQw4A==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ll.mit.edu; dmarc=pass action=none header.from=ll.mit.edu; dkim=pass header.d=ll.mit.edu; arc=none
From: "Blumenthal, Uri - 0553 - MITLL" <uri@ll.mit.edu>
To: "cfrg@irtf.org" <cfrg@irtf.org>
Thread-Topic: [CFRG] NSA vs. hybrid
Thread-Index: AQHX16fXW9d+W2Z8cUihngZecK0bMawJon4AgBWL0AD//8Y4gA==
Date: Thu, 02 Dec 2021 12:55:06 +0000
Message-ID: <D598FD2A-A2F3-4B91-9F11-70412E17D7A8@ll.mit.edu>
References: <20211112092811.628364.qmail@cr.yp.to> <9588651a323a489e8e4956e08a64b55f@blackberry.com> <CAMCcN7TmFuu-msYvmWDV=c3R=Vxyg9MBV++o3BfVDHEj8i3NmA@mail.gmail.com>
In-Reply-To: <CAMCcN7TmFuu-msYvmWDV=c3R=Vxyg9MBV++o3BfVDHEj8i3NmA@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/16.54.21101001
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 3750c5f7-1d85-4e5d-152e-08d9b592f748
x-ms-traffictypediagnostic: CY1P110MB0807:
x-microsoft-antispam-prvs: <CY1P110MB08073A654C9C764B7CBB840590699@CY1P110MB0807.NAMP110.PROD.OUTLOOK.COM>
x-ms-oob-tlc-oobclassifiers: OLM:9508;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: MhHQy/F/r66jXiVjwONlakrvks56sfflioZk7pO+xaKuogTuH9gF1uPiJ3agvfWhspow3ifspxEnPkAAoDdIbFQ/x7hDq4vqUHEDv8ut26QoIrpDhGSbhBqSkZ1VArmrJhSQcrSEUElkROysVUScMW4JYBh9g1aPcdR4o1Is2ko8t6YMEO/CuZ1Kt6J/Jv3vXaZHpKwvFCObgoQXgJmH8TvA0GRJq6HzwJBXmv1xOePOHECgkSnNzhmLlQ3zDpRKkCHDptyPh4XyWmGTrf8Mwt0F3qRVbE3+rNc4Fvu+Xg0jSQIdhNcM2SSpvCjG0ixQLF/K+l24UhyNNmCxBhlQXPCIFcmkev85w5dZbobr3F5yjEWZpgvL/Tc8TTwyWdawtuYK52NgYN7qnDL2fh0FEAtubF7IZ7n0Ux5OS1W0e636pQQlASguNw6d+wp7RkW+F+IgIHa7l8UhHpSlgVWHh6X0ZKymtZOxPYKiAUbuTmrAcny+fS0wuxd9Q19GYyDL6g2cgGcicMmixiSyplKe0TI3TCNhGah4k2oLisCEa/tBqLjX01DMKePtHIhN1CI1Nn+O0hTGmjNn8WbZPacYdNrmaecaB+wfXd+0WMYLeNaHqG+wHTopStwIqyRnO5756Wfy+KfDt+JovZK8diCBHMm4d+ZaHPcbwDB47GsVDBWV3sbpUxN1lp548+bfU1O9sESxEc4n31Pn2ESEP8f+uEVZXJ1h0E8wv/UJP1pQCiU=
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:CY1P110MB0616.NAMP110.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(366004)(99936003)(498600001)(38070700005)(8936002)(38100700002)(122000001)(6512007)(8676002)(53546011)(5660300002)(6506007)(33656002)(2906002)(66946007)(66476007)(83380400001)(6486002)(26005)(76116006)(86362001)(186003)(66556008)(75432002)(2616005)(166002)(966005)(6916009)(71200400001)(64756008)(66446008)(45980500001); DIR:OUT; SFP:1102;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: e/B43xQ0gv2/wC50MpG2kvg0PEmoPt1iSbS7FmUnxPT7R6FfBn2/fN+bFWZFXfettBGJO+8DeQ0W6FlEnAxSGHLP+Saqox9UT91lomgx84LC+Q5UkXIDBr+JzMjehYOZs9lU0HVgwoD2O15ianbxLA==
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha256"; boundary="B_3721276506_2043136471"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: CY1P110MB0616.NAMP110.PROD.OUTLOOK.COM
X-MS-Exchange-CrossTenant-Network-Message-Id: 3750c5f7-1d85-4e5d-152e-08d9b592f748
X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Dec 2021 12:55:06.6335 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 83d1efe3-698e-4819-911b-0a8fbe79d01c
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1P110MB0807
X-Proofpoint-GUID: LTH-Q775_G7OwzR0fCOF1TeBvmu3gVs-
X-Proofpoint-ORIG-GUID: LTH-Q775_G7OwzR0fCOF1TeBvmu3gVs-
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.425, 18.0.790 definitions=2021-12-02_07:2021-12-02, 2021-12-02 signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 mlxscore=0 phishscore=0 bulkscore=0 mlxlogscore=999 suspectscore=0 adultscore=0 malwarescore=0 spamscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2110150000 definitions=main-2112020082
Archived-At: <https://mailarchive.ietf.org/arch/msg/cfrg/pYtwT6UmceatI11JgsmggRCaROc>
Subject: Re: [CFRG] NSA vs. hybrid
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Crypto Forum Research Group <cfrg.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/cfrg>, <mailto:cfrg-request@irtf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/cfrg/>
List-Post: <mailto:cfrg@irtf.org>
List-Help: <mailto:cfrg-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/cfrg>, <mailto:cfrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Thu, 02 Dec 2021 12:55:18 -0000

NIST did not invent the finalists – some of them have more than two decades of research behind them. Situation looks comparable to that with RSA and ECC when those algorithms were brought into standards.

 

Thus, I do not support the Hybrid approach.

--

Regards,

Uri

 

There are two ways to design a system. One is to make it so simple there are obviously no deficiencies.

The other is to make it so complex there are no obvious deficiencies.

                                                                                                                                     -  C. A. R. Hoare

 

 

From: CFRG <cfrg-bounces@irtf.org> on behalf of Marek Jankowski <mjankowski309@gmail.com>
Date: Thursday, December 2, 2021 at 06:23
To: Dan Brown <danibrown@blackberry.com>
Cc: CFRG <cfrg@irtf.org>, "D. J. Bernstein" <djb@cr.yp.to>
Subject: Re: [CFRG] NSA vs. hybrid

 

Joining Dan, I too believe that the vetting of PQC algorithms should originate in a public process, and that NIST has not yet proven we should rely on the finalists alone. I find it important that CFRG advise upon hybridization both in KEMs and signatures, although I don't have a strong opinion in the composite vs multi-certs debate.
In the same context, I worry that not having a FIPS standard for Ed25519, the result of FIPS 186-5's publication being delayed, might cause a delay in adoption of PQ+EC hybrid signatures. CFRG should address this issue and take a proactive stance towards NIST by engaging in discussions regarding the publication of FIPS 186-5 as well as PQC and hybrid standards later on.

Best regards,
Marek

 

On Thu, Nov 18, 2021 at 7:20 PM Dan Brown <danibrown@blackberry.com> wrote:

> D. J. Bernstein wrote (on Friday, November 12, 2021 4:28 AM)
>  ...
> I would like to see CFRG instead advising integration of ECC into all post-
> quantum deployments for the foreseeable future. There's no reason that this
> advice has to wait for NISTPQC standards.
> ...

I largely agree with the point above (as some might recall from my past CFRG 
messages).

Hybrid cryptography in IETF ought to be encouraged by CFRG. At minimum, hybrid 
ought to be an option for sensitive applications (high-value data, needing 
long-term protection), where the cost seems worth the benefit.  As an 
exception, an IETF WG with low-value, short-term data and little budget for 
cryptography, might opt for a single non-hybrid PQC algorithm option.

Real-time authentication (e.g., signature-based server authentication in TLS), 
might have less risk than other applications (e.g., TLS key exchange), because 
new attacks discovered in the future (e.g., relevant quantum computer) cannot 
retroactively break today's real-time authentication. Nonetheless, hybrid
signatures may still be worth the cost?

For certificate structuring, I don't know which is better: (1) certificates 
with hybrid-signatures, or (2) multiple certificates with a single-algorithm 
signatures (or (3)=(1)+(2)), but CFRG could contribute significantly to a 
recommendation on this issue (e.g. comments already made in this thread). 
Perhaps CFRG should defer this more protocol-specific detail to LAMPS?

Organizationally, NIST and IETF could continue to have some interoperable 
cryptography options, while working independently on non-interoperable 
cryptography options (i.e., hybrid interoperability ;).

Best regards,

Dan

PS. A simplistic cost-benefit approach to choosing hybrid cryptography:
https://eprint.iacr.org/2021/608
Better methods ought to be possible.   A discussion on this at
https://groups.google.com/a/list.nist.gov/g/pqc-forum/c/OpFVbuMYk8c


----------------------------------------------------------------------
This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.
_______________________________________________
CFRG mailing list
CFRG@irtf.org
https://www.irtf.org/mailman/listinfo/cfrg