Randomize initial onion packet data. #403
Conversation
TheBlueMatt
force-pushed
the
2019-11-rand-onion
branch
from
9714cb4 to
500a69a
Compare
|
Okay would go tomorrow through the whole issue+ml announcement to double-check the fix is right. |
There was a problem hiding this comment.
From the paper : "The exit node hence can learn the length of the chosen path
with the following attack: The adversarial exit node observes
(after XORing) where the first 1 bit after the identifier is.
It knows that the filler string starts there or earlier and can
determine by the length of the filler string a lower bound on
the length of the path used."
If I understand correctly the heuristic lies on given a filler starting in the packet, I can deduce the previous size allocated for message headers (in LN the hops_payload), but assuming message headers size is known (at least in v0 onion) isn't the whole length of the path leaked ?
| @@ -224,6 +224,7 @@ mod real_chacha { | |||
| self.offset = 0; | |||
| } | |||
|
|
|||
| #[inline] // Useful cause input may be 0s on stack that should be optimized out | |||
There was a problem hiding this comment.
A warn against too smart compiler which would align stack after function jump?
There was a problem hiding this comment.
Hmm? Not sure what you're asking.
There was a problem hiding this comment.
Wasn't asking anything, just wanted to be sure that inline was to prevent compiler alignement.
There was a problem hiding this comment.
Not sure what you mean by "alignment", but, in any case, afaiu, #[inline] has two meanings:
- for pub fns it allows inlining across crates, which is normally only possible with lto,
- for regular fns its just a hint to the compiler that it should try inlining, which it is free to completely ignore if it likes.
This avoids at least the trivial hop count discovery attack, though other obvious ones remain and are slightly harder to avoid. See lightning/bolts#697
TheBlueMatt
force-pushed
the
2019-11-rand-onion
branch
from
56996b6 to
fd1d5fd
Compare
|
ACK fd1d5fd, that's okay for now but let's not abuse conditional compilation for testing. |
|
Ehh, we do it in a number of places already for fuzztarget, and exposing the onion data just for testing is grosser than just throwing test code in... |
This avoids at least the trivial hop count discovery attack, though
other obvious ones remain and are slightly harder to avoid.
See lightning/bolts#697