Making Mixnets from OHTTP

[DanGould]

1. https://github.com/orgs/payjoin/discussions/582: The possibility of Sphinx based multihop on OHTTP: Mixnet-like, onion like behavior. Should this be done to improve security model on 2-hop relay?
2. https://github.com/orgs/payjoin/discussions/679: Should we send p2p cover traffic in order to harden against passive adversary? Two contacts may establish a long-lived channel to send cover traffic in a sequence of mailboxes.
3. https://github.com/orgs/payjoin/discussions/681 Should we use QUIC / HTTP/3 for better transport layer privacy? Does this better resist traffic analysis? Client connection establishment can be faster if QUIC is used.
4. https://github.com/orgs/payjoin/discussions/680 Do we extend HPKE with post-quantum secure algorithms? If traffic is recorded today, it could be broken later, breaking privacy.
5. Rate limiting credentials

Problems with Tor in a mobile settings

• Onion routed overlay
• Connect to DB
• Update consensus info from it
• 2 round trips to guard node

How does Sphinx Relate to OHTTP

Why not multihop OHTTP?

https://github.com/orgs/payjoin/discussions/582

We can. Take 7168 byte encrypted payload in body of POST request. The outer layer is 8192 bytes. Then there's some overhead. In theory, we can go one more. we don't need the 1024 difference in side at every layer. The relay URI is variable, necessary 65 bytes of KEM, 16 bytes AEAD tag, 7 bytes OHTTP message header, ~100 bytes total per hop.

If a relay has an OHTTP Gateway, and some other relay forwards to the first relay, which forwards to a directory, then we have multi-hop OHTTP requests. it would be connection-oriented but only for a single request. This is a regression from Tor's full duplex stream but we're not interested in that because we're not trying to do web browsing (Which can be 10s of requests per connection).

If the data size grows, then we gain no real defense against traffic analysis. The 100 byte overhead is an obvious signature to a global passive adversary.

How does Sphinx relate to this?

sphinx is an onion wrapping approach to messsages. Lightning uses a sphinx-based design. How can we use it for OHTTP? When a relay receives an onion packet, it decrypts it and verifies it with a TAG, then it computes some deterministic padding data from its shared secret with the original sender, appends the appropriate number of padding bytes to the nested message. payload is less than 8192 bytes and it gets filled in by the padding key stream.

For example original 7900 byte payload, 1st relay gets 8000 byte payload cause the overhead of next hop is within its payload, extends to 8192 byte payload. 2nd relay can't tell where in the ciphertext the padding data computed by the 1st relay starts. The 2nd relay strips, pads with own shared secret, then passes off to the directory. The BHTTP request is random padded instead of null padded.

If packet size and message size is uniform then we can add opt-in delays and cover traffic to
deploy a full-on mixnet.

Async nature makes this approach useful for e.g. sender-initiated payjoin.

@DanGould

When would it become priority to build something like this

@nothingmuch

Might be useful for multiparty messaging (but not a very good reason to do it)
If we argue payjoin should have global passive adversary protections then we already need it.
It does not seem to me that the transport layer is the most urgent concern. On-chain clustering
seems like our problem now. This comes after.

Why is this exciting more generally?

Lightning could be considered a general onion-routed privacy overlay network, but it's poorly
accessible from mobile clients, and virtually inaccessible on web clients.

OHTTP allows for a general privacy overlay moreso than Lightning. Lightning ties gossip to pubic channels for ~DoS protection.

A straightforward DoS resistance approach for OHTTP Mixnet is to exchange rate limiting
credentials for utxo proofs. That way bandwidth could be allocated anonymously.

For V3 if we wanted an orderbook that fascilitated introductions, such an overlay would be a
useful primitive.

This might be a compelling way to bridge Lightning to Web clients since it would let Web clients make connections to the lightning network using HTTP. Maybe it could be used for Nunchuk tx
coordination. Maybe Nostr wallet connect. Hmm.

There seems to be a niche for bitcoin private communication infrastructure. Bitcoin relatedness
(tying auth to utxo ownership) might fix auth w/ market mechanism.

TODO

• @nothigmuch random pad requests instead of null pad
• Document random null pad in BIP 77