Re: [CFRG] NSA vs. hybrid

Marek Jankowski <mjankowski309@gmail.com> Thu, 16 December 2021 15:47 UTC

Return-Path: <mjankowski309@gmail.com>
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 7C7AE3A08B7 for <cfrg@ietfa.amsl.com>; Thu, 16 Dec 2021 07:47:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.847
X-Spam-Level:
X-Spam-Status: No, score=-1.847 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, 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 vCnKnHm0gcEM for <cfrg@ietfa.amsl.com>; Thu, 16 Dec 2021 07:47:41 -0800 (PST)
Received: from mail-ed1-x532.google.com (mail-ed1-x532.google.com [IPv6:2a00:1450:4864:20::532]) (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 9A1F93A08B5 for <cfrg@irtf.org>; Thu, 16 Dec 2021 07:47:40 -0800 (PST)
Received: by mail-ed1-x532.google.com with SMTP id t5so88379491edd.0 for <cfrg@irtf.org>; Thu, 16 Dec 2021 07:47:40 -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=BTp7AnXDfn1K1jvjSBFCfVpcPHRDXLBSckjdptrhhWY=; b=FxCJL/7m9OftQaFgQqnxpGXHRijTI7cNYSg0IQDgKMBhPO2olu/QFcOgWjXH4YcFrS qFbeCfmqsxSE4AsY86ycGYgKyHwvIaDUE3p2NgV530jCMZffboj0oE3S30p1jNpb5FEB sBMKmeiuK0AUObN9XnaeRmh430Bulr3k3asoxLb9YidEaKxwfrnpTLAepkDIh4D00nEm qCiDGShXsXAUmHVFYHArNRlWsE06HeD/GjoQkjI1Y2GKm4123hRf3ilUwwL9S1AXlPKC 9eWwav1zgXK7FJKnxYLpz3qnD0d7bE8A/i5HGVShxBQhWoJKgK8o6ZkywYmDgH5VML6g snBg==
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=BTp7AnXDfn1K1jvjSBFCfVpcPHRDXLBSckjdptrhhWY=; b=aCgUmixdefLWKLxGnkp4gVFzbwoYDFxYQL2uQS3pMXBJpF8whNkqzPtS22FAFl/QWX aLOct3S448H8237khuPH0xf9oEjUldvF4xeGA1pKx9BJUAOyQzH7AJYMcfMAbgCJQC8/ kxlcOLfD/Al7BipBG49oeUY2qxv40O3F/OBOxJdDEmygHJPnSs2L6AczKkR/7aj5+/Vk Zgz/iWBl0JQXKcEIZxD/uI4fSH7X04tYi+/ziyBsHqAoBimRmUhIVTV0lZWivMvxdixp b0M7yz5K2Aqj8SJOEV1claYS7Cw+0pnarzkhEIUMD2MadrOGkjlG5PPMQXF6h2vHRxXS r3Ng==
X-Gm-Message-State: AOAM531Y0Go56ObQVLtMEF6/mlnCxRY6vB2JwQCkDJItNLVgc8eGzK7L RygoNI/TYX9EIAxp2adPeQ9ohGreyRpx04ToN+I=
X-Google-Smtp-Source: ABdhPJzxYTSpXt5IFnssyQoxtCF5feXF8fbQq+uuHtMWwwvhKscR/tgnCLiUOGHio+r5Qug5YhleJV3VvwCtOyepuDY=
X-Received: by 2002:a17:906:c17:: with SMTP id s23mr15984121ejf.715.1639669654042; Thu, 16 Dec 2021 07:47:34 -0800 (PST)
MIME-Version: 1.0
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>
In-Reply-To: <CAAt2M19XCwuF==rmprejs+5Se5DwGYb4QRifR+__vSNtS0gugg@mail.gmail.com>
From: Marek Jankowski <mjankowski309@gmail.com>
Date: Thu, 16 Dec 2021 16:47:22 +0100
Message-ID: <CAMCcN7SnApLDOOVu440ghL8dg+L3C193SZzJd=U3t066x_1hZw@mail.gmail.com>
To: Natanael <natanael.l@gmail.com>, IRTF CFRG <cfrg@irtf.org>
Cc: Mike Ounsworth <Mike.Ounsworth=40entrust.com@dmarc.ietf.org>
Content-Type: multipart/alternative; boundary="0000000000004739ef05d34557d9"
Archived-At: <https://mailarchive.ietf.org/arch/msg/cfrg/WNFDVdj_tBtBNnF2OCMcGhvou-8>
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 15:47:46 -0000

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 <
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 <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 <natanael.l@gmail.com> wrote:

>
>
> Den tis 7 dec. 2021 02:21Mike Ounsworth <Mike.Ounsworth=
> 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
> CFRG@irtf.org
> https://www.irtf.org/mailman/listinfo/cfrg
>