Re: [CFRG] NSA vs. hybrid

"Blumenthal, Uri - 0553 - MITLL" <uri@ll.mit.edu> Thu, 16 December 2021 17:24 UTC

Return-Path: <prvs=8984959737=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 4622B3A0639 for <cfrg@ietfa.amsl.com>; Thu, 16 Dec 2021 09:24:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level:
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_QP_LONG_LINE=0.001, 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 2vVhFewdedOi for <cfrg@ietfa.amsl.com>; Thu, 16 Dec 2021 09:24:28 -0800 (PST)
Received: from MX3.LL.MIT.EDU (mx3.ll.mit.edu [129.55.12.52]) (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 4E13B3A0644 for <cfrg@irtf.org>; Thu, 16 Dec 2021 09:24:28 -0800 (PST)
Received: from LLEX2019-1.mitll.ad.local (llex2019-1.llan.ll.mit.edu [172.25.4.123]) by MX3.LL.MIT.EDU (8.16.1.2/8.16.1.2) with ESMTPS id 1BGHOO6T412844 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Thu, 16 Dec 2021 12:24:24 -0500
ARC-Seal: i=1; a=rsa-sha256; s=arcselector5401; d=microsoft.com; cv=none; b=Ig20YGFwfqIeh+P/qbCUyv6eEj0liUMhGAeE149ww+NoLCEqDT6HlaxFYCcfvH1vinnccaJ979qmkQzpsNfIP6p3lxFdCGNE9U6u/A4K9kXGjESDDN07VKRdF1QLndc+el9jmZyMHKQg0O9oDKUg6f9Zz1zyWiza6NwaFrTNIY9p6zpiTeTy3U28NbgGNaFnp9xx8o2lZzZatr1PVJk0+FvqVztRu/91ufZfqbHbUwBrlEt7bUSZzzhHYulFH1uLaIhVgphCJKx8MPhqlE4CCTDkQR5GDKjzSdA4X1zuIrsLHB0zJzELia2u2wHM+SqWAB3bSzyalsabpJe1hOdsOA==
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=x9I5LqPcMfjaLjUIIVa7R2R3b8UOhnjkbVvWCJc1tQ4=; b=QdrYRlnuAQgtZzNhaRWXFqhcQ1dJk54OXe0K/UC++NIOVigF6JwisSHdWKzj/r89DWVmBUsmILaMQOEim0+9MFKypmOf8IDmcPXrNFquLDiYoc5cVkPBDW7whJaaOsSt5kN8wog9jrrLkxbmtTp/NJbxh1D5EO99h/5RSRmcxF4WsA7VYZ+gb4NDSWdg87cYLfP004iVdW2BePM2S/3MlU3awRZvRT6PAovv8JaIAvOeAptTdI1/oGWhb+a9e+bHEW+/BaRE16ISRFtFoaMJVWJ1TXpW1a20AMqHciSBEeqPSV32AeKgwyW1FGbbEXaWBaF9DoCzEkzsZpKWrYQlOw==
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: Mike Hamburg <mike@shiftleft.org>, Marek Jankowski <mjankowski309@gmail.com>
CC: Mike Ounsworth <Mike.Ounsworth=40entrust.com@dmarc.ietf.org>, IRTF CFRG <cfrg@irtf.org>
Thread-Topic: [CFRG] NSA vs. hybrid
Thread-Index: Adfq+SifdKkyH8eASvmUsdG8SJfxR///vEKAgABXtID//69qgP//q8fggAC7BgCADwvvAIAAFNgA//+yb4A=
Date: Thu, 16 Dec 2021 17:24:22 +0000
Message-ID: <BC7A43B5-449D-47F1-9230-5AD03D21495D@ll.mit.edu>
References: <BL3PR11MB5732F4B9822A93E08E7E115F9F6D9@BL3PR11MB5732.namprd11.prod.outlook.com> <310998F0-F6A8-46D0-AF14-A85367169396@ll.mit.edu> <e8e80662-ac81-4845-8f8c-64ac81e30890@www.fastmail.com> <E383D80F-D38C-4A6F-9DA6-1BABDA7D8FBF@ll.mit.edu> <BL3PR11MB5732461035F7173FED4A0F309F6E9@BL3PR11MB5732.namprd11.prod.outlook.com> <CAAt2M19XCwuF==rmprejs+5Se5DwGYb4QRifR+__vSNtS0gugg@mail.gmail.com> <CAMCcN7SnApLDOOVu440ghL8dg+L3C193SZzJd=U3t066x_1hZw@mail.gmail.com> <CE910870-EB8D-4845-A42E-962950555EB2@shiftleft.org>
In-Reply-To: <CE910870-EB8D-4845-A42E-962950555EB2@shiftleft.org>
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: d4aa5473-3dea-4e3e-4829-08d9c0b8e6cd
x-ms-traffictypediagnostic: PH1P110MB1618:
x-microsoft-antispam-prvs: <PH1P110MB16186FED5B1385784005723790779@PH1P110MB1618.NAMP110.PROD.OUTLOOK.COM>
x-ms-oob-tlc-oobclassifiers: OLM:8273;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: 6+FhISVRpB9gYmA1BO/svxmoKYK4ArW7M1ZoO0Fs4tLu9Cgrp9QepoXeS43iQZ2StdeeyUhzzQ+LWyonhUSMhgmUw8Bod+GfbzffNNuEdOkO6aC0UDUyJ29meDNGCI5MUccO65OcM+ho2I0fRoSsqAUohZBF2ffmtJGEXor9XXI42wYMJFi69t+qI9cEkOjPCp8J5PNo9LY+nl++r6mErorQQsgzD0Hbt+WSRl+7jB1jI2Q8DVhl1vfpqKfU07SLTPHcfHOChcp6nbVPiumuKgs+3AITkmqI+CkXZnm06j9AwzElspAZuusac4GgrMm4DnRNMQX736l1MnB2GG40PaGYNwth0bgSRMox1T+6jx32Hi7ea7ePJUu5UtEvUL3/vSpTE3o8GSyKEmO9VtJMNAbY69opwf9/FM5w6TeV1GYpw40xOAT3oM4+70qtR1RAGdznokdrvlrC7J30jIcHGg2GLLFVAN73aOmnzZKANfXPo6OaYOtRzgWeQnU3dpsO37VImbcYYATVpIEBLeeFWPwe0NnF9L4tAilHiAs0oSgc6UEgHMhLFXAaYeLxIL57bOfZmy0iMpjfDdwdVYnSzR0BNC7tagT7cZMmViT9Vx6B9teXs1c1K74CLp5RDWQJehaxZfW/53OjMhyHJs5v4VQr363UNc6RWMQVL3b0o25ehj41zgb14o4eQQ9KQJBbkg/XkSnctbnP0j3jaWIwCbEj5OpHMpIPhgAjpFp59qk=
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:PH1P110MB1412.NAMP110.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(366004)(66556008)(5660300002)(4326008)(99936003)(64756008)(38100700002)(6512007)(8936002)(54906003)(38070700005)(66946007)(71200400001)(53546011)(76116006)(6506007)(66476007)(8676002)(6486002)(122000001)(66446008)(966005)(110136005)(316002)(26005)(75432002)(33656002)(2616005)(2906002)(186003)(83380400001)(508600001)(86362001)(45980500001); DIR:OUT; SFP:1102;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: 651bBOTBCX41ouPt0rbrXpP2Vcf/kQoxAwGXuqEZs0QhrsokzL8Voucgn927xdH3eLooFv/0FpeH3AJGBnwmmOKpgutUGZDunfeU9KKWRPo0hEcUBjeJli0o/peFgyW2ZBptF5Q7r0UOorC1BYsE/g==
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha256"; boundary="B_3722502262_635356360"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: PH1P110MB1412.NAMP110.PROD.OUTLOOK.COM
X-MS-Exchange-CrossTenant-Network-Message-Id: d4aa5473-3dea-4e3e-4829-08d9c0b8e6cd
X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Dec 2021 17:24:22.7667 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 83d1efe3-698e-4819-911b-0a8fbe79d01c
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH1P110MB1618
X-Proofpoint-GUID: 6vEoHhJ20ti0KmKC69i9zECFSHI2NQ7v
X-Proofpoint-ORIG-GUID: 6vEoHhJ20ti0KmKC69i9zECFSHI2NQ7v
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.425, 18.0.790 definitions=2021-12-16_05:2021-12-15, 2021-12-16 signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 adultscore=0 bulkscore=0 malwarescore=0 spamscore=0 suspectscore=0 mlxlogscore=783 phishscore=0 mlxscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2110150000 definitions=main-2112160097
Archived-At: <https://mailarchive.ietf.org/arch/msg/cfrg/nMn7T72_s5Zcbt7Y9QPa6l4ldwg>
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, 16 Dec 2021 17:24:34 -0000

> Hybrid cryptosystems would give a modest reduction in the risk of mathematical
> breakthrough, and on its own I’m not sure whether that’s worth the increased
> risk of implementation errors.

I agree 100%.

> However, PQ systems will take a while to be implemented and validated on HSMs,
> and it will take a while to have well-tested defenses against side channel and
> fault attacks. 

Again, I concur. 

Though I doubt we're fully done with side channel attacks against symmetric and Classic, so I doubt we'll be done with side channel attacks against PQ. 

> So if someone needs these features today, they will have trouble migrating
> to a postquantum system.  But they might be able to migrate to a hybrid
> system with the classical part running in the HSM or in a
> side-channel-protected way, if this can be done in a way that’s at
> least as secure as the classical system.

You are saying - "those who now use HSM, can still use Classic part on HSM and add PQ part in software"? I don't think it would be acceptable: if you embrace PQ - the only real reason seems to be that you really don't want your _today's_ data to become exposed (much?) later, when CRQC arrives. In that case, your combination won't work: CRQC would break the Classic part regardless of HSM. And if one does not worry about data lifetime - then there's no reason to add PQ now.

> I don’t know if that’s a controlling consideration, but we should
> at least consider it.

Consideration-wise, I'd say - not for me. If I have a "secure" box that performs crypto computations (you may call it "HSM" ;), then PQ would go there too. 

Makes sense?



On Dec 16, 2021, at 7:47 AM, Marek Jankowski <mailto:mjankowski309@gmail.com> wrote:

I would like to share my opinion regarding the thesis presented bellow, as I think it neglects a major issue which must be taken into account.

On Thu, Dec 2, 2021 at 5:45 PM Blumenthal, Uri - 0553 - MITLL <mailto:uri@ll.mit.edu> wrote:
1.  CRQC arrived, Classic hold against classic attacks,  PQ algorithms hold - Hybrid is useless. 
2. CRQC arrived, Classic hold against classic attacks, PQ algorithms fail - Hybrid is useless. 
3. CRQC arrived, Classic broken against classic attacks,  PQ algorithms hold - Hybrid is useless. 
4. CRQC arrived, Classic hold against classic attacks,  PQ algorithms broken - Hybrid useless. 
5. CRQC doesn’t arrive, Classic hold against classic attacks,  PQ algorithms hold - Hybrid is useless. 
6. CRQC doesn’t arrive, Classic hold against classic attacks,  PQ algorithms broken - Hybrid helps. 
7. CRQC doesn’t arrive, Classic broken against classic attacks,  PQ algorithms hold - Hybrid is useless. 
8. CRQC doesn’t arrive, Classic broken against classic attacks,  PQ algorithms broken - Hybrid is useless. 

The most relevant period to consider is between the emerging of PQC standards and the arrival of CRQC.
According to most estimations, this period will be the next 10-20 years (see Michele Mosca's post here https://open-ecosystem.org/articles/whats-your-risk-quantum-computers).
The above analysis considers only two cases: CRQC will arrive "in the near future" and CRQC will never arrive. This approach neglects the importance of safe and trusted cryptography in this interim period (which is also the migration period).

In this period, those are the possibilities for hybrid usefulness:
1. Classic holds (against classic attacks), PQ holds - Hybrid isn't useful.
2. Classic holds, PQ breaks - Hybrid helps.
3. Classic breaks, PQ holds - Hybrid isn't useful.
4. Classic breaks, PQ breaks - Hybrid isn't useful.

Those possibilities aren't equally likely. Specifically, a classical attack against current classical ciphers seems highly improbable. This means that 3 and 4 are unlikely and shouldn't be meaningfully taken into account.
In this case, 2 is not an unreasonable outcome, which leaves hybridization in an important position.

On Tue, Dec 7, 2021 at 3:01 AM Natanael <mailto:natanael.l@gmail.com> wrote:
PQ algorithms can break in that 1) they get reduced to classical quantum weak security, in which case hybrid won't help but where they still resist classical adversaries.

And 2) they can also break to even classical adversaries, in which case hybrid does help because it's much less likely that the more well established algorithms simultaneously break to classical adversaries. 

