Re: [lamps] Whether to hash-then-sign with Dilithium and Falcon?

"Scott Fluhrer (sfluhrer)" <sfluhrer@cisco.com> Wed, 17 August 2022 17:50 UTC

Return-Path: <sfluhrer@cisco.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 8458EC1522AA for <spasm@ietfa.amsl.com>; Wed, 17 Aug 2022 10:50:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.606
X-Spam-Level:
X-Spam-Status: No, score=-14.606 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, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=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, USER_IN_DEF_DKIM_WL=-7.5] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=MspbmURL; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=tWWWsI+1
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 MpZkpjEJNouu for <spasm@ietfa.amsl.com>; Wed, 17 Aug 2022 10:50:13 -0700 (PDT)
Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7EDC4C1524B1 for <spasm@ietf.org>; Wed, 17 Aug 2022 10:50:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8474; q=dns/txt; s=iport; t=1660758613; x=1661968213; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=vHRx7hlGtNp0GAdTkmaqMYNKkfRiZG3FYSq7xL3sPz4=; b=MspbmURLnW8aLAefGPiVxlYn6M5VPq797vwKMgqXG+zJoTffCQQlPX6H ruNVkdcbCOVdCxMWyXV9o+hEeBl+Wopk5ji1UGiZEHsag3o1ojQIPM+Kn 0yDvbaxiviFi4p7J1tnd+HwXS+vzMCvWgJrQGfRBZkTZaB6hrkE6KKopC o=;
X-IPAS-Result: A0BgAgAaKf1imIgNJK1agQmDIVJ/XDpFhE6DTAOFL4UMXYIlA5tTglEDVAsBAQENAQFCBAEBgVODNAIWhGMCJTgTAQIEAQEBAQMCAwEBAQEBAQMBAQUBAQECAQcEFAEBAQEBAQEBHQcGDAUOECeFaA2GQgEBAQECARIREQwBATgEBwQCAQgRBAEBAwImAgICMBUICAEBBAESCAwOgluCbgMNJQMBnBUBgT8Cih96gTGBAYIIAQEGBASFERiCOAmBESyDJYRggyCBb4IzJxyBSUSBFUOCNzA+hEaDVDeCLo0IjBYcNwNFHkIDC1IICRcSEBACBBEaCwYDFj0JAgQOA0AIDQMRBAMPGAkSCBAEBgMxDCULAwUPDAEGAwYFAwEDGwMUAwUkBwMZDyMNDQQYBx0DAwUlAwICGwcCAgMCBhUGAgIYNjkIBAgEKyMPBQIHLwUELwIeBAUGEQgCFgIGBAQEBBUCEAgCCCcXBxMzGQEFWRAJIRYGDhoKBgUGEwMgSSYFRQ8oMgE1PBASCR8bCoESKgkgFQMEBAMCBhMDAyICEC4xAxUGKRMSLQcrdQkCAyJpBQMDBCgsAwkgBBwHCSImPQUFXxIoAQQDAxMiLZlqETxrA4FOHSsCBgIYBhgBKAYcEZYIilefL4ExCoNSmR2HIRaEP6QtlwIgohKEfgIEAgQFAg4BAQaBeCOBW3AVO4JnURkPjisOCYNQiiEBPHU7AgYLAQEDCYsBAQE
IronPort-PHdr: A9a23:17IYmREqgqpV5cF5gZD2BZ1GfiYY04WdBeZdwpYkircbdKOl8tyiO UHE/vxigRfPWpmT8PNLjefa8sWCEWwN6JqMqjYOJZpLURJWhcAfhQd1BsmDBAXyJ+LraCpvG sNEWRdl8ni3PFITFtz5YgjZo2a56ngZHRCsXTc=
IronPort-Data: A9a23:H8LwDaDJwouqQRVW/93jw5YqxClBgxIJ4kV8jS/XYbTApGt2gz1Vx moXCzuOM/iKY2OjeYp1Pd6w/BhQ6paEztZrOVdlrnsFo1CmBibm6XV1Cm+qYkt+++WaFBoPA /02M4WGdIZuJpPljk/F3oLJ9RGQ7onVAOunYAL4EnopH1U8GH5+0UsLd9MR2+aEv/DoW2thh vuqyyHvEAfNN+lcaz98Bwqr8XuDjdyq0N8qlgVWicNj4Dcyo0Io4Kc3fsldGZdXrr58RYZWT 86bpF2wE/iwEx0FUrtJmZ6jGqEGryK70QWm0hJrt6aebhdqnwwK2ZgACeggU1pdrWuYtvF1l YRvjMnlIespFvWkdOU1Wh1cFWR1OrdLveSBKnmkusvVxErDG5fu66wxVwdtY8tBoaAuWj8mG f8wcFjhajiYiearwKi2UMFnh98oK4/gO4Z3VnRInGmFVa5+HsCdK0nMzeBbjRIRjO5EJKz9R 8YcSmBEZ07qTCQabz/7D7pnzLv32RETaQZwoluOjbU6+HTe1gZ42b6rNtPQd7SiXshcmG6Dv WSd5Wi/CRYfXPSc0TOD9WmEj+rGjyT9HokVEdWQ9PdpjVia3UQaDRQEUl39qv684mamQtkaJ UsO5y8Gqakp6AqtT8LhGRK/vhastRAGVPJRCfE0rgaXxcL8+B6QHW0sTzNdZpohrsBeeNAx/ laNm9WsDjt1vfjOD3mc7byT6zi1PED5MFPuewc9bTMO3eLesr0JkxjpEMdKMaro3//MTGSYL y+xkAAygLAajMgu3qq9/Ezajz/EmnQvZlNujukwdj/4hj6VdLJJdKTzsgGCsqgowJKxCwjf4 idVwqBy+chUVfmweDqxrPLh9V1Dz9+BNDDa6bKEN8Z8r232k5JPkHw53d2TDE5tNsBBcjjzb QqI/whQ/5RUenCtaMebgr5d6ex3ncAM9vy8C5g4i+aihLArK2drGwk1PyatM5jFyhRErE3GE c7znTyQJXgbE7976zG9Wv0Q17Qmrghnmz2LG8+nkU73juHADJJwdVvjGAbeBgzexP7UyDg5D /4CXyd340wFCbanMnW/HXA7dApWdBDX+qwaW+QOJrLcfWKK6UkqCuTaxvs6apd5kqFO/tokD VnjMnK0PGHX3CWdQS3TMygLQOq2Af5X8CNgVQRxbAnA8yZ4O+6HsvxAH6bbiJF6roSPO9YuE alcEyhBa9wSIgn6F8M1NsWl9d0yKUjz7e9MVgL8CAUCk1dbb1Sh0rfZksHHrUHi0gLfWRMCn oCd
IronPort-HdrOrdr: A9a23:FDH/p628yzFMsXIsjGGQNQqjBQ9yeYIsimQD101hICG9Lfb3qy n+ppsmPEHP5Ar5AEtQ5OxoS5PwPU80kqQFrLX5XI3SFjUO3VHIEGgM1/qa/9SNIVydygcZ79 YbT0EcMqy9MbEZt7eD3ODQKb9Jq7PrkNHKuQ6d9QYXcegAUdAF0+4NMHf8LqQAfnggOXNWLu v42uN34x6bPVgHZMWyAXcIG8LZocfQqZ7gaRkaQzY69Qinl1qTmfHHOind+i1bfyJEwL8k/2 SAuRf+/L+fv/ayzQKZ/3PP7q5RhMDqxrJ4dYKxY4kuW3TRYzSTFcdcso65zXIISSaUmRMXee z30lcd1gJImjfsly+O0FzQMkLboUkTAjfZuCGlaD3Y0IrErPZQMbsYuWqfGSGpsnbI9esMoZ 5jziaXsYFaAgjHmzm479/UVwtynk7xunY6l/UP5kYvGLf2RYUh2rD3xnklZqsoDWb/8sQqAe NuBMbT6LJfdk6bdWnQui1qzMa3Vno+Ex+aSgxa0/blmAR+jTR81Q8V1cYflnAP+NY0TIRF/f 3NNuBtmKtVRsEbYKphDKMKQNexCGbKXRXQWVjiaWjPBeUCITbAupT36LI66KWjf4EJ1oI7nN DbXFZRpQcJCjbT4A21reh2Gzz2MRaAtG7Wu7FjDrBCy8/BeIY=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.93,243,1654560000"; d="scan'208";a="904000786"
Received: from alln-core-3.cisco.com ([173.36.13.136]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 17 Aug 2022 17:50:12 +0000
Received: from mail.cisco.com (xfe-rtp-004.cisco.com [64.101.210.234]) by alln-core-3.cisco.com (8.15.2/8.15.2) with ESMTPS id 27HHoBPP009095 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=OK); Wed, 17 Aug 2022 17:50:12 GMT
Received: from xfe-rtp-004.cisco.com (64.101.210.234) by xfe-rtp-004.cisco.com (64.101.210.234) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.986.14; Wed, 17 Aug 2022 13:50:10 -0400
Received: from NAM12-DM6-obe.outbound.protection.outlook.com (64.101.32.56) by xfe-rtp-004.cisco.com (64.101.210.234) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.986.14 via Frontend Transport; Wed, 17 Aug 2022 13:50:10 -0400
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=CMevsxmdloyFQH62LRDTjlShA2reQvxAKO6YVxcu3OPqd9eZJilBoqAz919oJZNEVG23oONv/J6ok05gG3sOFmMr7TR2BnPWa4OuTuyxMcpysgKetPbETsa61sPTHA2N1QVf1xy8jfklhsOnrBlYuefbZzxuOcuAmotv0hzZu8mq5YKALz70AB2yEgOluvzipEIpBr1pBgUZ1ryzyY/slRobzURVttzwev5GxTjEr8bQAuQXZZVg+aeB1A/FCQnmXgYRSL4t5Dt8U1Mc5JB2Pvt3RzDX1yYIqHDKeq35nmx/fgqY1SmdSwLUCqpFtEm3suwFVrGcgCrNnTiV625h9g==
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=vHRx7hlGtNp0GAdTkmaqMYNKkfRiZG3FYSq7xL3sPz4=; b=jiK37te6/sdZ3Lj6g+2S2vyCPTc1hzTEkzkDDn6rmVw3DT5nZfYJjT1KF546FTshaV93JNpQmOSwQNTQyvrtZM7AdV8X6C/AwhsqOgga9O4BG0gLNnB3kCD0r5pYhVHyUt2WkpFXpxoVid86dICUfTnbNnwPbBlyBTqlzMUITS6xqP1MhLrOVHaVjYRiqJeRp0phkWPAOzYdHzuf35ra3KSeBxi43TPNsV/xDD0tysi4s4GFCZVPNYSe5VZDfuVF4LOUlq4AwJbKB4msDbYpJTJjR2lBGXc8Jqg6fb7Rgrp6+MeBL9RbdSVVKM67KS+38lnHLWJe6px86doPZJAAnw==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=vHRx7hlGtNp0GAdTkmaqMYNKkfRiZG3FYSq7xL3sPz4=; b=tWWWsI+1I5EA4HDC14W0rX8MmVzMvmLX1l7LleLxssQJNZgmv12LiJyVd7RP99XVwAPd3SaUBxq9j+/06DKQN4qSgsh03v2s324rfHtmEXNv4N1RZ4oRRCfkjsP9/wDth05bnVl+8qrB2R6DYojSXXYOV76yfX8FD5wPweN5uGQ=
Received: from CH0PR11MB5444.namprd11.prod.outlook.com (2603:10b6:610:d3::13) by MW3PR11MB4570.namprd11.prod.outlook.com (2603:10b6:303:5f::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5525.19; Wed, 17 Aug 2022 17:50:09 +0000
Received: from CH0PR11MB5444.namprd11.prod.outlook.com ([fe80::ec97:3894:f9f9:ff0a]) by CH0PR11MB5444.namprd11.prod.outlook.com ([fe80::ec97:3894:f9f9:ff0a%3]) with mapi id 15.20.5504.028; Wed, 17 Aug 2022 17:50:09 +0000
From: "Scott Fluhrer (sfluhrer)" <sfluhrer@cisco.com>
To: Mike Ounsworth <Mike.Ounsworth@entrust.com>, 'LAMPS' <spasm@ietf.org>, "cfrg@irtf.org" <cfrg@irtf.org>, pqc-forum <pqc-forum@list.nist.gov>, "jakemas@amazon.com" <jakemas@amazon.com>, "kpanos@amazon.com" <kpanos@amazon.com>, "sean@ssn3rd.com" <sean@ssn3rd.com>, "bas@westerbaan.name" <bas@westerbaan.name>
Thread-Topic: Whether to hash-then-sign with Dilithium and Falcon?
Thread-Index: AdiyWmrrCCvkDLBiTn2DcOMWvaOQ/gABb6NQ
Date: Wed, 17 Aug 2022 17:50:09 +0000
Message-ID: <CH0PR11MB5444B9D3A0CB6E447A2FA3E5C16A9@CH0PR11MB5444.namprd11.prod.outlook.com>
References: <CH0PR11MB5739393F19DD5282E3D7EF549F6A9@CH0PR11MB5739.namprd11.prod.outlook.com>
In-Reply-To: <CH0PR11MB5739393F19DD5282E3D7EF549F6A9@CH0PR11MB5739.namprd11.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=cisco.com;
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: ce8a7012-aa35-42a6-dfac-08da8078ed54
x-ms-traffictypediagnostic: MW3PR11MB4570:EE_
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: 0Fnjur0997CLt64XWeG4St1XkerysgQibIOVJQ9g44xYy7xIr9Tw52Hb7nvSCpl/vB2gX+1w8FpKg+glEvk1muao90g4WXonQUfrv9rZ0o4KD6VJHcG/s7zIkL6bynIGll38oEtfvi3XnogSX3TLIqBKw3WZEWI6RARG0bf95/l+gxArp/bUGsAn6B1YzHdyksVrgUBeS0sMy96vjUr/pIyJ1TpkRzj0072zU5jv0nnyHrY6whsAMBns3T/C0oy8oWw8TGhyWDAFC3cY585+GcKbrXf2IFNO2b5DNBOEyOfd57kfzPAziG4VCPdok2zsUmgq4uysht4wlHp347ZPGvpuPMIFmvk2YCNovuMP9DAvSyhrENqHvrT9hqsYZuVSStRJ6CgSn2JTZG5Y7miuTnGzyzzEsJUVMpSAgEYSNkPWzD9P3IQ8pIRC0V6qxgS/dX2l21RIRIptEUrwja5dEzb4uHLHuaDS9A4dYuIPyutlE6TiUKnskih2T/zTtak7k73mELsWrb6bxVmTEMyCfu6ErsNUdVmx55a8ordpVvD0fEnTEPhy6V+Ht17uGZYUYLJj20b6wfwxA3OQU+PFpGyRZqWhkPFpBd0JY4+6EjK5MfS1yjRWTSjHKy1vq+NJzOPBay/xLEZNxOAUiz/c7E+aMHY5uJ1latWXPi8A0nWcDiSQNddFjuwXU9CH8CXhDTeukKPEU2NKJWSZx3AY8avzkytK1nBdOnaocHNzQYfWpVT1ImgMwoWn3NzFzLdadwS1tVB4Bj83DhtMDsfqxDW+UP3LI3EVLHvAs7jiqLEz+lkCcAMU3uuRSpZxE/f6
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:CH0PR11MB5444.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230016)(4636009)(396003)(366004)(39860400002)(136003)(346002)(376002)(26005)(9686003)(38100700002)(2906002)(53546011)(7696005)(6506007)(55016003)(186003)(83380400001)(122000001)(33656002)(8676002)(64756008)(66476007)(66446008)(66556008)(71200400001)(76116006)(66946007)(478600001)(110136005)(316002)(5660300002)(38070700005)(86362001)(41300700001)(8936002)(52536014); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: e0w0ATUMsGq2Vzi4hRzq5AM/j/bpId5IkL6w9Z6LxdRtszQChrRrbh2WI1Ma8WGxi354UQCVL+tQ4sxxiiZu6nHOrqFf+da17DZ8EIXpKf1L1R7IUcpJG0Y35oZeBIipl9j7DtpqnDLdcg4Kg+0KhvaQ6Om7VsnNYFFIkDZks9sYLNYUk+fla0bvbMBid7nQygqPNmIg2gN/WpkK0Bd3kSv7fdp+rG62cA6YqSbiv5DeigI/xTINdCYJhwlzlzaYkYBEzwUJRo+g55nDbbC8CZ/oB3jLMgv6MBkID4NumdwMRS62BVtycm2AB5zWwmumf00pRaOQiCV0ovueRyVZ7XSjo68a3iU2HJgNgXIfhK/42U7GQRM24LbihvFcB8rJfRnMzIyxheD7NOrIMFv81qKrhAzj9ynpGf5uGD2Vvxpg6/uPjQgHsMiwNNZuMLdpM+P7WqLebVeHbKGnO4hh1aOgyQpz2Lpk7Ups9m8+axBhiVEZuOhC/SUrOhM4k7hQzFh2TuD/X745qf4IpY6bEtJPpL7FuUPpLhLTJmhEzJFT+Eywyf48i2LBoC6HSJrcCx29dLg9ZnMj6IJh+6+LQT17ehOJdHi/d71G11DARFbSdlzBdou9PLFuUpLs7ql572hDSAu/jCLEwnsC/cOqqp/H8/BwRidupgoCI/jpo3GoT7D6FHR9JiZZgcdmeJcenDXDtvD+qi9Np2RLnhB0KUnpIoxE+mbahLhlhJoN+qSBBgQevTOK6eK4mN+o357s0G29I7A2zcskh5Tm+WSynVJbkGMrqCAEeNhfSnQIio1TyGz5RNwA5TmyAjqIwzrw/l3/EP/PZqPYsOpQC9QRaywNFjzszNuG6Ja9wHRbnElu5fe4YJaVlnts4jR8ClhHPIoA3MsIliieethLkgFMaa+txCJJ+omPSdjbeNCvvYIke7x+Z3zxSv2a8nBnXrkkcYiPgenK7+M//kzGCWd/jvekZQXrFiamsj3mYN7iZCofNay1gVxib+t4e4IATMzzEduJ4lj20BQGKGbytXK9lLtZ6XsiZ7SmJc5hlPGtVLswbF8Xn2bGZCm/cFsPc9Y7oyDzdXQCnvRvHJFWWBaNovBXs+Z9NSg3AmJREEHJDdn5MPQe4+DH3qHjcubYPJ0RrfdCbWDta3q25VJdEs5jgJmCe+lNS515kpVZHjfU5qNFqc0KYfQuiif+koNykxo3mME2u570wAWIfeEqlA2Zjguc6CB9XAYWpJYcOksq2to11SPBpZm/aoOvBnVk4jgBat7O9xZ/yXM4B59kH1L1//z2Hic+j7MSlktqZb9w9Ikrgl5XEC+tLpbETAFxrtVzNfbAqarTiIBKsnhQdtfWeO1K3K8DXwvp3fvYacph8eMlKfVvuuGBETEN1FxReqZqQWE+XbnyQYEhQpT3VZRMYozs2N6mGV4n0vx+N4iamYduZ7vX8SnjzWKCSkk1yhsaHY/mL2XMGDRySgDjhQ0UX/LCGVCPNHT4HLQilQbWzmMi0FGymuWVRcW2cdeFwZfLIjAZv1lfJIY3f1cP/+NWsQgjaCWCsQEm7L8R7Q4TgnfB/UGq4o0ccEbdSZy6BdTO
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: CH0PR11MB5444.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: ce8a7012-aa35-42a6-dfac-08da8078ed54
X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Aug 2022 17:50:09.1914 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: KEf6LLkarIVuA5wemQcna9ff0BPbKfHuGA/qWoiRI1WtdXWIQbFO5CTEk4wG37lTfRCBAsNquQoozqYDoGvBcA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MW3PR11MB4570
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 64.101.210.234, xfe-rtp-004.cisco.com
X-Outbound-Node: alln-core-3.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/spasm/gQ6OM7lX_W9WTWvZ4LgDINszAVA>
Subject: Re: [lamps] 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: Wed, 17 Aug 2022 17:50:17 -0000


