secp256k1 DHKEM point encoding

[nothingmuch]

The draft secp256k1 DHKEM spec uses the same approach as the NIST P curve specs and uses uncompressed points while also specifying they MUST be validated, which is essentially the same as decoding compressed points.

"Compact" variants have been proposed to optimize this.

Due to padding this is likely a negligible overhead for BIP 77, so doesn't warrant a change, but due to BIP 324 libsecp256k1 for the most part support EllSwift encoding, which encodes curve points as uniform bytes.

This would make HPKE encrypted messages indistinguishable from random noise to the directory, so perhaps has some plausible deniability or censorship resistance advantages.

However, the payoff seems marginal and mostly to do with code complexity, since achieving the same uniformity would be possible by simply wrapping all messages that may extend BIP 77 or diverge from it using the current approach. Nonetheless I thought it was worth writing this down somewhere and Dan suggested a discussion so here it is.

[DanGould]

Our bitcoin-HPKE implementatin lets us implement new DHKEMs with declarative macros. Follow the template to get a new DHKEM.

@Kixunil brought this up before, but I didn't understand what benefit ElligatorSwift had, because my understanding was only that it was used for unauthenticated encryption and we needed authenticated encyption. I no longer believe EllSwift is incompatible with authenticated encryption. I'll reiterate:

[EllSwift DHKEM point encoding] would make HPKE encrypted messages indistinguishable from random noise to the directory, so perhaps has some plausible deniability or censorship resistance advantages.

This is because our payloads include an ephemeral public key passed in plaintext.

I wonder if EllSwift has an application to improve metadata privacy in the planned Nostr OpenMLS E2EE proposal

[nothingmuch]

FWIW i misspoke, it's not "the same uniformity", rather achieving uniformity in the set of valid messages. For the existing spec this means uniformly random group element in uncompressed encoding, followed by uniformly random bits, so individual requests would still appear to distribute uniformly in the space of possible requests, even though the bits don't.

Secondly, I would like to clarify that the main benefit of indistinguishable indistinguishable subdirectory IDs and payloads is protocols can be upgraded without needing to worry about that wrapping and hiding, so long as the upgraded protocol also satisfies this notion.

Perhaps for this reason it would be better to use a tagged (domain separated by protocol version, hpke params, with type tag e.g. "ID") hash of the elliptic curve point as the subdirectory ID, and then use another tagged (same domain separation information, type separator e.g. "PSK") hash of the same preimage as the a PSK component.

This would get bit uniformity-to-the-directory, assuming pubkeys are ephemeral and not reused, with no modifications to the current HPKE, but due to domain separation makes it easy to upgrade, a BIP 21 or perhaps BOLT 12 level specification that specifies or reaches agreement on something else will have automatic domain separation, allowing clients to support independent ones without much trouble and without requiring different protocols to need Elligator or EllSwift encodings, or wrap everything in the draft secp256k1 DHKEM

From the directory's point of view, subdirectory IDs should just be specified as 256 cryptographically pseudorandom bits, encoded in url safe base64. This should work for any combination of collision resistant hash function with at least 256 bits of output.

[nothingmuch]

opened #371 since this makes more of a difference than i first anticipated