mirrors/lightning-bolts
1
0
Fork 0
mirror of https://github.com/lightning/bolts.git synced 2024-11-19 01:50:03 +01:00
Code Issues Projects Releases Wiki Activity

BOLT04: Add rationale for constant error decryption. (#1154)

Browse Source 
To avoid timing analysis when decrypting failed payments the sender
should act as if the failure in the route came for the 27th hop.
Also changed the maximum number of hops in the route from 20 (legacy)
to 27 (tlv onion).
This commit is contained in:
ziggieXXX 2024-07-02 12:03:54 +02:00 committed by GitHub
parent c562d91ace
commit 64ce121cdc
No known key found for this signature in database
GPG Key ID: B5690EEEBB952194
1 changed files with 9 additions and 1 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

10
04-onion-routing.md
View File

@ -1057,9 +1057,17 @@ The _erring node_:
The _origin node_: The _origin node_:
- once the return message has been decrypted: - once the return message has been decrypted:
- SHOULD store a copy of the message. - SHOULD store a copy of the message.
- SHOULD continue decrypting, until the loop has been repeated 20 times. - SHOULD continue decrypting, until the loop has been repeated 27 times
(maximum route length of tlv payload type).
- SHOULD use constant `ammag` and `um` keys to obfuscate the route length. - SHOULD use constant `ammag` and `um` keys to obfuscate the route length.
### Rationale
The requirements for the _origin node_ should help hide the payment sender.
By continuing decrypting 27 times (dummy decryption cycles after the error is found)
the erroring node cannot learn its relative position in the route by performing
a timing analysis if the sender were to retry the same route multiple times.
## Failure Messages ## Failure Messages
The failure message encapsulated in `failuremsg` has an identical format as The failure message encapsulated in `failuremsg` has an identical format as