I think that this is a valid point as well. Even if 2 happens in a world with CRQC, it leaves us open to quantum adversaries only. Not the best scenario, but better than being vulnerable to every cyber-criminal out there.

Regards,
Marek


On Tue, Dec 7, 2021 at 3:01 AM Natanael <mailto:natanael.l@gmail.com> wrote:

Den tis 7 dec. 2021 02:21Mike Ounsworth <Mike.Ounsworth=mailto:40entrust.com@dmarc.ietf.org> skrev:
I don't think the " PQ algorithms do not hold" case is as absolute as you're claiming:


In cold storage encryption or any kind of public trust signature scenario (ie places where record-now-crack-later doesn't apply):
1) Implementation bugs in either traditional or PQC: hybrid makes these not-immediately-fatal and buys you time to patch and potentially re-protect existing data. (applies to both pre- and post-CRQC scenarios thanks to "quantum annoyance").


In all scenarios:
2) Hybrid (esp. with 3+ algs) allows you to combine multiple PQC algs, spreading out your risk.

And my own main argument, rephrased in the list condensed form;

Most people worry about non quantum adversaries, some worry about both quantum and non quantum adversaries. 

PQ algorithms can break in that 1) they get reduced to classical quantum weak security, in which case hybrid won't help but where they still resist classical adversaries.

And 2) they can also break to even classical adversaries, in which case hybrid does help because it's much less likely that the more well established algorithms simultaneously break to classical adversaries. 

As mentioned before #2 has already been observed. I anticipate to see it happen again. Just because we failed to prevent a quantum attacker it doesn't mean all is lost, because most relevant adversaries for most people are still only classical adversaries. In addition hybrid under #2 raises the cost of performing the attacks. 

As for previous questions from earlier messages on the topic, we did not use hybrid between RSA and ECC because ECC took so long to deploy that by the time it was ready for use it was fairly widely trusted already. In addition, it's fairly meaningless to deploy hybrid between algorithms with fundamentally equivalent hardness assumptions and shared attacks. Hybrid is most useful when the risks are different in between the algorithms of choice. 
_______________________________________________
CFRG mailing list
mailto:CFRG@irtf.org
https://www.irtf.org/mailman/listinfo/cfrg
_______________________________________________
CFRG mailing list
mailto:CFRG@irtf.org
https://www.irtf.org/mailman/listinfo/cfrg