> -----Original Message-----
> From: 'Mike Ounsworth' via pqc-forum <pqc-forum@list.nist.gov>
> Sent: Wednesday, August 17, 2022 1:27 PM
> To: 'LAMPS' <spasm@ietf.org>; cfrg@irtf.org; pqc-forum <pqc-
> forum@list.nist.gov>; jakemas@amazon.com; kpanos@amazon.com;
> sean@ssn3rd.com; bas@westerbaan.name
> Subject: [pqc-forum] Whether to hash-then-sign with Dilithium and Falcon?
> 
> Hi Jake, Panos, Sean, Bas,
> 
> 
> We notice that your IETF draft-massimo-lamps-pq-sig-certificates-00 has the
> following security consideration:
> 
> > Within the hash-then-sign paradigm, hash functions are used as a
> > domain restrictor over the message to be signed. By pre-hashing, the
> > onus of resistance to existential forgeries becomes heavily reliant on
> > the collision-resistance of the hash function in use. As well as this security
> goal, the hash-then-sign paradigm also has the ability to improve
> performance by reducing the size of signed messages. As a corollary, hashing
> remains mandatory even for short messages and assigns a further
> computational requirement onto the verifier. This makes the performance of
> hash-then-sign schemes more consistent, but not necessarily more efficient.
> > Dilithium diverges from the hash-then-sign paradigm by hashing the
> message during the signing procedure (at the point in which the challenge
> polynomial).
> > However, due to the fact that Dilithium signatures may require the
> > signing procedure to be repeated several times for a signature to be
> produced, Dilithium implementations can make use of pre-hashing the
> message to prevent rehashing with each attempt.
> 
> 
> First, quoting from the Dilithium NIST Round 3 submission documents:
> 
> > Since our signing procedure may need to be repeated several times
> > until a signature is produced, we also append a counter in order to
> > make the SHAKE-256 output differ with each signing attempt of the same
> message.
> 
> So it seems like the Dilithium designers explicitly want the hash to differ
> across repeated attempts.
> 

