Hacked up a "constant message size" change for CLN, inspired by https://github.com/lightning/bolts/pull/1304
There have been a number is papers showing how trivial it is for someone with a network view to identify which messages are Lightning payments. The first mitigation is to make the TCP packet sizes identical (the rest have to do with timings, but this is a prerequisite).
The approach here is wrong: you need to attack it lower level than message construction. You need it post-encryption where you do the write(). Fortunately, we have explicit padding messages for this in the spec! Pings which do not elicit a reply.
But testing is vital: it's easy to slip up and have weird packet sizes slip though and leak all your info even though everything "works fine"!
There have been a number is papers showing how trivial it is for someone with a network view to identify which messages are Lightning payments. The first mitigation is to make the TCP packet sizes identical (the rest have to do with timings, but this is a prerequisite).
The approach here is wrong: you need to attack it lower level than message construction. You need it post-encryption where you do the write(). Fortunately, we have explicit padding messages for this in the spec! Pings which do not elicit a reply.
But testing is vital: it's easy to slip up and have weird packet sizes slip though and leak all your info even though everything "works fine"!