Re: [lamps] [EXTERNAL] Re: [CFRG] [pqc-forum] RE: Whether to hash-then-sign with Dilithium and Falcon?

Mike Ounsworth <Mike.Ounsworth@entrust.com> Fri, 19 August 2022 17:56 UTC

Return-Path: <Mike.Ounsworth@entrust.com>
X-Original-To: spasm@ietfa.amsl.com
Delivered-To: spasm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC7F8C1522AB; Fri, 19 Aug 2022 10:56:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.806
X-Spam-Level:
X-Spam-Status: No, score=-2.806 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=entrust.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 VsNpLbF7L5x2; Fri, 19 Aug 2022 10:55:56 -0700 (PDT)
Received: from mx08-0015a003.pphosted.com (mx08-0015a003.pphosted.com [185.183.30.227]) (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 D0A02C14CF17; Fri, 19 Aug 2022 10:55:55 -0700 (PDT)
Received: from pps.filterd (m0242863.ppops.net [127.0.0.1]) by mx08-0015a003.pphosted.com (8.17.1.5/8.17.1.5) with ESMTP id 27J2SwsO028855; Fri, 19 Aug 2022 12:55:42 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=entrust.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=mail1; bh=DPA5EIXQysa6ppe9EY5JXrbyZx8Xsf4bMmKaNno4tfQ=; b=b7pAx915M8FhcX/xAf9kmT/6o8+xXW8i/BA0A2aNtt8ZDaan9dAX2Lgl07jYdM6GwQy1 b9/y0PmsUE/3Y2hNQTd1FGz7KBW74ULcFIsIMve5zxA3zRwbtz3VoAtdX6/EDV9iwHJn 8LHmtIIJH5MhaZaHt7Sj8Ib5rDcQtvi6XKZEaz0BlhYX1S2AT5OS48Z0CmqBvlGMO9aB voir+l59hT6+50nbsBmXK8G+L5CVIVqxKQqm/FR61oLhz5aMNKV1EtusaRfPFTjnAveg w5LREeOFsKJ+d9JzyDf3I5D26lv7wwA1J5AxTL57Jq/1aJsLbBfiHQBLx0ac0EfspWnE SA==
Received: from nam10-dm6-obe.outbound.protection.outlook.com (mail-dm6nam10lp2101.outbound.protection.outlook.com [104.47.58.101]) by mx08-0015a003.pphosted.com (PPS) with ESMTPS id 3hyv2h577q-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 19 Aug 2022 12:55:42 -0500
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=j7HdTVQwVuPL/WPPw4ZpHgaDXE1YIyRyvW6hsJedVlUbXjBMUu167zZZcQFe515dcEWJWQri7WYtHqfDlJpCmPP+PU8D8sE/bTNtpczemAw3PYqvAwrM+YlvIi51BOLFyn0PdQmS6JIUZpNDE4oVK/CCmc6D4Rxewit/hKX5lUgZTqHlnI7/J4F49VADqswEDH0jZ2uUcCf9VdOr6xk1ejU6H59uj/Tsw81VOhl1aDBiJ2ajRLwoPZgwDnYEaPY933m0OkIaOWTApXpyh3GzBzC0R5fO6l2u4KWUXlKhBvURAkYHOVMDVkMTFg3GIwm8Lf6ANRYHldAl6X7gDZsfEw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=DPA5EIXQysa6ppe9EY5JXrbyZx8Xsf4bMmKaNno4tfQ=; b=k0hMB9RZjJWQN/Ml/0wsvY4iJVm8vKi4KZ255pte6jTjHLKySM5oG4lJSEooMevQyjfr4YkbPiMnFzzvCHzPrJBEs+qvFLckLRT5KlYNP8lz8n41vl+p0tAo9NZ2Ssu7BrE4+hplOtai24vvLcZLdPojrM2rx/FxuC9smhkKSfa1HbiGZEgweDgAd7Fe50Q30pe7OhajQi1shRJr5gI1peh2SGA2sMIsvELoh/fY/E6vqURBbulnanPemaKWOh1Wtxy2Kv3njX1mY8NDNRVMjhVHtqTEWixIDbTUau9fikF/VoXr+voYAVbkO/igYj9umYNMCQuQAo889mf4uapSlQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=entrust.com; dmarc=pass action=none header.from=entrust.com; dkim=pass header.d=entrust.com; arc=none
Received: from CH0PR11MB5739.namprd11.prod.outlook.com (2603:10b6:610:100::20) by SN6PR11MB3037.namprd11.prod.outlook.com (2603:10b6:805:d6::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5525.19; Fri, 19 Aug 2022 17:55:38 +0000
Received: from CH0PR11MB5739.namprd11.prod.outlook.com ([fe80::ed02:6e67:98f7:f33d]) by CH0PR11MB5739.namprd11.prod.outlook.com ([fe80::ed02:6e67:98f7:f33d%7]) with mapi id 15.20.5546.018; Fri, 19 Aug 2022 17:55:38 +0000
From: Mike Ounsworth <Mike.Ounsworth@entrust.com>
To: Phillip Hallam-Baker <phill@hallambaker.com>, John Gray <John.Gray=40entrust.com@dmarc.ietf.org>
CC: Tadahiko Ito <tadahiko.ito.public@gmail.com>, "Massimo, Jake" <jakemas=40amazon.com@dmarc.ietf.org>, "Scott Fluhrer (sfluhrer)" <sfluhrer@cisco.com>, LAMPS <spasm@ietf.org>, "cfrg@irtf.org" <cfrg@irtf.org>, pqc-forum <pqc-forum@list.nist.gov>, "Kampanakis, Panos" <kpanos@amazon.com>, "sean@ssn3rd.com" <sean@ssn3rd.com>, "bas@westerbaan.name" <bas@westerbaan.name>
Thread-Topic: [lamps] [EXTERNAL] Re: [CFRG] [pqc-forum] RE: Whether to hash-then-sign with Dilithium and Falcon?
Thread-Index: AQHYs3vm5fRuxucdn0abXx9gnOqOjK22fqSw
Date: Fri, 19 Aug 2022 17:55:38 +0000
Message-ID: <CH0PR11MB5739054876AF545FCA6DEA749F6C9@CH0PR11MB5739.namprd11.prod.outlook.com>
References: <CH0PR11MB5739393F19DD5282E3D7EF549F6A9@CH0PR11MB5739.namprd11.prod.outlook.com> <CH0PR11MB5444B9D3A0CB6E447A2FA3E5C16A9@CH0PR11MB5444.namprd11.prod.outlook.com> <88358933-A540-4000-9C7D-D248F670122F@amazon.com> <CAFTXyYC=Zt0hhk5G2A6b6AOM6Aww7jL3CwUmcZfNpmsWW0cpGQ@mail.gmail.com> <DM6PR11MB2585E47B6D7D92EBC1E71A29EA6D9@DM6PR11MB2585.namprd11.prod.outlook.com> <CAMm+LwiCxwv6smMSL4u+3dnBYWDkStE4pBXh25GKAuaVj+nehg@mail.gmail.com>
In-Reply-To: <CAMm+LwiCxwv6smMSL4u+3dnBYWDkStE4pBXh25GKAuaVj+nehg@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 3028da20-d2df-462a-7ea4-08da820c0651
x-ms-traffictypediagnostic: SN6PR11MB3037:EE_
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: yG3mMn+xOWTkk6eFDwQ8NkuIJvOierXZ5KCbGO2n+S1BiJ7EC9clIi54rMrs8NEHbINaJ3sSzJ00dl/mOjdyU0S3LweS9FuKtBnRClnmjWJo2+T7g1cBVLlLACOBFlIhL+5zWFVIKkFa7jq7wslAuCGf70VFtpzISZllMqispMJCca8iwMpkC5wa6pM+FmO0eUqGpMT5GMNObj4sRnB/XPCcNyNYnOSEXAVw8F8LleSFRbM4c5HozWLtVWHe8molD1BUt/8sPx/5SA0/xEK1d/cGnK6GdYmdPqCI+S19C7OvjD10pwA8fs8AVVZtyil3V4/CJPfMTjOtNhjyOoY9ItdvrrcyEr1O1F5hVZvmT8Rr+NfA14b6ZE2/IMKzmjn9qpcwa4hUUEhItL7nXItT73xGiaxY5HxTkmUW+SEjeYxVDSUA3V5louPWhYcI1LA23sEeSEnG9rtvjyZmDGvjbkUsMC0rT8QvFUyvxD2tJvIFrQ8cQgQJWB17IPUCZ4vneiBE5ZgVfzlxOBNrMf1/6bIbgBjXTaifQM1oqUc128y7T3rX9NBK9MsWBDs8mIw9K8kd/YcLFwOFCWQhwA07Ec+f2uN0pGaTteefYXO9pP6fkVxaW5kp5PmDJwohqoPr7p38VeM5g8DY2HI+pIDsajhlpOlGL2j1XSIgK+67MwhBwziMRrgIWzAGxKy5b65SdqAad8FE4Bu0Fl5sOCYOvhjo3ePIio7g/mjuRSHAglr26NvcIPfjb1sQa/hSKnwOGkmbrXxfNNlpv8GBSGp6Nw==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:CH0PR11MB5739.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230016)(376002)(346002)(396003)(39850400004)(136003)(366004)(5660300002)(55016003)(478600001)(8676002)(71200400001)(7416002)(316002)(110136005)(54906003)(66476007)(41300700001)(66946007)(66556008)(76116006)(4326008)(2906002)(64756008)(8936002)(52536014)(66446008)(86362001)(6506007)(38070700005)(186003)(53546011)(33656002)(7696005)(66574015)(26005)(83380400001)(122000001)(9686003)(38100700002); DIR:OUT; SFP:1102;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: W9GIZGCPSK6zHx7AETPis1vsv470FaPL1KuG1fT03k3TU2Sp8QhaWdwW6TmMf8AxM++EnhvziTWi1wXb1t+IH0MMaeHK+K2UVWu6o5yWspyibB30ybc34uQK9DWMfGU9zlTn6SM5WOk57RdeUsHlBuRyLCOCFkpYjHS7UAGOAMoOb9SwNaQxGitLnv7pB/yvJJgQErcnWNJHgD4xKtNVjT5i5Zxw/dkIWyjhYZ4KyjXu0IfctiDCQjX9WGufLssc9qdIHbAH8USD9RMs7lJSMhqj1JIvX8+9yFCtZzuqz5cG49h5dZq5x5ScIELaqz6b191SP35koO/F+Lb3hdhfgq+qHEVRd+ie/cAFAkGg4AG+9eIxN/bkh+cj0J0KStbikkEQ5En7kAaFhwSzZpuuP+llGNNG0dPx02DFVRsepgekMSgdUSvBiGWGB8aORxxrbl3IrJ9Ah5/jYkt3T5DryQV3FLF+RQVH1crgGy9KQXuJ9eADuSykRSJzfhP1REcdF0tNBQv7ISWnubArgIspNmpnBlWCSkPG8kYfSKUSMRmA/UpH0frT0ek34Imr0yv5EXkz5rZxLF2l64WoENlQ9EtujN0+YvV+vRE8WJ2vaLK0XWN9312JF5/kOm8hKv8EAt3ejxcIvjom59TUEfzVYGbPb+7ezAB5mDq6ejMpeBjlPENpVnCtXhfG2jJ18q/siVQrIZwMqerwbXR2wCyJHI+2v+xLpbDdrLQm//8ta5ES+y7i5hPseIvjYGs+4zQbhT+tKDxSheY6fKZo2v5ANTucHi+S6Cx1Xee7/Mb5Z4uqfrrLS3nDnd5QjC4BZhJn+DMMPvPnL0wQ2eX7/zEdcBwWtQz9dvlqUuo1GuAyBRBuhnz2feIeJ+N9+LymsTdNtunEEReLPtl8avqxkzh69awR12OpPLjv65iQSksJLscrE+FsHIm9VWV+nrXRDTnsRTRG+dRgIjG06wDMcYPCbQfGx5ucwd+vw9BTmlGIWB+1KM4dCeBfHf6SzV7NjnMCBOG/MQxEIWtBrqKW4r3FUPe8ps0N64UyZzklGCh1fdgWC25uFBwzKB7rdX1BM9czmUyABH2KPovUgw30DnzcJm4i49q32KhebUi94KsiinbLetDYDqT3YidwfoBBUQG6UxF1wmck1vOcSOD4x66PGTN/thStYs0sHn6hKd0afCxnUrSRMSSe86gSwdpPH7GEkImvNgkceFCJyooj/b0kX61S9VGWKMSoIiVUwloW/6/4JGs5JDhp+S8La/LwH9dz9SGicUOrYMaCdqH/Royo5tObryL6AQL4LL+ol/yiQOmHpatsc9KieUwNKybSd05sXQZCSWKoe4YhV+uRueP46qpBn5wKychrAmjuaZ+TII9apI9FXmdLBTE7uQ7qRhNuWiD197Jr3W+dl+ukKiZ9E4LG/GiZ71BO6laj9MFqAOnm2xsNb9+9Jm/5e3IR0st/YCTvhifjhrHxk13GPKwyPQEQdE6sanu3E6HiGzhLp+8MG3D6tXBHx+EKdm62twjQ629m+UtobhjnLUcJv2855gPy/jLijVw3pAlKCsEZ76KGt2+Jz3ElcG5fDGnjW7zzla4x2ly0KtRhA091l+BnTA==
Content-Type: multipart/alternative; boundary="_000_CH0PR11MB5739054876AF545FCA6DEA749F6C9CH0PR11MB5739namp_"
MIME-Version: 1.0
X-OriginatorOrg: entrust.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: CH0PR11MB5739.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 3028da20-d2df-462a-7ea4-08da820c0651
X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Aug 2022 17:55:38.3412 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: f46cf439-27ef-4acf-a800-15072bb7ddc1
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: fgh4rVmZ50fIydRREau8sWd2NDt6WQYTEKWtZ/N51QwGxJkD6oV9g38NKh43fCJznTRWrzn/cAb0TgEodOq48A7RqNW+p2z6SlkIWL0HNBs=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN6PR11MB3037
X-Proofpoint-GUID: LvCFG5LqZTwzd3cANRgY0fD33iS1TkBa
X-Proofpoint-ORIG-GUID: LvCFG5LqZTwzd3cANRgY0fD33iS1TkBa
X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.205,Aquarius:18.0.895,Hydra:6.0.517,FMLib:17.11.122.1 definitions=2022-08-19_10,2022-08-18_01,2022-06-22_01
X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 impostorscore=0 clxscore=1011 spamscore=0 mlxlogscore=999 priorityscore=1501 suspectscore=0 bulkscore=0 adultscore=0 lowpriorityscore=0 malwarescore=0 phishscore=0 mlxscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2207270000 definitions=main-2208190066
Archived-At: <https://mailarchive.ietf.org/arch/msg/spasm/i1P-HCBEECzIHPB_t41yJdi9uv4>
X-Mailman-Approved-At: Fri, 19 Aug 2022 11:20:01 -0700
Subject: Re: [lamps] [EXTERNAL] Re: [CFRG] [pqc-forum] RE: Whether to hash-then-sign with Dilithium and Falcon?
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." <spasm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/spasm>, <mailto:spasm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/spasm/>
List-Post: <mailto:spasm@ietf.org>
List-Help: <mailto:spasm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/spasm>, <mailto:spasm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 19 Aug 2022 17:56:00 -0000

Phillip,

> That is not a new issue and it is one that we discussed at great length for RSA. The hash of the digest is part of the signature payload to prevent substitution attacks.


I think you are in fact mistaking the problem that we’re trying to solve / trying not to un-solve. Nobody is suggesting hash downgrade or substitution attacks. As you point out, that is already solved by existing protocols.

Taking Falcon as an example, the problem as I understand it is that the first internal step of Falcon is:

Sign(m):
  r = rand(320);
  c = SHAKE(r || m);
  …
  output (r, s)

Verify(r, s, m):
  c = SHAKE(r || m);


this has the nice property that `r` is generated at signing time by the signer. So should SHAKE develop a collision attack similar to the one we saw for SHA1, then the collision pre-computation as still intractable for the attacker because the attacker cannot not know `r` in advance. (Disclaimer: I am just an engineer trying to wrap my head around this, corrections welcome!).

So the concern with hash-then-sign is that if `m` above is itself a message digest, ie `m = SHA256(M)`, then you have un-done the collision resistance that is built in to the Falcon primitive, essentially reducing the security properties of Falcon. Adding the message digest to the signed content does not help if the attacker is holding two messages with the same SHA256 hash.

My simplified-to-the-point-of-being-wrong understanding is that this would be no worse than what we do with RSA and therefore might be acceptable in some use cases, but it is also ignoring cryptographic improvements beyond RSA.

Disclaimer: this whole email should be viewed as a question that we are seeking confirmation of.

---
Mike Ounsworth

From: Phillip Hallam-Baker <phill@hallambaker.com>
Sent: August 18, 2022 10:29 PM
To: John Gray <John.Gray=40entrust.com@dmarc.ietf.org>
Cc: Tadahiko Ito <tadahiko.ito.public@gmail.com>; Massimo, Jake <jakemas=40amazon.com@dmarc.ietf.org>; Scott Fluhrer (sfluhrer) <sfluhrer@cisco.com>; Mike Ounsworth <Mike.Ounsworth@entrust.com>; LAMPS <spasm@ietf.org>; cfrg@irtf.org; pqc-forum <pqc-forum@list.nist.gov>; Kampanakis, Panos <kpanos@amazon.com>; sean@ssn3rd.com; bas@westerbaan.name
Subject: Re: [lamps] [EXTERNAL] Re: [CFRG] [pqc-forum] RE: Whether to hash-then-sign with Dilithium and Falcon?



On Thu, Aug 18, 2022 at 11:29 AM John Gray <John.Gray=40entrust.com@dmarc.ietf.org<mailto:40entrust.com@dmarc.ietf.org>> wrote:
Thanks Tadahiko,

I read through your paper, and it covers exactly the usability issues we have come across!   We were wondering if it is possible to perform the specific hashing external to the server (which could be an HSM as in your paper, or timestamp server, etc).   For example, for Dilithium the mu := CRH( tr || M) and for Falcon it would be  c <- HashToPoint(r || m, q, n).    Your paper answers that question, it can be done for Falcon, but  not Dilithium (without changing the signature output).   So part of our question is whether using a regular external Hash as we do today for RSA and ECDSA (and what you call a boundary type B) somehow reduces the security and we shouldn’t recommend it.   We are interested in this because we are looking at defining composite pairs or triples which combine existing signature algorithms like RSAWithSHA256 and ECDSAWithSHA256 with Falcon or Dilithium.    Having to change the operational paradigm for an HSM or something like a timestamping server would result in large amounts of data having to be piped across the internet for signatures (as you point out in your paper).

For our composite signature use case it brings up similar questions.   We can support a mode where external hashing is done once, and then individually signed by the components (this makes it much more efficient) both internally and externally for the HSM, timestamping, code signing use-cases.   However, in the case of Dilithium there would need to be two signature modes Sig = Dilithium (Message) and the other would be Sig = Dilithium ( HASH (Message)).   I don’t think that is necessarily a bad thing as long as it is standardized and secure.   Alternatively, we could support independent hashing for each component, but that gets strange if you are doing an external hash for ECDSA, but then need to send the whole data for Dilithium.   We would likely have to end up supporting sending the whole data if external hashing compromises security of the PQC composites, but then it is even more inefficient as each component would need to hash independently.    You also covers this in section 4.3 your paper:

“We can construct type B cryptographic boundaries by adding one more hash function before the execution of PQC’s signature generation algorithm… This approach would improve the efficiency of lattice based digital signature schemes deployed in HSM. It would have a greater impact on Dilithium, but also be applicable to Falcon and other digital signature schemes. Two modes of PQC algorithms utilizing this approach will be able to exist, namely, a PQC algorithm without an additional hash (i.e. original PQC algorithm) and a PQC algorithm with an additional hash. If there are two modes of a digital signature scheme, then the asymmetric operation for those two modes must not be identical. The reason is that, obtaining a signature from the mode with an additional hash function would help attackers who can attack another mode which is without the additional hash function.”

That is not a new issue and it is one that we discussed at great length for RSA. The hash of the digest is part of the signature payload to prevent substitution attacks.

I am finding the description of the problem here to be making assumptions about what 'formal proofs' are demonstrating that are probably demonstrating something else. If you assume there is only one true digest function, you 'solve' the digest substitution problem by pretending it does not exist...


In my view, the signature function should be over the payload and the additional authenticated data. Whether this is the OID of the digest algorithm alone or something more depends on the signature scheme. That is what JOSE etc. have to sort out.

Preventing a digest downgrade attack may be considered the concern of the cryptographic envelope format because there may be more than one form of downgrade attack to be considered. But it is also something we have traditionally included in the signature...


Any email and files/attachments transmitted with it are confidential and are intended solely for the use of the individual or entity to whom they are addressed. If this message has been sent to you in error, you must not copy, distribute or disclose of the information it contains. Please notify Entrust immediately and delete the message from your system.