[Cfrg] RFC 8032: Question on Side-Channel Leaks

Jerry Zhu <jezhu@nvidia.com> Wed, 19 July 2017 08:34 UTC

Return-Path: <jezhu@nvidia.com>
X-Original-To: cfrg@ietfa.amsl.com
Delivered-To: cfrg@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 3755C131C3B for <cfrg@ietfa.amsl.com>; Wed, 19 Jul 2017 01:34:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id zS9ohKXeuXRs for <cfrg@ietfa.amsl.com>; Wed, 19 Jul 2017 01:34:50 -0700 (PDT)
Received: from nat-hk.nvidia.com (nat-hk.nvidia.com []) (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 4B73F131C35 for <cfrg@irtf.org>; Wed, 19 Jul 2017 01:34:50 -0700 (PDT)
Received: from hkpgpgate102.nvidia.com (Not Verified[]) by nat-hk.nvidia.com id <B596f15ec0001>; Wed, 19 Jul 2017 16:18:52 +0800
Received: from HKMAIL102.nvidia.com ([]) by hkpgpgate102.nvidia.com (PGP Universal service); Wed, 19 Jul 2017 01:34:47 -0700
X-PGP-Universal: processed; by hkpgpgate102.nvidia.com on Wed, 19 Jul 2017 01:34:47 -0700
Received: from HKMAIL103.nvidia.com ( by HKMAIL102.nvidia.com ( with Microsoft SMTP Server (TLS) id 15.0.1263.5; Wed, 19 Jul 2017 08:34:46 +0000
Received: from HKMAIL103.nvidia.com ([fe80::f5ae:f43f:ff37:8c85]) by HKMAIL103.nvidia.com ([fe80::f5ae:f43f:ff37:8c85%19]) with mapi id 15.00.1263.000; Wed, 19 Jul 2017 08:34:46 +0000
From: Jerry Zhu <jezhu@nvidia.com>
To: "cfrg@irtf.org" <cfrg@irtf.org>
Thread-Topic: RFC 8032: Question on Side-Channel Leaks
Thread-Index: AdMAahSpyutm7k8jSgmJRdRK3qusBg==
Date: Wed, 19 Jul 2017 08:34:46 +0000
Message-ID: <6fa65bd5e4ce454ba871ddec56a87d9c@HKMAIL103.nvidia.com>
Accept-Language: en-US
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: []
MIME-Version: 1.0
Content-Language: en-US
Content-Type: multipart/alternative; boundary="_000_6fa65bd5e4ce454ba871ddec56a87d9cHKMAIL103nvidiacom_"
Archived-At: <https://mailarchive.ietf.org/arch/msg/cfrg/-5QI56d6ULOPYDCsLOm6BKefaf0>
Subject: [Cfrg] RFC 8032: Question on Side-Channel Leaks
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.22
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: Wed, 19 Jul 2017 08:34:52 -0000

Dear RFC experts,

I am an engineer in Nvidia. When reading below statement in https://tools.ietf.org/html/rfc8032#section-8.1

"To make an implementation side-channel silent in this way, the modulo p arithmetic must not use any data-dependent branches, e.g., related to carry propagation."

Does the 'modulo p' refer to a generic prime number, or the prime number defining GF(p) e.g. 2^255-19 for Ed25519?
I am asking this because some modulo arithmetic in  Ed25519 Sign is against  L, not p.

"5.  Compute S = (r + k * s) mod L.  For efficiency, again reduce k modulo L first."
I think this computation shall also be side channel silent to keep confidentiality of k.

Could you please clarify?

-Jerry Zhu (Ext. 41218)

This email message is for the sole use of the intended recipient(s) and may contain
confidential information.  Any unauthorized review, use, disclosure or distribution
is prohibited.  If you are not the intended recipient, please contact the sender by
reply email and destroy all copies of the original message.