Hmmm, I don't see that in Dilithium; are they referring to the internal ExpandMask function?  That isn't applied to the input message.

In any case, it's easy to derive SHAKE( M || 1 ), SHAKE( M || 2 ), ... without multiple passes through M; you compute the partial SHAKE state after process M, and then apply that partial state to 1, 2, ...

> 
> 
> Second, we had a similar discussion within the context of composite
> signatures when figuring out how to combine Dilithium and Falcon with
> ECDSA and RSA. We came out with a different conclusion; that hash-then-
> sign reduces the security properties of Dilithium and Falcon down to the
> collision resistance of the hash function used to pre-hash.
> 
> We would like community opinion on this.
> 
> 
> Here's the Security Consideration text that we're working on:
> 
> 
> 
> 
> In the hash-then-sign paradigm, the message to be signed is hashed
> externally to the signature primitive, and then the hash value is signed.
> 
> The hash-then-sign paradigm is required, for example, with RSA signatures in
> order to sign messages larger than the RSA modulus. Hash-then-sign also
> gives performance and bandwidth benefits, for example, when the signature
> is performed by a networked cryptographic appliance since you only need to
> send a small hash value rather than streaming the entire message.
> 
> With Dilithium and Falcon signatures it is not recommended to pre-hash for
> the following reasons:
> 
> 
> The Dilithium construction includes
> 
> ~~~
> Sign(sk,M):
> 10: mu \in {0, 1}^384 := CRH(tr || M)
> ~~~
> 
> where `CRH` is any collision-resistant hash function and `tr` is a component
> of the secret key.

