proof: implement encrypted proof payload for hashmail and other mailbox based couriers

[Roasbeef]

Background

Today we use the hashmail courier to send proofs from sender to receiver. One unresolved TODO is to use an encryption scheme to preserve privacy between the sender and receiver:

taproot-assets/proof/courier.go

Lines 571 to 583 in 4a0a16c

	// Now that the stream has been initialized, we'll write
	// the proof over the stream.
	//
	// TODO(roasbeef): do ecies here
	log.Infof("Sending receiver proof via sid=%x",
	senderStreamID)
	err = h.mailbox.WriteProof(
	ctx, senderStreamID, proof.Blob,
	)
	if err != nil {
	return fmt.Errorf("failed to send proof "+
	"to asset transfer receiver: %w", err)
	}

This can be generalized to other mailbox-like transports such as nostr.

In the TODO above, I propose using the Elliptic Curve Integrated Encryption Scheme (ECIES), which is a hybrid encryption scheme. In our domain, we can use the script key of the receiver as the main DH point, with the sender generating an ephemeral secret themselves, then doing DH between this points to derive a secret key. The secret key would then be used to encrypt the payload with an AEAD scheme. The final payload is the ephemeral DH point, concatenated with the AEAD payload.

Steps To Completion

• Decide if the courier interface should make this opaque, or create a new superset interface, EncryptedProofCourier

  • No big trade offs here imo, just if we want to have the encryption step be a distinct phase or not. It will require the ability to do a DH with a key, and for the receiver the same as well.
  • Control-flow wise, the diff would be handling the encryption before/after passing the payload to the courier.

• Implement ECIES in a new module (maybe to be upstreamed to btcd/btcec eventually? For the symmetric encryption scheme, we'd likely go with ChaChaPoly.

  • Importantly, we'd want to include the DH point in side the associated data. This serves to fully authenticate the entire payload.

• Update the existing hashmail impl to use this new scheme. We may want to use a new URI for this? Depends on timing w.r.t v0.3 IMO. Either way, clients should have a way to detect if this is being used or not.

[jharveyb]

Instead of an ephemeral secret on the sender side, could we use the private key from one of the keys already being used by the sender during the transfer? Like the top-level taproot key for the first input to the TX.

Then we could address #740 by both parties computing a DH point from those keys and use that to derive a hashmail stream ID / mailbox address.

[Roasbeef]

Fixed by #1587