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> Fri, 11 March 2022 15:52 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 7AA133A1717 for <cose@ietfa.amsl.com>; Fri, 11 Mar 2022 07:52:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level:
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 GDDeZxzVn4Zt for <cose@ietfa.amsl.com>; Fri, 11 Mar 2022 07:52:02 -0800 (PST)
Received: from welho-filter4.welho.com (welho-filter4b.welho.com [83.102.41.30]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 40F503A1758 for <cose@ietf.org>; Fri, 11 Mar 2022 07:51:58 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by welho-filter4.welho.com (Postfix) with ESMTP id D4B4B67AB5 for <cose@ietf.org>; Fri, 11 Mar 2022 17:51:55 +0200 (EET)
X-Virus-Scanned: Debian amavisd-new at pp.htv.fi
Received: from welho-smtp3.welho.com ([IPv6:::ffff:83.102.41.86]) by localhost (welho-filter4.welho.com [::ffff:83.102.41.26]) (amavisd-new, port 10024) with ESMTP id Q8scOqxxYr74 for <cose@ietf.org>; Fri, 11 Mar 2022 17:51:55 +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-smtp3.welho.com (Postfix) with ESMTPSA id A7DDA2315 for <cose@ietf.org>; Fri, 11 Mar 2022 17:51:54 +0200 (EET)
Date: Fri, 11 Mar 2022 17:51:54 +0200
From: Ilari Liusvaara <ilariliusvaara@welho.com>
To: cose@ietf.org
Message-ID: <YitwGnqrDy9Fm1YX@LK-Perkele-VII2.locald>
References: <SA2PR00MB1002C64FDF9A7CF14E95D135F50B9@SA2PR00MB1002.namprd00.prod.outlook.com> <a730ecbe-bbc5-2df1-ec60-a43353507b93@gmail.com> <CAGJKSNSY5WdXXRrE-GBi7zgsy69ea8MhPsc0P4X7tNB4=JDRtw@mail.gmail.com> <CAN8C-_+6ydynEFqiKvK2ONw9cwDxDX0F8xBXm4x6awvNfHOnkw@mail.gmail.com> <91bb290a-b109-ae35-6188-44568e44197c@gmail.com> <Yio8lfPQ/fHuxU6f@LK-Perkele-VII2.locald> <CAHrM0e_HOecDRc4CtXsovrQYoj10XVe7aE7fsw4Jg817A00NrQ@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <CAHrM0e_HOecDRc4CtXsovrQYoj10XVe7aE7fsw4Jg817A00NrQ@mail.gmail.com>
Sender: ilariliusvaara@welho.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/cose/oNiybqZQAy64YOQRFkY8p0F4Q5Q>
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: Fri, 11 Mar 2022 15:52:07 -0000

On Thu, Mar 10, 2022 at 03:20:43PM -0500, Rafael Misoczki wrote:
> I'm not quite familiar with kty's and OKP's yet (sorry, I hope to ramp up
> soon) but from a pure crypto perspective, here are my two cents:
> 
> History has shown that anytime we left room for ambiguity in terms of the
> primitive being used, we saw some sort of downgrade attacks in the wild.
> See for example this attack
> <https://www.youtube.com/watch?v=CiH6iqjWpt8&t=1428s> where AES-GCM is
> replaced by the weaker AES-CBC, thus being exploited as an efficient
> padding oracle.
> 
> For PQC, things are even trickier because most of them employ several
> cryptographic building blocks. The choice for these building blocks has
> critical security implications, so I won't consider them "equivalent".  For
> example, SPHINCS+ using SHA256 or the more efficient Haraka are secure but
> I won't be so sure if some other (second pre-image vulnerable) hash
> function is plugged in.
> 
> Again, I'm not very familiar with all the nuances for the kty's design but
> being as specific as possible may have some security benefits.

Yes, in general, using one key with multiple algorithms is crypto-
graphically unsound. Safety would have to be evaluated at case-by-case
basis. That is a reason for any cryptographic key material to state what
algorithm it is intended to be used with. However, Taking this to the
logical conclusion would lead to the ultimate algorithm overload.

And I think that any "hash" function that fails 2nd preimage resistance
is utterly worthless (similarly to any key exchange that fails OW-CONF
security). Fortunately that seems to be extremely rare. I think the last
time any "serious" hash function has failed that way was SNEFRU (1990).
However, even just failing collision resistance is a cause for grave
concern.

And with parametrizing asymmetric primitives, some primitives use
parameters like hash functions in public key derivation. So what
public key goes with what private key depends on hash function. And
this might not change lengths of the fields, so it is possible for
an implementation to try use wrong one.



-Ilari