IETF Logo Mail Archive

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

Benjamin Kaduk <bkaduk@akamai.com> Sat, 06 August 2022 05:15 UTC

Return-Path: <bkaduk@akamai.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 9892EC14F74D for <tls@ietfa.amsl.com>; Fri, 5 Aug 2022 22:15:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.687
X-Spam-Level:
X-Spam-Status: No, score=-2.687 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.582, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_NONE=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=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.com
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 TlC6zkxVWk5a for <tls@ietfa.amsl.com>; Fri, 5 Aug 2022 22:15:49 -0700 (PDT)
Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (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 316FEC14F746 for <tls@ietf.org>; Fri, 5 Aug 2022 22:15:47 -0700 (PDT)
Received: from pps.filterd (m0122332.ppops.net [127.0.0.1]) by mx0a-00190b01.pphosted.com (8.17.1.5/8.17.1.5) with ESMTP id 2763MsMx020346; Sat, 6 Aug 2022 06:15:46 +0100
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=date : from : to : cc : subject : message-id : references : mime-version : content-type : content-transfer-encoding : in-reply-to; s=jan2016.eng; bh=0owEpJsqJjJ7wyCTrF64n2VPZrmofl2bYlAgEilOZP0=; b=aR/0UHTy6vCRt1NF0TfhhC6z4tCS+CYbRuj2AkyAmd0AVblFh98XRrPKHCtVlc1truSW KAqBcKcwCdYCLsdDb1pdOa08Bo6eI/mFBjucDiFTBUrhEI3zQ6jsnz4OrR8XchlXpdf0 XamlKoKyNv0wCnDGpBHQmCaYbgNKEUFXqLDJRlsXPJ8GhLeBx/4abuJKn9iO+QmKFfkl vMDM8PdAsJ4HIge3hwQASTYlqNGywnkZ9DepFyz9dUHX0pGtEo6lPBNycp+o0hLZH6Vw IBz6nV5qb8UT5LUkqnrOrzHkohGW/QMNhS9WLAXPdE556TFh3wFvYofrSiX7DRrRNOW8 gw==
Received: from prod-mail-ppoint1 (prod-mail-ppoint1.akamai.com [184.51.33.18] (may be forged)) by mx0a-00190b01.pphosted.com (PPS) with ESMTPS id 3hsgbjcb0x-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sat, 06 Aug 2022 06:15:46 +0100
Received: from pps.filterd (prod-mail-ppoint1.akamai.com [127.0.0.1]) by prod-mail-ppoint1.akamai.com (8.17.1.5/8.17.1.5) with ESMTP id 2764KuSB003988; Sat, 6 Aug 2022 01:15:45 -0400
Received: from email.msg.corp.akamai.com ([172.27.123.57]) by prod-mail-ppoint1.akamai.com (PPS) with ESMTPS id 3hn00hu2pm-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Sat, 06 Aug 2022 01:15:45 -0400
Received: from usma1ex-dag3mb4.msg.corp.akamai.com (172.27.123.56) by usma1ex-dag4mb7.msg.corp.akamai.com (172.27.91.26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.2.1118.9; Sat, 6 Aug 2022 01:15:44 -0400
Received: from usma1ex-dag4mb6.msg.corp.akamai.com (172.27.91.25) by usma1ex-dag3mb4.msg.corp.akamai.com (172.27.123.56) with Microsoft SMTP Server (TLS) id 15.0.1497.36; Sat, 6 Aug 2022 01:15:44 -0400
Received: from akamai.com (172.19.16.38) by usma1ex-dag4mb6.msg.corp.akamai.com (172.27.91.25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1118.9 via Frontend Transport; Sat, 6 Aug 2022 01:15:44 -0400
Date: Fri, 05 Aug 2022 22:15:42 -0700
From: Benjamin Kaduk <bkaduk@akamai.com>
To: Rob Sayre <sayrer@gmail.com>
CC: Sofía Celi <cherenkov@riseup.net>, "TLS@ietf.org" <tls@ietf.org>
Message-ID: <20220806051541.GQ3579@akamai.com>
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>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <CAChr6SxXVzKptFzDEczOUzVf+LGSNxY=rk45DgXceg_anA_SPQ@mail.gmail.com>
User-Agent: Mutt/1.9.4 (2018-02-28)
X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.205,Aquarius:18.0.883,Hydra:6.0.517,FMLib:17.11.122.1 definitions=2022-08-06_01,2022-08-05_01,2022-06-22_01
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 mlxscore=0 malwarescore=0 mlxlogscore=999 adultscore=0 spamscore=0 phishscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2206140000 definitions=main-2208060028
X-Proofpoint-ORIG-GUID: TOSEw1SDIqgNusGg243Ttz_kBWOhrl7-
X-Proofpoint-GUID: TOSEw1SDIqgNusGg243Ttz_kBWOhrl7-
X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.205,Aquarius:18.0.883,Hydra:6.0.517,FMLib:17.11.122.1 definitions=2022-08-06_01,2022-08-05_01,2022-06-22_01
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 adultscore=0 mlxscore=0 impostorscore=0 clxscore=1011 lowpriorityscore=0 priorityscore=1501 phishscore=0 bulkscore=0 suspectscore=0 spamscore=0 malwarescore=0 mlxlogscore=999 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2206140000 definitions=main-2208060029
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/dlykmLLZl1ZSODA9-4AAwl-o7II>
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 05:15:53 -0000

On Fri, Aug 05, 2022 at 07:16:06PM -0700, Rob Sayre wrote:
> On Fri, Aug 5, 2022 at 5:16 PM Sofía Celi <cherenkov@riseup.net> wrote:
> 
> > There is a notion of being 'quantum annoyant' to a quantum computer:
> >
> 
> I've encountered the term "quantum annoyant" a few times. Is there a
> precise definition that could be referenced? Maybe [0]?
> 
> I don't find the references I know of very satisfying, and I would
> translate "annoyant" to "doesn't actually work".
> 
> thanks,
> Rob
> 
> [0] https://urldefense.com/v3/__https://eprint.iacr.org/2021/696.pdf__;!!GjvTz_vk!S_lXpy5HvfAfDJmtXdME2kuOOLXGTGz07_pqClIgY8ppVcZYu7Cf2WQ0K7YjyyOypKFppMI6NE_C$ 

I think [0] is the reference (or at least very similar content) I've seen in previous discussions of this topic.

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, rather than being able to amortize the cost of running the
quantum computer across many protocol runs that are broken by that computer.
They'd have to be selective about what to decrypt (quickly), rather than just
getting "everything" -- while a QC does provide massive speedups, it does still
take some actual amount of time to run, and we can build protocols so that
the runtime of the QC is a practical constraint on the attacker's ability, even
if it is not necessarily a theoretical constraint on them.

-Ben

v2.23.0 | Report a Bug | By Email