[CFRG] Re: Can hash_to_field hash to mod (p-1)?

Mike Hamburg <mike@shiftleft.org> Mon, 03 August 2026 16:08 UTC

Return-Path: <mike@SHIFTLEFT.ORG>
X-Original-To: cfrg@mail2.ietf.org
Delivered-To: cfrg@mail2.ietf.org
Received: from localhost (localhost [127.0.0.1]) by mail2.ietf.org (Postfix) with ESMTP id BA918122C5E1B for <cfrg@mail2.ietf.org>; Mon, 3 Aug 2026 09:08:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1785773334; bh=P5aQuOV0/yPrKyVTLWaDxDNYiyZb8KIdB2ecGzgV0IU=; h=From:Subject:Date:In-Reply-To:Cc:To:References; b=pGjxl0flMmdT0lhP5Z+eVqCfxE9d2VVkqugsjirOh1dBhfR8Vh1c+M9KaaJ6mQ8fb zRSfNV33bjKoVYu2iQoo6WnE3Zh3tIfzKB2cA1A6ZqdSIUnNxHpsCbOS1Dy2hi+C+0 BkhiF4UMmeSKoYPa5rPzpVazgXQQB5Ul6TbVpBHM=
X-Virus-Scanned: amavisd-new at ietf.org
X-Spam-Flag: NO
X-Spam-Score: -2.087
X-Spam-Level:
X-Spam-Status: No, score=-2.087 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, HTML_MESSAGE=0.001, RCVD_IN_VALIDITY_CERTIFIED_BLOCKED=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no
Authentication-Results: mail2.ietf.org (amavisd-new); dkim=pass (4096-bit key) header.d=shiftleft.org
Received: from mail2.ietf.org ([166.84.6.31]) by localhost (mail2.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0TdLmRe1iRgq for <cfrg@mail2.ietf.org>; Mon, 3 Aug 2026 09:08:54 -0700 (PDT)
Received: from mockingbird.shiftleft.org (mockingbird.shiftleft.org [172.233.56.96]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by mail2.ietf.org (Postfix) with ESMTPS id BF961122C599A for <cfrg@irtf.org>; Mon, 3 Aug 2026 09:08:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=shiftleft.org; s=sldo2024; t=1785773309; bh=P5aQuOV0/yPrKyVTLWaDxDNYiyZb8KIdB2ecGzgV0IU=; h=From:Subject:Date:In-Reply-To:Cc:To:References:From; b=XipNMChcc24yNCMmZUYP8gG3sAlxFh9TaaNNPuFaSuHzhuZqPEo8x14nJJeZVsk7r z/wVp5U2s17R2vyM5D7rECvesTJTzoTizyEAztMPFGgtU7naa/jpen7WMmlGuRjk/j xhc6HlGBeDGzbsdM/iV3twmkYBrHYpYOqknl3+oUxyG3KNpBpISNmAFIDszgum+zcK rYMp7UQ9p/H/rAlrsYYGwGyePOc1Pr7P+45oZUDsV6m+05w0hAVF+KnCLpVfm3Sera j4hgomO2vPryQsNDYrkdxrCPcOZTMVLb7pZ+zSr81hAlTnwjZxpODbwa/8XtZnzN4C W+6aApkPOo6IIm7KCRYhGUapK6g45VaNhNLclm6/sKpBIwm5/IwJojYVX06NGBiNpX yZS/MNEKd6XpXL7pMT6BfEUj84gNfFQ32YQbplQP4nPTkIpGrZLJmtgcfEFBgPS34k t8j6Zk6yhzZyQ8MDqVc5W0w3XmDmJ9JbNFkzg8Hst1uxQi7wiFD+otXPIRPLqsK8I8 Ns1fv3+0QlyMGCH6hBOdnkQAQQsSMcAEPMfZAOvDTzQkvAnvjdss9l1GDpJqW1QqAN oCUh6Nu6MWLhjPMu2UiVT9Ef5jZl2ULqJJWfq5KEq78p1mq/0ahzotX6O+NaEkY+FX KEbLuHNexEVoOe9Ke5anGXV0=
Received: from smtpclient.apple (77-164-31-58.fixed.kpn.net [77.164.31.58]) by mockingbird.shiftleft.org (Postfix) with ESMTPSA id 356FF7F2F8; Mon, 3 Aug 2026 16:08:29 +0000 (UTC)
From: Mike Hamburg <mike@shiftleft.org>
Message-Id: <017388BA-CF30-472A-ACC2-A7BDD1CDD3B1@shiftleft.org>
Content-Type: multipart/alternative; boundary="Apple-Mail=_D0562366-D1F7-40AF-AA10-6FE2DEA79F8A"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3864.600.51.1.1\))
Date: Mon, 03 Aug 2026 18:08:18 +0200
In-Reply-To: <CANMnvkxNZn2aoO652PzOniPHj28LNcC8DPURUH3K4o=7xtiykw@mail.gmail.com>
To: Emil Lundberg <emil=40yubico.com@dmarc.ietf.org>
References: <CANMnvkxNZn2aoO652PzOniPHj28LNcC8DPURUH3K4o=7xtiykw@mail.gmail.com>
X-Mailer: Apple Mail (2.3864.600.51.1.1)
Message-ID-Hash: WNHBXNCST6CYTSOIOSE6LA627VJOOJW5
X-Message-ID-Hash: WNHBXNCST6CYTSOIOSE6LA627VJOOJW5
X-MailFrom: mike@SHIFTLEFT.ORG
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-cfrg.irtf.org-0; header-match-cfrg.irtf.org-1; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: CFRG <cfrg@irtf.org>
X-Mailman-Version: 3.3.9rc6
Precedence: list
Subject: [CFRG] Re: Can hash_to_field hash to mod (p-1)?
List-Id: Crypto Forum Research Group <cfrg.irtf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/cfrg/PFfmwFafvu7-rfMCdnf2gSZEyAw>
List-Archive: <https://mailarchive.ietf.org/arch/browse/cfrg>
List-Help: <mailto:cfrg-request@irtf.org?subject=help>
List-Owner: <mailto:cfrg-owner@irtf.org>
List-Post: <mailto:cfrg@irtf.org>
List-Subscribe: <mailto:cfrg-join@irtf.org>
List-Unsubscribe: <mailto:cfrg-leave@irtf.org>

