Re: [CFRG] NSA vs. hybrid

Mike Hamburg <mike@shiftleft.org> Thu, 16 December 2021 19:01 UTC

Return-Path: <mike@shiftleft.org>
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 9EB473A0E66 for <cfrg@ietfa.amsl.com>; Thu, 16 Dec 2021 11:01:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=shiftleft.org
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 xONVzDiUP5YS for <cfrg@ietfa.amsl.com>; Thu, 16 Dec 2021 11:01:06 -0800 (PST)
Received: from wanderer.shiftleft.org (wanderer.shiftleft.org [45.79.68.162]) (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 59FE83A0E65 for <cfrg@irtf.org>; Thu, 16 Dec 2021 11:01:06 -0800 (PST)
Received: from smtpclient.apple (c-24-4-232-36.hsd1.ca.comcast.net [24.4.232.36]) (Authenticated sender: mike) by wanderer.shiftleft.org (Postfix) with ESMTPSA id AB748418A0; Thu, 16 Dec 2021 19:01:01 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=shiftleft.org; s=sldo; t=1639681262; bh=PZil0pV+rtGvWKhBGHhc/zYpesH5MFgvysOkVBqc7v0=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=bcxqduQV1A5w4Y1yYKQgfffBEcezKw86Inbq1WObD3guQm/3iNfaEUvnwgqbimQjN p/yfQNTspcAnKmiPMQFAidliuYQKO6iqNqpT3s6lrk3eu47IxKMyYeXP2buyFTLVH/ t4O6zbdamJ44WK/xu8d2TxqEZ8gk6wCoZypuymt4=
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 15.0 \(3693.40.0.1.81\))
From: Mike Hamburg <mike@shiftleft.org>
In-Reply-To: <BC7A43B5-449D-47F1-9230-5AD03D21495D@ll.mit.edu>
Date: Thu, 16 Dec 2021 11:01:00 -0800
Cc: Marek Jankowski <mjankowski309@gmail.com>, Mike Ounsworth <Mike.Ounsworth=40entrust.com@dmarc.ietf.org>, IRTF CFRG <cfrg@irtf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <F814C8C8-2612-4C24-A3FF-0F649F7776C2@shiftleft.org>
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> <BC7A43B5-449D-47F1-9230-5AD03D21495D@ll.mit.edu>
To: "Blumenthal, Uri - 0553 - MITLL" <uri@ll.mit.edu>
X-Mailer: Apple Mail (2.3693.40.0.1.81)
Archived-At: <https://mailarchive.ietf.org/arch/msg/cfrg/7a22v8GW7vy6WNPc45w5NtPkQ-A>
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 19:01:12 -0000

>>  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.

Yes, but this attack requires the attacker to hack you today to steal your non-HSM postquantum keys, and then also come back with a quantum computer in 10 or 20 years to break the classical components (if the HSM resists the attack).  Similarly with side-channels attacks, the attacker must mount the side-channel attack today on your PQC in order to attack you much later.

This is a much more difficult attack model than “slurp up everything on the internet today, and break inteteresting-seeming things later”.

>> 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?

Sure, PQC should eventually go into the secure box, but that may take longer.  This might prevent people who take security very seriously, such that they need HSMs, from deploying PQC.

Cheers,
— Mike