Re: [TLS] RSA-PSS in TLS 1.3

"Dang, Quynh (Fed)" <> Thu, 03 March 2016 18:13 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id C74BD1B2C77 for <>; Thu, 3 Mar 2016 10:13:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0.698
X-Spam-Status: No, score=0.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, MANGLED_BACK=2.3, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Y7lZMC0zD00u for <>; Thu, 3 Mar 2016 10:13:25 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 876691B2C39 for <>; Thu, 3 Mar 2016 10:13:25 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=selector1-nist-gov; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=P84r8uLoQa6Je3znsbv4OF/O3vUJDmwSidK5XXGvh3M=; b=kIRSSgsl47bK9pwEgMMKb3IuwWCI6Zr2j6qCoLSGFKXNa7LelPcfwUKjfRLMS1Tl6IgecQDp61VnePlgQeHtTw5bXeccWed7NiOtTyTMWRW1o5RpWQ1wlJNkq+rQI4n3afxeUZnETLeiJRdcALm9iWeppkfSmiUvRccCP46zMec=
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.1.415.20; Thu, 3 Mar 2016 18:13:23 +0000
Received: from ([]) by ([]) with mapi id 15.01.0415.024; Thu, 3 Mar 2016 18:13:23 +0000
From: "Dang, Quynh (Fed)" <>
To: =?utf-8?B?SGFubm8gQsO2Y2s=?= <>, "Blumenthal, Uri - 0553 - MITLL" <>, "" <>
Thread-Topic: [TLS] RSA-PSS in TLS 1.3
Thread-Index: AdF1YX6h0LczJ8DOZUibIUJHHuPVmgABdJKAAAAkjow=
Date: Thu, 3 Mar 2016 18:13:22 +0000
Message-ID: <>
References: <>, <20160303171117.12e627b3@pc1>
In-Reply-To: <20160303171117.12e627b3@pc1>
Accept-Language: en-US
Content-Language: en-US
authentication-results:; dkim=none (message not signed) header.d=none;; dmarc=none action=none;
x-originating-ip: []
x-microsoft-exchange-diagnostics: 1; BN1PR09MB121; 5:qjuS6fw7XU0PU4ekoKQBLrBeWZFx6aS2J9UqQoqQ7VD4L4EAn1Y4jCe3V0MmMKhHNxF6cjUWLjD87Fvm43OiXJubhQ3AaYfJ4dawVnzk1fBiOKLpvjXUQ96ze0QImGkzsAsLfdhuEaaq5N9ld1llIw==; 24:MdR0wKxSHkdFiNXIg857d83C1as4+raqG2EuFgt2xurqTXlQ3IpcfFa9e7uT1Jpga0DkXz2hTohNxwvW2moVV3CzPFZL88hLwa+HhSSfbxY=
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN1PR09MB121;
x-ms-office365-filtering-correlation-id: f9b50fe6-13f6-4f3f-6903-08d3438f8209
x-microsoft-antispam-prvs: <>
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046); SRVR:BN1PR09MB121; BCL:0; PCL:0; RULEID:; SRVR:BN1PR09MB121;
x-forefront-prvs: 0870212862
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(24454002)(377454003)(92566002)(3900700001)(6116002)(1096002)(1220700001)(50986999)(5003600100002)(102836003)(586003)(3660700001)(77096005)(2501003)(2900100001)(15975445007)(54356999)(2950100001)(76176999)(81166005)(66066001)(5004730100002)(3280700002)(2906002)(122556002)(40100003)(19580405001)(189998001)(5002640100001)(74316001)(19580395003)(10400500002)(76576001)(86362001)(107886002)(33656002)(99286002)(11100500001)(5001770100001)(5008740100001)(2171001); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1PR09MB121;; FPR:; SPF:None; MLV:sfv; LANG:en;
spamdiagnosticoutput: 1:23
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Mar 2016 18:13:22.6036 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN1PR09MB121
Archived-At: <>
Subject: Re: [TLS] RSA-PSS in TLS 1.3
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 03 Mar 2016 18:13:29 -0000

PSS+SHAKE128/512+SHAKE128 or PSS+SHAKE256/512+SHAKE256 (as SHAKEs being used as MGF) would be more efficient options. NIST is working on a formal specification for the SHAKEs being used as fixed output-length hash functions such as SHAKE128/256, SHAKE128/512 and SHAKE256/512. 

Prepending a random salt of 512-bit in length (fixed length of 512 bits) to the message should work and this is very simple and efficient.


From: TLS <> on behalf of Hanno Böck <>
Sent: Thursday, March 3, 2016 11:11 AM
To: Blumenthal, Uri - 0553 - MITLL;
Subject: Re: [TLS] RSA-PSS in TLS 1.3

On Thu, 3 Mar 2016 15:29:37 +0000
"Blumenthal, Uri - 0553 - MITLL" <> wrote:

> Also, wasn't PSS ‎developed before SHA3 and SHAKE were known, let
> alone available?

Yeah, more than 10 years before.
It's more the other way found: PSS and other constructions showed the
need for hash functions with a defined output length. SHAKE is such a
function. PSS uses a construction called MGF1, which essentially takes
an existing fixed-output-length hash, combines that with a counter and
produces some construction. SHAKE deprecates the need for such a

So instead of using PSS+SHA256+MGF1-with-SHA256 you could say you use
PSS+SHA-3-256+SHAKE256. I don't think this changes a whole lot in
regards to security (as long as we assume both sha256 and sha-3-256 are
very secure algorithms).

> It may be worth asking the authors what's their opinion of FDH vs PSS
> in view of the state of the art *today*.

You may do that, but I doubt that changes much.

I think FDH really is not an option at all here. It may very well be
that there are better ways to do RSA-padding, but I don't think that
this is viable for TLS 1.3 (and I don't think FDH is better).
PSS has an RFC (3447) and has been thoroughly analyzed by research. I
think there has been far less analyzing effort towards FDH (or any
other construction) and it is not in any way specified in a standards
document. If one would want to use FDH or anything else one would imho
first have to go through some standardization process (which could be
CFRG or NIST or someone else) and call for a thorough analysis of it
by the cryptographic community. Which would take at least a couple of

Given that there probably is no long term future for RSA anyway (people
want ECC and postquantum is ahead) I doubt anything else than the
primitives we already have in standards will ever be viable.

Hanno Böck