Hello Emil,

Yes, the outputs are very close to uniformly random even if p isn’t a prime.  The same method — generate extra random bits, reduce mod p-1, add 1 — is used in FIPS 186-5 §A.3.1.

Regards,
— Mike

PS: As a small correction, Z/q is only a field if q is prime.  Being a power of a prime isn’t enough: the Galois fields GF(q^n) are not the same as Z/q when n > 1.

> On 3 Aug 2026, at 17:30, Emil Lundberg <emil=40yubico.com@dmarc.ietf.org> wrote:
> 
> Hi CFRG,
> 
> I have a question about the hash_to_field function defined in RFC 9380 [1]: Can hash_to_field be used to securely hash to an integer mod (p-1), for some (large) prime p?
> 
> I know that Z_{p-1} is not a field unless p-1 happens to be a power of two (very unlikely as p would have to be a Fermat prime), but it's not clear to me whether hash_to_field outputs are (approximately) uniformly random _only_ for prime p, or if that's just what's relevant for RFC 9380 itself. My guess would be that uniformity is preserved when p is coprime to 2^8L? (which does not hold for p-1 then, since p-1 is even)
> 
> The reason I'm asking is for whether you could use hash_to_field(r-1)+1 to securely hash to a nonzero scalar mod r, for secret keys, message representatives and the like. This would be an infallible way to do so in constant time, as opposed to rejection sampling for a nonzero result (not constant time) or accepting the negligible probability of a bad result (practically infallible, but nonzero probability in principle) as advocated in section 10.1 of RFC 9380 [2].
> 
> This thought occurred to me as I was reviewing draft-irtf-cfrg-bls-signature-07, which uses HKDF mod r and rejection sampling to generate nonzero scalars as private keys, and I was reminded of it by Michele Orrù's recent message on draft-irtf-cfrg-pairing-friendly-curves [3] which remarks/proposes that "Sampling APIs distinguish between sampling from [0, r - 1] and sampling from [1, r - 1]".
> 
> I'm sure someone has considered this before and discarded it as a bad idea, but I haven't found any documentation on whether it works or fails. Can someone point me to any relevant reading?
> 
> [1]: https://www.rfc-editor.org/rfc/rfc9380.html#name-hashing-to-a-finite-field
> [2]: https://www.rfc-editor.org/rfc/rfc9380.html#name-properties-of-encodings
> [3]: https://mailarchive.ietf.org/arch/msg/cfrg/K8sgyB7qT-tGTAOKtsngV6n0Slg/
> 
> Emil Lundberg
> Staff Engineer | Yubico <http://www.yubico.com/>
> 
> _______________________________________________
> CFRG mailing list -- cfrg@irtf.org
> To unsubscribe send an email to cfrg-leave@irtf.org