Re: [COSE] draft-prorock-cose-post-quantum-signatures [Was: Re: Call for COSE Agenda Items for IETF 113 in Vienna]

Ilari Liusvaara <ilariliusvaara@welho.com> Tue, 15 March 2022 18:57 UTC

Return-Path: <ilariliusvaara@welho.com>
X-Original-To: cose@ietfa.amsl.com
Delivered-To: cose@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 186A33A15EF for <cose@ietfa.amsl.com>; Tue, 15 Mar 2022 11:57:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.909
X-Spam-Level:
X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=ham 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 86FoPS4HV0S2 for <cose@ietfa.amsl.com>; Tue, 15 Mar 2022 11:57:54 -0700 (PDT)
Received: from welho-filter1.welho.com (welho-filter1b.welho.com [83.102.41.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5F97C3A156B for <cose@ietf.org>; Tue, 15 Mar 2022 11:57:53 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by welho-filter1.welho.com (Postfix) with ESMTP id 9040F22705 for <cose@ietf.org>; Tue, 15 Mar 2022 20:57:51 +0200 (EET)
X-Virus-Scanned: Debian amavisd-new at pp.htv.fi
Received: from welho-smtp2.welho.com ([IPv6:::ffff:83.102.41.85]) by localhost (welho-filter1.welho.com [::ffff:83.102.41.23]) (amavisd-new, port 10024) with ESMTP id K6jUf8BbGFpn for <cose@ietf.org>; Tue, 15 Mar 2022 20:57:51 +0200 (EET)
Received: from LK-Perkele-VII2 (87-92-216-160.rev.dnainternet.fi [87.92.216.160]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by welho-smtp2.welho.com (Postfix) with ESMTPSA id 5DC1D292 for <cose@ietf.org>; Tue, 15 Mar 2022 20:57:50 +0200 (EET)
Date: Tue, 15 Mar 2022 20:57:50 +0200
From: Ilari Liusvaara <ilariliusvaara@welho.com>
To: "cose@ietf.org" <cose@ietf.org>
Message-ID: <YjDhrsAIjM9zVZGS@LK-Perkele-VII2.locald>
References: <SA2PR00MB1002DE43864B01F70546A691F50F9@SA2PR00MB1002.namprd00.prod.outlook.com> <CAN8C-_Jo_-=Jpava0db6BgR4j_BEyZp_3hN6VEv7MJuBwCsPQA@mail.gmail.com> <3053B653-6F26-421F-8498-1002030F3CD8@alkaline-solutions.com> <CAN8C-_JA2fN2HYVjbOjKUBJhJybo0DcLBZJEDoQpMznVi7Pxng@mail.gmail.com> <CAGJKSNRWfK8T4+zk6mF80KUKyndjoKvTvJiUtzD1u9u8_rSecA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <CAGJKSNRWfK8T4+zk6mF80KUKyndjoKvTvJiUtzD1u9u8_rSecA@mail.gmail.com>
Sender: ilariliusvaara@welho.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/cose/dwP6gQ_pjvPRqQ1ppPuJFhe8gBc>
Subject: Re: [COSE] draft-prorock-cose-post-quantum-signatures [Was: Re: Call for COSE Agenda Items for IETF 113 in Vienna]
X-BeenThere: cose@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: CBOR Object Signing and Encryption <cose.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/cose>, <mailto:cose-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/cose/>
List-Post: <mailto:cose@ietf.org>
List-Help: <mailto:cose-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/cose>, <mailto:cose-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 15 Mar 2022 18:57:59 -0000

On Tue, Mar 15, 2022 at 11:16:34AM -0400, Mike Prorock wrote:
> Orie,
> I think other alternative would be:
> kty: PQL        // post quantum - lattice based
> alg: CRYDI3  // crystals dilithium, parameter set 3
> x: public
> d: private

"Lattice-based post quantum" is not a valid key type. It is not a single
key shape (unlike every kty currently defined). And it does not look to
be helpful even working around algorithm dispatch issues in
implementations, as, e.g., Dilithium and Kyber are both lattice post-
quantum algorithms, but wildly different.

If that kty is supposed to be octet-keypair for given alg, that would
be defensible (mixing algorithms for the same key is unsound), but the
name for that kty would not be PQL.

There is also actual security problem with this: Serious cryptographers
are very unconfortable with unhybridized post-quantum algorithms (with
exception of hash signatures) at the moment. Gaining confidence on such
things will take years at the very least.


> and
> kty: PQH       // post quantum - hash based
> alg: SP-SHAKE256-[n]-[w]-[h]-[d]-[k]-[t]  // SPHINCS+, shake256, parameter
> set as noted
> x: public
> d: private

One really should stay away from those parameters and use parameter
sets made by experts, as at least some of those parameters will
absolutely destroy security if set the wrong way.

And "Hash-based post quantum" is also not a valid key type.




-Ilari