Re: [CFRG] I-D Action: draft-irtf-cfrg-det-sigs-with-noise-03.txt

"D. J. Bernstein" <djb@cr.yp.to> Fri, 22 March 2024 07:08 UTC

Return-Path: <djb-dsn2-1406711340.7506@cr.yp.to>
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 1F889C14F60E for <cfrg@ietfa.amsl.com>; Fri, 22 Mar 2024 00:08:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.907
X-Spam-Level:
X-Spam-Status: No, score=-1.907 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no
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 2JC0ozY0QYb7 for <cfrg@ietfa.amsl.com>; Fri, 22 Mar 2024 00:08:38 -0700 (PDT)
Received: from salsa.cs.uic.edu (salsa.cs.uic.edu [131.193.32.108]) by ietfa.amsl.com (Postfix) with SMTP id 16210C14F5F6 for <cfrg@irtf.org>; Fri, 22 Mar 2024 00:08:37 -0700 (PDT)
Received: (qmail 27742 invoked by uid 1010); 22 Mar 2024 07:08:36 -0000
Received: from unknown (unknown) by unknown with QMTP; 22 Mar 2024 07:08:36 -0000
Received: (qmail 738851 invoked by uid 1000); 22 Mar 2024 07:08:27 -0000
Date: Fri, 22 Mar 2024 07:08:27 -0000
Message-ID: <20240322070827.738849.qmail@cr.yp.to>
From: "D. J. Bernstein" <djb@cr.yp.to>
To: cfrg@irtf.org
Mail-Followup-To: cfrg@irtf.org
In-Reply-To: <GVXPR07MB9678799A86599695B7B31F41892F2@GVXPR07MB9678.eurprd07.prod.outlook.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/cfrg/R7tUulCdBh9wHMVaCsr-ho-Xi9I>
Subject: Re: [CFRG] I-D Action: draft-irtf-cfrg-det-sigs-with-noise-03.txt
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Crypto Forum Research Group <cfrg.irtf.org>
List-Unsubscribe: <https://mailman.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://mailman.irtf.org/mailman/listinfo/cfrg>, <mailto:cfrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Fri, 22 Mar 2024 07:08:39 -0000

I think the best way to convert deterministic Ed25519 signing software
into randomized Ed25519 signing software is to overwrite noncekey with
H(noncekey,randomness) right after the usual derivation of noncekey from
the secret key, i.e., before computing nonce = H(noncekey,message).

This makes the code changes as simple as possible: for example, the
relevant changes from earlier code to lib25519 replaced

    unsigned char secret[64];
    crypto_hash_sha512(secret,sk,32);

with

    unsigned char secret[96];
    crypto_hash_sha512(secret,sk,32);
    randombytes(secret+64,32);
    crypto_hash_sha512(secret+32,secret+32,64);

and left everything else unchanged.

The main security risk from randomization comes from typical test
frameworks not being able to test randomized functions: basically, the
entire signing function ends up being tested merely for "yes, signatures
verify", so bugs in how nonces are generated won't be caught. Randomized
functions are tested in the lib25519 test framework, and aligning the
randomization details has the secondary advantage of allowing reuse of
test inputs and test outputs from lib25519.

---D. J. Bernstein