Consider Making pjv2 payloads and IDs Uniform so they Might be Indistinguishable from Future Protocols' #371
Comments
|
Upon more careful reading of RFC 9180, it appears that key encapsulation does not make use of the PSK. Therefore in order to achieve bit uniformity of HPKE payloads, the encapsulated key would need be be additionally encrypted using a pre-shared secret (e.g. same entropy from which HPKE PSK would be derived). |
DanGould
changed the title
|
after DanGould#6 in #364 I believe pjv2 payloads are uniform, assuming HPKE Base and HPKE Auth modes produce uniform payloads |
If it were desirable to separate the pubkey from the URL for a dumb way to make IDs uniform, a BIP78 backwards compatible send could pass the pubkey to the directory as a query string parameter, contingent on bip78 implementations reading and re-using the query string provided in the bip21 pj param. The directory v1 endpoint could then derive the uniform subdir id that the v2 receiver listens on, thereby only revealing that they're listening using the v2 protocol if the v1 protocol is initiated by a sender. edit: upon code review of BTCPayServer.BIP78's Sender, its URL mutating code is not sophisticated enough to respect this rule without further changes |
Couldn't we still use EllSwift for the bip21 without changing the DHKEM? This is akin to the current way we serialize the directory pubkey as a Compressed Public key but then deserialize as an Uncompressed Public Keys for the actual DHKEM operations. We could also make the |
|
Replying for the sake of posterity since we already discussed it, ElligatorSwift as used in BIP 324 specifies x-only public keys, but x-only is not a requirement for the libsecp256k1 implementation, so indeed no DHKEM changes are needed and EllSwift can be used as purely a serialization/encoding thing |
For censorship resistance and privacy different usage patterns of the directory should be indistinguishable to the directory operator.
Ideally this would apply to different versions of the protocol but since BIP 77 is backwards compatible with BIP 78 and payloads aren't encrypted in BIP 78 that isn't possible for v1 and v2.
What does remain possible is to accommodate future protocols, by making it easier to match the distribution of BIP 77 traffic.
Current patterns
Subdirectory IDs are compressed secp256k1 points encoded as url safe base64. This implies the first byte is a 0x02 or 0x03, and that the remainder of the types encode a valid x coordinate.
Payloads are use HPKE based the draft secp256k1 DHKEM. This begins with an uncompressed encoding of the DH curve point used for a shared secret derivation. This consists of an 0x01 byte, followed by a pair of valid coordinates. Assuming #364 (review) addressed, this should be the only detectable pattern since the subsequent ciphertext would appear to distribute uniformly.
Simulating these patterns is relatively straightforward. Both IDs and DHKEM point can just be sampled randomly. They might also be hash-to-curve or tweaked points comitting to a hash of arbitrary data. Producing this costs at least single curve multiplication (public key derivation).
Uniformly Distributed Bit Patterns
If both IDs and payloads were entirely uniform future protocols would simply have to likewise appear uniform to the directory, and not to simulate the bit patterns currently implemented.
Achieving this requires the sender and receiver to share a secret that the directory does not know, or using uniformly distributed encodings.
Relation to append semantics described in #365
If multiple writers are appending to the same subdirectory, keeping their writes indistinguishable means every append would need either perform or simulate a DHKEM, wasting 65 bytes per write, and this is a larger % of the data if writes are smaller.
Bit uniformity in the payloads that covers the KEM as well would allow established secrets to be used for subsequent messages as appropriate, reducing the overhead.
Backwards incompatible, bit uniform BIP 77
By specifying a different BIP 21 format, e.g.
?pjv2=<base_url>&pubkey=<...>that isn't backwards compatible with BIP 78, two differently tagged hashes of the public key could instead be used, the first as the ID (appended to the base URL) and the second as a PSK for the HPKE.In this approach the ID would be 256 uniform bits, and both the key encapsulation and the ciphertext would be further protected (and authenticated) by the PSK. The directory would not learn the receiver's public key used in HPKE.
With the current
?pj=param retaining backwards compatibility with BIP 78 this would not work: even if the key was specified to be mangled, because simply polling for v1 sender requests, even if the sender only supports v2, would reveal the public key to the directory, and with it the PSK, reverting to the indistinguishably guarantees of the current approach.EllSwift
EllSwift for secp256k1 as specified by BIP 324 is a way of encoding x-only public keys as uniformly distributed 512 bit strings, and by making every 512 bit string decodable as a curve point.
If IDs were encoded this way bit uniformity would be achieved, but at the cost of doubling the ID size, which would encumbers on BIP 21 encoding in QR codes.
If DHKEM were done this way, this would provide the desired properties. No draft IETF DHKEM standard exists for this, and implementing EllSwift is involved.
short ID, public key as separate BIP 21 parameter
Since the number of subdirectories per directory can and should be strongly bounded, collision resistance could be relaxed by using a shorter ID (e.g. 96 bits).
A public key can then be specified as a fragment parameter, and this could be used to derived a PSK as well.
Shortening the ID would be problematic for future protocols that may need the ID to be collision resistant or strongly binding, but this would significantly reduces the BIP 21 overhead over the EllSwift ID approach, and require no changes to the DHKEM.
receiver's public key in ID, low entropy PSK (best compromise?)
Against the PSK reccomendations of RFC 9180, a low entropy PSK could be used instead.
Since the receiver's public key, and not this PSK would not be used for authentication of the receiver's response (the payjoin PSBT), but this seems justifiable as it only provides privacy and not integrity or authenticity, for which the receiver's public key is used.
dubious: x-only IDs with noise?
Using x-only coordinates with an additional noise term that is still uniquely decodable is not indistinguishable from random bits. However given a set of 256 bit strings, correctly classifying a specific target as either x coordinates or random strings might be sufficiently hard for the directory so as to provide censorship resistance.
This hack might make it possible to avoid hash-to-curve and just use a 256 bit image directly as the ID in future protocols.
If I'm not mistaken the directory may be able to estimate (how well?) the rate of usage due to a weak bias in aggregate, but it's possible that censoring individual requests on the basis of the decision problem of whether they do or do not encode a secp256k1 point would still be hard.
However, it's very likely that I'm wrong about this.
Alternatives to BIP 21 and future proofing
With BIP 353 gaining adoption and the discussion about sender initiated payjoins using silent payments in #365, alternatives to BIP 21 and especially BIP 21 in QR codes may become more available.
Since such approaches would not need to maintain compatibility with BIP 78, they would not be as constrained by BIP 21 QR encoding limitations.
512 bit post quantum collision resistant IDs may be appropriate eventually, but since this will certainly involve a script upgrade to bitcoin and potentially much larger witnesses and therefore transactions, and because of the downsides it seems more appropriate not to take this into consideration.
The text was updated successfully, but these errors were encountered: