IETF Logo Mail Archive

Re: [TLS] Before we PQC... Re: PQC key exchange sizes

Phillip Hallam-Baker <ietf@hallambaker.com> Sat, 06 August 2022 17:00 UTC

Return-Path: <hallam@gmail.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1FD8C157B4B for <tls@ietfa.amsl.com>; Sat, 6 Aug 2022 10:00:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.428
X-Spam-Level:
X-Spam-Status: No, score=-1.428 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.248, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.248, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iVoZllx4Rq-a for <tls@ietfa.amsl.com>; Sat, 6 Aug 2022 10:00:09 -0700 (PDT)
Received: from mail-oo1-f42.google.com (mail-oo1-f42.google.com [209.85.161.42]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E2B67C157B37 for <tls@ietf.org>; Sat, 6 Aug 2022 10:00:09 -0700 (PDT)
Received: by mail-oo1-f42.google.com with SMTP id u7-20020a4a8c07000000b00435ac1584a6so968383ooj.1 for <tls@ietf.org>; Sat, 06 Aug 2022 10:00:09 -0700 (PDT)
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=Ssan2EU9apNpxCk+dsdBE5ps5ObuNz9a1kbD7lQlfiI=; b=Quq7wZ2gHjQ+2XJiwY8dp+NjIbXwt3CneZ86ztkd4JDV7DFj+34ylOtLKodO/3cUsk wIrohrud6yVjy7v9qlJWpLZxnFGkvVYVqxtsBaqRlGaHs1gsiY2WAnYIQIIlj9ig1Dnx CruAs7nZ3/XNzdbaGiY2xwnrW15Hcq8dGq3Q3LF80iHJXfWcVv/Hs9VJpIsTJlFeEpZY ktAeHB1pKWl4U0bby+yifWS833HvC59ekbt9kuSQ7CVdXWUTED4wyJZmHvDLYRDiB57T q/Kn/pE+kmb+FbGqDwv1nYCJvLlrv/ir2iFOfISsVdcBEUGaN4ERn0pVYFT+gcgyJpBs fJiw==
X-Gm-Message-State: ACgBeo2vIsqZqbLKwoktSu5cgfDyODSSwJnyWMi1pnFWE8u3Wdby2Oe+ tk95hxTX5eU0zuzkMd5EG99vo/tTHiFi9w5hebkfBJrPF4M=
X-Google-Smtp-Source: AA6agR6zWaerJMAjrroaQHKtdfkmKDMRg+2I9ZKjH4qXjfrfAGpwHK/CqtGJihrg12yq8yE4e56UhsjQkhxPyUrTGjo=
X-Received: by 2002:a4a:be06:0:b0:435:8b69:e35b with SMTP id l6-20020a4abe06000000b004358b69e35bmr4258720oop.78.1659805209060; Sat, 06 Aug 2022 10:00:09 -0700 (PDT)
MIME-Version: 1.0
References: <CABzBS7nsbEhR-bmHG_ViSJFSH-0_5p0O3vKndS4+wFR=iGQzhw@mail.gmail.com> <CAMm+LwgAzb4t=awzpU4Sb5j7Bf6DuR3u+23n+h_C3Pnsin-SHg@mail.gmail.com> <8383756C-5595-4028-9E5E-8B758147ED33@ll.mit.edu> <CAMm+LwgHNL_aHqK+TbdBf=xJBPftjkXL_=isXUJB+mbiUc7_Lw@mail.gmail.com> <58778bee-ccd8-3b6b-cdf3-7392cd6f3187@riseup.net> <CAChr6SxXVzKptFzDEczOUzVf+LGSNxY=rk45DgXceg_anA_SPQ@mail.gmail.com> <20220806051541.GQ3579@akamai.com> <CAChr6Sy3vGbcDCDXWOGNwLQgwZZG_z3HTSgz54Ch2_vurF++RA@mail.gmail.com>
In-Reply-To: <CAChr6Sy3vGbcDCDXWOGNwLQgwZZG_z3HTSgz54Ch2_vurF++RA@mail.gmail.com>
From: Phillip Hallam-Baker <ietf@hallambaker.com>
Date: Sat, 06 Aug 2022 12:59:58 -0400
Message-ID: <CAMm+Lwj19zmbPo+53Zk8m3AOWPGF8mhyB9SPTVP7mP0DsWpPzQ@mail.gmail.com>
To: Rob Sayre <sayrer@gmail.com>
Cc: Benjamin Kaduk <bkaduk@akamai.com>, "TLS@ietf.org" <tls@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000e1eab505e59583b1"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/MgwuBXO-cEz-LKryZnWFvs5pDeY>
Subject: Re: [TLS] Before we PQC... Re: PQC key exchange sizes
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 06 Aug 2022 17:00:11 -0000

OK so how about this:

Quantum Annoyance: Using classical cryptography in ways that maximize the
number of quantum processing cycles to attack.
Quantum Hardening: Using PQC in parts of a system to prevent QCC resulting
in a breach of stored data or communications.
Quantum Secure: Using PQC in all parts of a system so that every security
property is maintained against QCC.

We have a triad!

We really should not reject Quantum Annoyance out of hand because it can be
very powerful. Nobody can decrypt data they didn't store. The result of the
TLS everywhere campaign is that the amount of encrypted data whizzing about
the planet is in the Petabytes and there is absolutely no way anyone can
store all of it if it is all encrypted under different keys.



On Sat, Aug 6, 2022 at 7:01 AM Rob Sayre <sayrer@gmail.com> wrote:

> On Fri, Aug 5, 2022 at 10:15 PM Benjamin Kaduk <bkaduk@akamai.com> wrote:
>
>>
>> It's annoying to the attacker when they have to use their expensive and
>> finicky
>> hardware once (or multiple times) for each individual message/exchange
>> they
>> want to break,
>>
>
> Well, I can agree with the term "expensive", but I'm not sure what you
> mean by "finicky". Are you saying they only work sometimes? It seems a bit
> hand-wavy to say that.
>
> I've seen quantum computers before. They are room-sized, but not that big.
> I still find the term "quantum annoying" rather imprecise.
>
> thanks,
> Rob
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>

v2.23.0 | Report a Bug | By Email