Re: [Cfrg] A new MGF for RSA-PSS based on SHAKE
"Dang, Quynh (Fed)" <quynh.dang@nist.gov> Sun, 30 September 2018 10:42 UTC
Return-Path: <quynh.dang@nist.gov>
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 6B95B130DFA for <cfrg@ietfa.amsl.com>; Sun, 30 Sep 2018 03:42:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.199
X-Spam-Level:
X-Spam-Status: No, score=0.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (public key: not available)" header.d=nist.gov
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 woI7BEujsD7c for <cfrg@ietfa.amsl.com>; Sun, 30 Sep 2018 03:42:41 -0700 (PDT)
Received: from GCC01-DM2-obe.outbound.protection.outlook.com (mail-dm2gcc01on0127.outbound.protection.outlook.com [23.103.201.127]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 456C3120072 for <cfrg@irtf.org>; Sun, 30 Sep 2018 03:42:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nist.gov; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=BSD8idCqBE2BPCtDeXwGpYHkjAyknGPy20vZD1p7xY4=; b=0GJh2tH8WuOH2W/ygtV6YJqyNizhRt1bj0ecNHwBDy59IIw85JSCK5Q7GUEzhe8fMNLuA5mXsatG4rJ4pvpNsedhlRy2shuAs8Mx5ltYpOkmMC8PDmERQnvWds0vUoguhx48NtiwbqeQXFjOeevyJTePBYXZN9h7UyW9d3SCTVA=
Received: from DM6PR09MB2746.namprd09.prod.outlook.com (20.176.97.156) by DM6PR09MB2747.namprd09.prod.outlook.com (20.176.97.157) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1164.25; Sun, 30 Sep 2018 10:42:38 +0000
Received: from DM6PR09MB2746.namprd09.prod.outlook.com ([fe80::c0c0:1326:345e:29e9]) by DM6PR09MB2746.namprd09.prod.outlook.com ([fe80::c0c0:1326:345e:29e9%2]) with mapi id 15.20.1164.027; Sun, 30 Sep 2018 10:42:38 +0000
From: "Dang, Quynh (Fed)" <quynh.dang@nist.gov>
To: Natanael <natanael.l@gmail.com>, Russ Housley <housley@vigilsec.com>
CC: IRTF CFRG <cfrg@irtf.org>
Thread-Topic: [Cfrg] A new MGF for RSA-PSS based on SHAKE
Thread-Index: AQHUTskgVGWWQTc7tkG17wqHfHNncKUIAEOAgACvpZ8=
Date: Sun, 30 Sep 2018 10:42:38 +0000
Message-ID: <DM6PR09MB2746C43EB1EE79801AFB864AF3EE0@DM6PR09MB2746.namprd09.prod.outlook.com>
References: <3B4BE320-418B-4FC1-8427-0EF2F58A0F01@vigilsec.com>, <CAAt2M19wdngVoruE_FF69-jhNf8fWXXuQdRtY+z9jq_ujfTyNA@mail.gmail.com>
In-Reply-To: <CAAt2M19wdngVoruE_FF69-jhNf8fWXXuQdRtY+z9jq_ujfTyNA@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=quynh.dang@nist.gov;
x-originating-ip: [129.6.222.223]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; DM6PR09MB2747; 6:RorvLpgO4pWy0AtkCr0TarXkLqBqSeeJ1QYBYkxSC5wDVOr5BX6fqUVTa87oNhM3hni/4aoj9ryyfOEcm6qb1zPwpKjtnhvggQYEWu2S2i+GLQeUEf2TkVVC+j5MsH3+hSU2rDGHefVCJ0hTnNbBM2uJRrYDE3pFCyiNHWc8nGuWt8qAVApQ4tF6vard4nimDvBP6NofMbjUytOOVzPY0IeRhdEUmmk8waAX5iVrN9Tl0CvctXQLV7UbiJhRDbuYrbgv0VGxManDGGFGccHFYlRi8RLhp5No1a0RfV7CVGeGpJFrOb34MlPVMesxx0xclkG8k+XpPJfBUE/qXce0zfCdE8H5//F/x+XvUZ/S0G80P2nPceYGuDq2BhELvt9IsPRfnecjWasxKfAIsbDkgkzA7wVALiKLz3Xss+4saxtoM+NG5h3y4VrCCLY6lToS7MelxKAxVKDCt8QAfhjYZQ==; 5:0srny/d+XTIp62hjh8FMogR/yGeRa/GyvkTMdpEO2UktAcRn1kW2S7KnGrkuJrjTVTbabmrBfe9NSVmXSAGQRJOSjYZYq+dlUWSdkeNCNTMonYAxVEOzt+IlK6qgyCo8+4hq2iro45Fz49lcbPJFTa9BxsENyHL6KD8HpzfnDAQ=; 7:N3rkCFchvGPd8KeCO7rhgTYEplec/OLsBkDRfS/JFdMHvDKwqSlebBhPqop/H3hnTwtUP8KKI/NPSQ0TLrsEvWqGjQIhrJ/A3P5QvOPsxqMuIGLrUsoBj9UH/dNE5up7nkpX0if6XnwIbDW4iXEOdc0k1Kmif+jVNmsCiPGb5epahC67ACfKPltI9dX9XVrbs4vX8kp3wZ/hWiKRvBa/MVlicPfMAAMKBcr48P8iUpLwlzl1F/IQOs9MyuacMVqJ
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-ms-office365-filtering-correlation-id: c558a98f-e0ff-42de-cd43-08d626c170dd
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989299)(4534165)(4627221)(201703031133081)(201702281549075)(8990200)(5600074)(711020)(4618075)(2017052603328)(7153060)(7193020); SRVR:DM6PR09MB2747;
x-ms-traffictypediagnostic: DM6PR09MB2747:
x-microsoft-antispam-prvs: <DM6PR09MB27471D3E91770639133AAA4AF3EE0@DM6PR09MB2747.namprd09.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(192374486261705)(85827821059158)(269456686620040)(788757137089)(219752817060721)(189930954265078);
x-ms-exchange-senderadcheck: 1
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040522)(2401047)(8121501046)(5005006)(10201501046)(93006095)(93001095)(3002001)(3231355)(944501410)(52105095)(6055026)(149066)(150057)(6041310)(20161123562045)(20161123558120)(20161123560045)(20161123564045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(201708071742011)(7699051); SRVR:DM6PR09MB2747; BCL:0; PCL:0; RULEID:; SRVR:DM6PR09MB2747;
x-forefront-prvs: 08118EFC2B
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(366004)(376002)(346002)(136003)(39850400004)(396003)(199004)(189003)(51444003)(2900100001)(106356001)(105586002)(81166006)(81156014)(8676002)(19627405001)(53936002)(86362001)(76176011)(74316002)(256004)(14444005)(229853002)(102836004)(345774005)(53546011)(26005)(7696005)(33656002)(486006)(6506007)(476003)(446003)(11346002)(186003)(66066001)(14454004)(71190400001)(71200400001)(68736007)(34290500001)(55016002)(6606003)(606006)(236005)(9686003)(6306002)(97736004)(478600001)(7736002)(6436002)(5660300001)(966005)(54896002)(6116002)(3846002)(39060400002)(6246003)(5250100002)(25786009)(4326008)(110136005)(2906002)(316002)(99286004)(8936002); DIR:OUT; SFP:1102; SCL:1; SRVR:DM6PR09MB2747; H:DM6PR09MB2746.namprd09.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None (protection.outlook.com: nist.gov does not designate permitted sender hosts)
x-microsoft-antispam-message-info: z9nQ13B/9pRAbV+ATj5ulnUuwzmBGpmkrNN+Vm/GTmLS3ryEr1bAFGeWcyGJtOclPBGtIhuWIcBleTT+qARqNIerjZCWewZ5kwgYHg4RWmau5IUkRtaI/JCo9ERigr4ReQaBUymGYHZFw6DT5ATGBTJ9r63cibfm0SJdiWXm8HqUizmde4fMK+kRAqlvXkjN+87PmGu+dPwTDykE2ruY0xkC6rGZ4zMREhGMwlCzToT/z7gFuhTNP6jnnitc+z+JaE6EJROQeiJzRs8pbMov5H+OHJEMbWazMtQS7DZiSy1S5qEJ4ZJZIif1uYdHN++8UaUXgtxz6wKbNUkm+R6n8yC5zLM9db/CXQxz0cSPJB0=
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_DM6PR09MB2746C43EB1EE79801AFB864AF3EE0DM6PR09MB2746namp_"
MIME-Version: 1.0
X-OriginatorOrg: nist.gov
X-MS-Exchange-CrossTenant-Network-Message-Id: c558a98f-e0ff-42de-cd43-08d626c170dd
X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Sep 2018 10:42:38.2694 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR09MB2747
Archived-At: <https://mailarchive.ietf.org/arch/msg/cfrg/acRf6E-wIzs5E3vyjsclc4wx54c>
Subject: Re: [Cfrg] A new MGF for RSA-PSS based on SHAKE
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: Sun, 30 Sep 2018 10:42:45 -0000
Hi Natanael, Thank you for reviewing the document and for giving a nice security discussion. We described that property of the SHAKEs or any other stream ciphers similarly in FIPS 202. In this specification, output lengths of the SHAKEs are all fixed-lengths. When they are used to generate message digests, their outputs are 256 or 512 bits. In RSA-PSS, with any given length of a RSA modulus, all outputs of a SHAKE are in fixed lengths and all inputs are different from each other. So, the uses of a SHAKE in RSA-PSS are good. Regards, Quynh. ________________________________ From: Cfrg <cfrg-bounces@irtf.org> on behalf of Natanael <natanael.l@gmail.com> Sent: Saturday, September 29, 2018 7:48:27 PM To: Russ Housley Cc: IRTF CFRG Subject: Re: [Cfrg] A new MGF for RSA-PSS based on SHAKE (note that the following is my layman's opinion (perhaps in more words then necessary)) --- I think that the security considerations in these documents currently aren't phrased strongly enough regarding one point - to "not expect unrelated outputs" from a XOF for the same input doesn't properly explain the risk. The relevant section is this; > The SHAKEs are deterministic functions. Like any other deterministic functions, executing each function with the same input multiple times will produce the same output. Therefore, users should not expect unrelated outputs (with the same or different output lengths) from excuting a SHAKE function with the same input multiple times. Explained another way, SHAKE as a XOF (extensible output function) takes an input and derives a fixed pseudorandom bit sequence of arbitary length as an output (similar to a stream cipher), where the requested length only determines how much of that sequence to use. In pseudocode: SHAKE128(message, length) == truncate(SHAKE128(message, length+N), length). To be clear, changing the requested length doesn't influence the output sequence, the output bits remain the same. As a consequence, any XOF output can be truncated to any shorter length and still remain valid, for as long as the recipient will accept that shorter output. This is *very* different from just "not unrelated"! In short, the risk here is that a poorly implemented client could be convinced to accept shorter XOF lengths than intended, perhaps even dangerously short hashes! For example, a SHAKE output that initially was 2048 bits long would still be equally valid even if reduced to 80 bits or less, or alternatively a client might accept a 128 bit XOF in place of a 256 bit one (perhaps enabling a birthday collision attack). Verifying the intended output length of the SHAKE function is absolutely necessary in order to ensure that the intended security level is preserved, and too short output lengths needs to be prohibited entirely. Every protocol or algorithm using a XOF needs to be very clear with what lengths are accepted. They also need to take extra care when multiple lengths are allowed, to not mix them up / allow unintended reuse or cross-protocol exploits, etc. Note: in algorithms / protocols where multiple lengths are allowed it is possible to encode the chosen output length as a part of the message, and to also require validation of that encoded length by the client. This would be a fairly simple way to ensure correctly behaving clients will not be fooled by truncated hashes. This effectively works as a form of domain separation between different messages with different requested XOF output lengths. So far I have only looked briefly at a few of the documents where SHAKE is being recommended, so I can't say if there currently are any such risks here. I have seen some documents specify fixed output lengths which is a very good sign, but more review might still be a good idea. Especially whenever multiple XOF lengths are allowed. Also, some uses of XOF:s might also not be at risk of this at all, such as when the XOF output is authenticated (signed or MAC tagged, etc), where truncating it breaks the authentication. But once again, it's a good idea to review it first. Den mån 17 sep. 2018 22:57Russ Housley <housley@vigilsec.com<mailto:housley@vigilsec.com>> skrev: Dear CFRG: The IETF LAMPS WG is specifying the use of SHAKE with RSA-PSS for use with certificates and CMS signed objects. The current drafts are: draft-ietf-lamps-cms-shakes-01.txt draft-ietf-lamps-pkix-shake-02.txt In discussion of these drafts, it was suggested that instead of replacing SHA-1 in the RSA-PSS default mask generation function (MGF), one could replace the entire MGF with SHAKE. While it does look like a simple substitution, I do not think the IETF LAMPS WG is the right group to make the assessment. CFRG may have people with the right skills, so I would greatly appreciate you thoughts on this idea. Russ _______________________________________________ Cfrg mailing list Cfrg@irtf.org<mailto:Cfrg@irtf.org> https://www.irtf.org/mailman/listinfo/cfrg<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.irtf.org%2Fmailman%2Flistinfo%2Fcfrg&data=02%7C01%7Cquynh.dang%40nist.gov%7C8905e4261449422112b808d626663950%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C0%7C636738617850955007&sdata=VX7Mc1ZeeC%2FR%2BIZM8R%2BfoiEyrzzlcJrdnU7Lg5B2Crg%3D&reserved=0>
- [Cfrg] A new MGF for RSA-PSS based on SHAKE Russ Housley
- Re: [Cfrg] A new MGF for RSA-PSS based on SHAKE Saqib A. Kakvi
- Re: [Cfrg] A new MGF for RSA-PSS based on SHAKE Jim Schaad
- Re: [Cfrg] A new MGF for RSA-PSS based on SHAKE Saqib A. Kakvi
- Re: [Cfrg] A new MGF for RSA-PSS based on SHAKE John Mattsson
- Re: [Cfrg] A new MGF for RSA-PSS based on SHAKE Jim Schaad
- Re: [Cfrg] A new MGF for RSA-PSS based on SHAKE Peter Gutmann
- Re: [Cfrg] A new MGF for RSA-PSS based on SHAKE Scott Fluhrer (sfluhrer)
- Re: [Cfrg] A new MGF for RSA-PSS based on SHAKE Jim Schaad
- Re: [Cfrg] A new MGF for RSA-PSS based on SHAKE Peter Gutmann
- Re: [Cfrg] A new MGF for RSA-PSS based on SHAKE Andy Lutomirski
- Re: [Cfrg] A new MGF for RSA-PSS based on SHAKE John Mattsson
- Re: [Cfrg] A new MGF for RSA-PSS based on SHAKE John Mattsson
- Re: [Cfrg] A new MGF for RSA-PSS based on SHAKE A. Huelsing
- Re: [Cfrg] A new MGF for RSA-PSS based on SHAKE Tibor Jager
- Re: [Cfrg] A new MGF for RSA-PSS based on SHAKE Natanael
- Re: [Cfrg] A new MGF for RSA-PSS based on SHAKE Dang, Quynh (Fed)
- Re: [Cfrg] A new MGF for RSA-PSS based on SHAKE Panos Kampanakis (pkampana)