A hash of the public key, actually; see line 7 of the key generation process (which explicitly computes it from the components of the public key) - Dilithium stores it in the private key so the signer doesn't need to recompute it every time.

> This provides strong security against pre-computed
> collision attacks since an attacker has no a-priori knowledge of `r` and
> provides per-key hash-domain separation of the message to be signed.

Rather, it limits the usability of any found collision to a specific public key; however it does nothing to frustrate a collision attack against a specific public key.

Now, it does probably add a constant factor to any attack that searches for a simultaneous collision between the hash that RSA/ECDSA uses (without the prepend) and the hash that Dilithium uses (with the known prepend) - I would hesitate to give a value to that constant factor, but it is likely not large.

> 
> 
> The Falcon construction includes
> 
> ~~~
> Sign (m, sk, beta^2):
> 1: r <- {0, 1}^320 uniformly
> 2: c <- HashToPoint(r || m, q, n)
> ~~~
> 
> where `HashToPoint` is a SHAKE-256-based construct. This provides strong
> security against pre-computed collision attacks since an attacker has no a-
> priori knowledge of `r` and provides per-signature hash-domain separation
> of the message to be signed.
> 
> If the message to be signed is pre-hashed, for example `m0 = SHA256(m)`
> and then m0 provided to Dilithium or Falcon to sign, then you have re-
> introduced the collision problem since two messages m1 and m2 where
> SHA256(m1) == SHA256(m2) hash value will result a single Falcon or Dilithium
> signature value which is simultaneously valid for both m1 and m2. This
> removes the extra collision resistance built in to the Dilithium and Falcon
> primitives and reduces it to the collision resistance strength of the underlying
> hash function. For this reason it is in general not recommended to pre-hash
> when using Dilithium or Falcon except in cases where the implementor is
> comfortable with this reduction in security.
> 
> Therefore, for the purpose of interoperability of composite signatures,
> implementations MUST NOT pre-hash messages for Dilithium and Falcon. If
> pre-hashed versions of these signatures are desired, then separate signature
> algorithms will need to be defined.
> 
>