[feature]: Require authentication of recipient before removal of proof trimming during hashmail delivery

[dstadulis]

trafficstars

Is your feature request related to a problem? Please describe. Currently the hashmail server removes stashed proofs when any client retrieves the stashed proof. This can lead to premature removal of the proof file before the intended recipient has been able to download the proof.

Describe the solution you'd like Add a lean method of authentication, possibly a MAC, the hashmail will check before wiping the proof.

Describe alternatives you've considered Tolerate griefing activity -- though this hasn't been observed in practice

[Roasbeef]

Duplicate of https://github.com/lightninglabs/taproot-assets/issues/478?

[guggero]

I don't think so. #478 is about encrypting the content sent over the courier while this is about authenticating the sender and receiver when using a hashmail box (to avoid a malicious actor to read a proof from the mailbox before the intended recipient can do it).

[dstadulis]

Duplicate of #478?

IIUC #478 covers the data-at-rest privacy of the proof payload but doesn't cover when that proof data should be removed. Maybe, proof-retriever authentication is a by product of #478's cryptography scheme?

@ffranr and I desire was to modify hashmail's proof-deletion code until after receiver authentication to mitigate premature deletion.

[jharveyb]

I added a comment on #478 about this issue, I agree that they aren't the same but we could use DH to derive a hashmail stream ID / address. Instead of authenticating the proof receiver, we have a stream ID that can only be computed by the sender and receiver, and I think that would work for preventing griefing.