RFC 9380 requires a domain separation tag that is unique to the protocol using it (§3.1: "a DST that is unique to the protocol"). The crypto draft cites Hash2Curve but supplies no suite string and no DST, so every implementation will pick its own and none will interoperate.
What this crate chose: base DST OR13_EXP_MOLE, with a per-use suffix so each Fiat–Shamir context is separated:
| Use |
DST |
Y = Hash2Curve(m) |
OR13_EXP_MOLE/h2g/m/v1 |
| Pedersen generator |
OR13_EXP_MOLE/h2g/pedersen-H/v1 |
endorsement challenge e |
OR13_EXP_MOLE/chal/endorsement/v1 |
| DLEQ challenge |
OR13_EXP_MOLE/chal/dleq/v1 |
| OR-proof challenge |
OR13_EXP_MOLE/chal/or/v1 |
Why it names this crate and not MoLE: the DST must not squat on a string the eventual specification might want. OR13_EXP_MOLE is deliberately not a plausible spec value, so nothing here can be mistaken for interoperable.
Revisit when the crypto draft assigns a suite. Exposed as exp_ihat::DST_BASE.
Draft text: https://github.com/Moderation-of-unLinkable-Endorsements/internet-drafts/blob/main/draft-authors-mole-crypto.md
Update — upstream PR #39 (open, unmerged)
Partially narrowed by PR #39.
Now specified: the hash-to-curve variant. The text changes from "the Hash2Curve function" to "the RO based Hash2Curve function", which pins the random-oracle suites (..._RO_) rather than the non-uniform ones (..._NU_). That is a real constraint and it was previously ambiguous.
Consequence for our SHA-256 choice: if the group is P-256 (see #1), the RFC 9380 suite is P256_XMD:SHA-256_SSWU_RO_ — which uses SHA-256 internally. So SHA-256 for hash-to-curve is not merely an acceptable guess here; it is what the draft's own implied suite specifies. Our choice matches.
Still unspecified: the DST. RFC 9380 §3.1 requires a DST unique to the protocol, and none is given. PR #39 does introduce two literal hash-to-curve inputs — "IHAT second generator" and "IHAT unknown discrete logarithm point" — but those are messages, not domain separation tags, and no DST accompanies either. An implementation still cannot derive an interoperable DST.
OR13_EXP_MOLE therefore remains correct as a deliberately non-interoperable value.
Update — DSTs revised for P-256
Still open: no DST is specified upstream. But the values changed with the group, and
they now follow RFC 9380 §3.1's convention of naming the suite so that changing the
group necessarily changes the domain:
| Use |
DST |
Y = Hash2Curve(m) |
OR13_EXP_MOLE-V01-h2g-m-with-P256_XMD:SHA-256_SSWU_RO_ |
| second generator |
OR13_EXP_MOLE-V01-h2g-gen2-with-P256_XMD:SHA-256_SSWU_RO_ |
| endorsement challenge |
OR13_EXP_MOLE-V01-chal-endorsement-with-P256_XMD:SHA-256_SSWU_RO_ |
| DLEQ challenge |
OR13_EXP_MOLE-V01-chal-dleq-with-P256_XMD:SHA-256_SSWU_RO_ |
| OR-proof challenge |
OR13_EXP_MOLE-V01-chal-or-with-P256_XMD:SHA-256_SSWU_RO_ |
| scalar sampling |
OR13_EXP_MOLE-V01-rand-with-P256_XMD:SHA-256_SSWU_RO_ |
OR13_EXP_MOLE remains the base, so none of these can be mistaken for a value the
specification might want. exp_ihat::DST_BASE and exp_ihat::SUITE_ID are exposed.
The suite itself is no longer a guess. With the group at P-256, the crypto
draft's "RO based Hash2Curve function" resolves to RFC 9380
P256_XMD:SHA-256_SSWU_RO_, which the profile now uses via p256's hash2curve
feature rather than a hand-rolled expand_message_xmd. Only the DST is still ours.
Update — RESOLVED: the DSTs are specified, in the reference implementation
They were never unguessable — just not in the drafts. ihat-rs fixes four,
and its wire-format doc says they "are not part of the wire format but are fixed by
the protocol":
MOLE-IHAT-P256:H1-nullifier-to-group:v1
MOLE-IHAT-P256:fiat-shamir-getend:v1
MOLE-IHAT-P256:pedersen-generator-H:v1
MOLE-IHAT-P256:fiat-shamir-or-proof:v1
crypto::exp_ihat now uses these verbatim, exposed as DST_H1, DST_FS,
DST_PEDERSEN and DST_OR, with a test pinning the literal strings — a silent drift
here breaks all interoperability and nothing else would catch it.
The OR13_EXP_MOLE values this crate invented are gone, except for one that never
appears on the wire (scalar sampling), which deliberately does not claim the
MOLE-IHAT prefix.
Interoperability confirmed by interop/, both directions. Closing.
Worth noting for upstream: the drafts should state these tags. An implementer
reading only the RFC-track documents cannot derive them, and RFC 9380 §3.1 requires
a protocol-unique DST — so the spec as written is unimplementable without reading
the reference code.
RFC 9380 requires a domain separation tag that is unique to the protocol using it (§3.1: "a DST that is unique to the protocol"). The crypto draft cites Hash2Curve but supplies no suite string and no DST, so every implementation will pick its own and none will interoperate.
What this crate chose: base DST
OR13_EXP_MOLE, with a per-use suffix so each Fiat–Shamir context is separated:Y = Hash2Curve(m)OR13_EXP_MOLE/h2g/m/v1OR13_EXP_MOLE/h2g/pedersen-H/v1eOR13_EXP_MOLE/chal/endorsement/v1OR13_EXP_MOLE/chal/dleq/v1OR13_EXP_MOLE/chal/or/v1Why it names this crate and not MoLE: the DST must not squat on a string the eventual specification might want.
OR13_EXP_MOLEis deliberately not a plausible spec value, so nothing here can be mistaken for interoperable.Revisit when the crypto draft assigns a suite. Exposed as
exp_ihat::DST_BASE.Draft text: https://github.com/Moderation-of-unLinkable-Endorsements/internet-drafts/blob/main/draft-authors-mole-crypto.md
Update — upstream PR #39 (open, unmerged)
Partially narrowed by PR #39.
Now specified: the hash-to-curve variant. The text changes from "the Hash2Curve function" to "the RO based Hash2Curve function", which pins the random-oracle suites (
..._RO_) rather than the non-uniform ones (..._NU_). That is a real constraint and it was previously ambiguous.Consequence for our SHA-256 choice: if the group is P-256 (see #1), the RFC 9380 suite is
P256_XMD:SHA-256_SSWU_RO_— which uses SHA-256 internally. So SHA-256 for hash-to-curve is not merely an acceptable guess here; it is what the draft's own implied suite specifies. Our choice matches.Still unspecified: the DST. RFC 9380 §3.1 requires a DST unique to the protocol, and none is given. PR #39 does introduce two literal hash-to-curve inputs —
"IHAT second generator"and"IHAT unknown discrete logarithm point"— but those are messages, not domain separation tags, and no DST accompanies either. An implementation still cannot derive an interoperable DST.OR13_EXP_MOLEtherefore remains correct as a deliberately non-interoperable value.Update — DSTs revised for P-256
Still open: no DST is specified upstream. But the values changed with the group, and
they now follow RFC 9380 §3.1's convention of naming the suite so that changing the
group necessarily changes the domain:
Y = Hash2Curve(m)OR13_EXP_MOLE-V01-h2g-m-with-P256_XMD:SHA-256_SSWU_RO_OR13_EXP_MOLE-V01-h2g-gen2-with-P256_XMD:SHA-256_SSWU_RO_OR13_EXP_MOLE-V01-chal-endorsement-with-P256_XMD:SHA-256_SSWU_RO_OR13_EXP_MOLE-V01-chal-dleq-with-P256_XMD:SHA-256_SSWU_RO_OR13_EXP_MOLE-V01-chal-or-with-P256_XMD:SHA-256_SSWU_RO_OR13_EXP_MOLE-V01-rand-with-P256_XMD:SHA-256_SSWU_RO_OR13_EXP_MOLEremains the base, so none of these can be mistaken for a value thespecification might want.
exp_ihat::DST_BASEandexp_ihat::SUITE_IDare exposed.The suite itself is no longer a guess. With the group at P-256, the crypto
draft's "RO based Hash2Curve function" resolves to RFC 9380
P256_XMD:SHA-256_SSWU_RO_, which the profile now uses viap256'shash2curvefeature rather than a hand-rolled
expand_message_xmd. Only the DST is still ours.Update — RESOLVED: the DSTs are specified, in the reference implementation
They were never unguessable — just not in the drafts.
ihat-rsfixes four,and its wire-format doc says they "are not part of the wire format but are fixed by
the protocol":
crypto::exp_ihatnow uses these verbatim, exposed asDST_H1,DST_FS,DST_PEDERSENandDST_OR, with a test pinning the literal strings — a silent drifthere breaks all interoperability and nothing else would catch it.
The
OR13_EXP_MOLEvalues this crate invented are gone, except for one that neverappears on the wire (scalar sampling), which deliberately does not claim the
MOLE-IHATprefix.Interoperability confirmed by
interop/, both directions. Closing.Worth noting for upstream: the drafts should state these tags. An implementer
reading only the RFC-track documents cannot derive them, and RFC 9380 §3.1 requires
a protocol-unique DST — so the spec as written is unimplementable without reading
the reference code.