BOLT04: Add rationale for constant error decryption.

[ziggie1984]

Fixes #1125

[t-bast]

Shouldn't we instead just get rid of this section entirely? This is completely useless, isn't it? I don't see how timing the decryption steps of the error message can be useful to any attacker, as there is a lot of random delay before a retry that is orders of magnitude larger (path-finding and network latency).

[ziggie1984]

Agree, either we get rid of the whole section or we introduce the rationale because when I was reading this part of the spec I had a hard time understanding the reasoning behind it. LND has implemented it, it actually does the 27 decryption cycle so maybe keep it? But open for both approaches, wdyt @morehouse

[t-bast]

LND has implemented it, it actually does the 27 decryption cycle

Then it's probably a good idea to simplify lnd by removing that extra code if it's useless 😉
This timing information seems completely unusable by an attacker to me, but maybe I'm missing something.

[ProofOfKeags]

I would like to second the opinion that it seems entirely useless. Two reasons for this.

1. Like y'all have already stated, network delay middle 50% variance probably dwarfs the entirety of the decryption process.
2. Learning your relative position in the route is pretty useless beyond 3 hops. It is important to make it hard to distinguish whether your upstream is the sender or a forwarder, but let's say you know you're hop number 6... what then?! I'm supposedly 6 degrees of separation from everyone on the planet, so you've successfully ascertained it could be....anyone...

All that said, this PR aims to clarify and for as long as we continue to have the normative requirement to do that extra decryption. I support merging this as the rationale to clarify the purpose of this (seemingly ridiculous) practice.

[t-bast]

This was discussed during the last two spec meetings, and it was agreed that this specific decryption step isn't really a fingerprinting vector. But there are other fingerprinting vectors when retrying payments, so this section should be re-worked to explain that generally, as a payment sender, you should ensure you're protecting against fingerprinting by adding random delays before retries and trying as much as possible to be constant time in most operations.

[Roasbeef]

LGTM 🦎

[ProofOfKeags]

This immediate commit is better for consistency and clarity of the existing spec. However, the "real solution" to this is to generalize the recommendation to say that the sender SHOULD implement reasonable defenses against timing attacks by inserting a random delay before retrying.