--- Log opened Tue Jul 25 00:00:09 2023 00:36 -!- jespada [~jespada@cpc121308-nmal25-2-0-cust15.19-2.cable.virginm.net] has quit [Ping timeout: 250 seconds] 00:44 -!- jespada [~jespada@cpc121308-nmal25-2-0-cust15.19-2.cable.virginm.net] has joined #lightning-dev 00:52 -!- AaronvanW [~AaronvanW@user/AaronvanW] has quit [Quit: Leaving...] 01:00 -!- riclas [~riclas@26.27.71.148.rev.vodafone.pt] has joined #lightning-dev 01:07 -!- riclas [~riclas@26.27.71.148.rev.vodafone.pt] has quit [Ping timeout: 260 seconds] 01:08 -!- whysthatso125070 [~whysthats@74-206-50-195.sta.estpak.ee] has quit [Read error: Connection reset by peer] 01:09 -!- whysthatso125070 [~whysthats@74-206-50-195.sta.estpak.ee] has joined #lightning-dev 02:55 -!- ghost43 [~ghost43@gateway/tor-sasl/ghost43] has quit [Ping timeout: 240 seconds] 03:13 < vincenzopalazzo> I was reading this https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev related to the packet size. Is it possible with the padding solution still to guess the length of the message? Imagine if I know the length of one message without padding, and I know the additional news that the node is using for padding. Can I get the length of the message back by tripping the pong messages and match on the size of the remains? 03:13 < vincenzopalazzo> or I am missing somethings inside the Noise encryption? 03:23 < _tnull> "I was reading this https://lists..." <- > <@vincenzopalazzo:matrix.org> I was reading this https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev related to the packet size. Is it possible with the padding solution still to guess the length of the message? Imagine if I know the length of one... (full message at ) 03:24 < vincenzopalazzo> yeah it istnull sorry for the broken link 03:24 < _tnull> This should be the right one?: https://lists.linuxfoundation.org/pipermail/lightning-dev/2023-June/004000.html 03:24 < vincenzopalazzo> yeah I was looking for the link, thanks 03:25 < _tnull> How would a network-level adversary know the 'additional news'? 03:26 < vincenzopalazzo> do you mean how at the network level someone know that we are padding? 03:27 < _tnull> Yeah, not only that we're padding but also how long the padding is. Sure, if you knew that you could subtract that and arrive at the original packet size, but this shouldn't be possible of course. 03:27 -!- riclas [~riclas@26.27.71.148.rev.vodafone.pt] has joined #lightning-dev 03:28 < _tnull> For context, this is the paper discussing such network-level attacks: https://muoitran.com/publications/revelio.pdf 03:28 < vincenzopalazzo> I will read the paper thanks, I was missing it 03:29 < vincenzopalazzo> tnull: Mh yeah right my point is this that if we do padding with a static message inside the code, anyone that have access to the code can try to do this understanding of the network 03:29 < vincenzopalazzo> but maybe I am missing something 03:34 < _tnull> I think the main point is that the observable packet sizes going over the wire should have a uniform size, whether we do that by appending a TLV field or by piggybacking PING/PONG messages (I imagine getting this exactly right might be easier with the former approach). 03:36 < _tnull> Additionally we might want to put some effort into making the messaging patterns unrecognizeable, i.e., essentially introducing some cover traffic through PINGs/PONGs if there is no real traffic to be sent. 03:41 < _tnull> I think both have been discussed in NYC, where, IIRC, the need for message padding was entirely uncontroversial, while we concluded that cover traffic could be an additional feature that implementations might want to disable if there are heavy bandwidth constraints. 03:43 < _tnull> * i.e., essentially applying Poisson mixing while introducing some 03:46 < _tnull> * Additionally we might want to put some effort into making the messaging patterns unrecognizeable, e.g., essentially applying Poisson mixing while introducing some cover traffic through PINGs/PONGs if there is no real traffic to be sent. 03:50 < vincenzopalazzo> yeah I agree on the second point, but also on the first. My only point is why do not decide the padding length at handshake time? and padding with a known size only the init msg. The init message is not a big deal if was catch because if we are exchange message with a peer we are for sure connected 03:51 < vincenzopalazzo> I know that is was discussed in NY but I need some time to process it otherwise I will say no sense things :) 03:59 < _tnull> "yeah I agree on the second point..." <- Mh, I'm not sure I'm following. We should pad all messages to the same length so that they become indistinguishable to a network-level attacker. The authors of above paper describe the issue pretty well: "In LN specifications [40], the communication between two LN nodes involves multiple messages, each encapsulated in a single TCP packet. Despite the messages being encrypted under the 03:59 < _tnull> Noise Protocol Framework [43], they do not apply any random padding. The adversary, thus, can use the size of the TCP payload to deduce the LN message type. (...) For example, the adversary can identify a new payment made on an observed channel by looking for the update_add_htlc message with a payload size of 1452 Bytes." 04:05 -!- test_ [flooded@gateway/vpn/protonvpn/flood/x-43489060] has joined #lightning-dev 04:06 < vincenzopalazzo> yeah, I did not read the paper yet because in the ML there was no link. I will read it, but my question still stands, if we pad with a pong message and we implement it, anyone that has to the code could do the reverse engineering to understand the length of the actual message (they know the real message length because they found the size already, no?) 04:09 -!- flooded [flooded@gateway/vpn/protonvpn/flood/x-43489060] has quit [Ping timeout: 252 seconds] 04:13 < _tnull> Eh no, we should really pad all messages of all types to the same payload length (1472 bytes to fit in the 1500 byte mtu I guess). Whether we do that via a TLV field or PONGs is rather irrelevant. 04:15 < _tnull> So an adversary would only get a bunch of 1472 byte payload blobs on the wire and can't infer anything else really because all have exactly the same size. No 'reverse engineering' possible as they can't figure out how much padding was applied to arrive at that 1472 byte payload size. 04:17 < _tnull> "yeah, I did not read the paper..." <- I think you're confusing *internal* and *external* attackers. We're trying to protect against an *external* network-level attacker that doesn't have access to any keys, i.e., can't look into the encrypted payloads. However, they currently would still be able to observe which message types are transmitted just by observing the characteristic message payload lengths alone. 04:22 < _tnull> > <@vincenzopalazzo:matrix.org> yeah, I did not read the paper yet because in the ML there was no link. I will read it, but my question still stands, if we pad with a pong message and we implement it, anyone that has to the code could do the reverse engineering to understand the length of the actual message (they know the real message length because they found the size already, no?) 04:22 < _tnull> * I think you're confusing _internal_ and _external_ attackers. We're trying to protect against an _external_ network-level attacker that doesn't have access to any keys, i.e., can't look into the encrypted payloads. However, they currently would still be able to observe which message types are transmitted just by observing and classifying messages according to their characteristic payload lengths on the wire. 05:13 -!- flooded [flooded@gateway/vpn/protonvpn/flood/x-43489060] has joined #lightning-dev 05:17 -!- test_ [flooded@gateway/vpn/protonvpn/flood/x-43489060] has quit [Ping timeout: 250 seconds] 05:19 -!- ghost43 [~ghost43@gateway/tor-sasl/ghost43] has joined #lightning-dev 05:30 -!- b_101 [~robert@static-198-54-129-102.cust.tzulo.com] has joined #lightning-dev 05:34 -!- b_101 [~robert@static-198-54-129-102.cust.tzulo.com] has quit [Ping timeout: 246 seconds] 05:39 -!- bitdex [~bitdex@gateway/tor-sasl/bitdex] has quit [Quit: = ""] 05:56 < vincenzopalazzo> <_tnull> "I think you're confusing *..." <- So from an external network-level attacker I can not do something like `pad-lnmsg = lnmsg + pong*times` -> `lnmsg = pad-lnmsg - pong*time` if I know how it is big the `pong` message? 06:27 < _tnull> "So from an external network-..." <- Right, every `pad-lnmsg` payload would have exactly the same size and the adversary therefore couldn't infer more than "oh, it's likely *a* padded lightning message". 06:28 < _tnull> At least that's what we should aim for. 06:28 < vincenzopalazzo> _tnull: aaah 06:28 < vincenzopalazzo> wait I am assuming that the attacher know that this packet is a lightning network one 06:29 < _tnull> Yeah, even if they do it shouldn't allow them to tell any of the packets apart 06:29 < vincenzopalazzo> ok now make sense to me, thanks to drive me in the correct direction 06:30 < _tnull> Sure! 06:35 < instagibbs> (aside from timing analysis) 06:37 < cdecker[m]> Notice that the attacker can very well see how packages are fragmented, and infer from that if there was a single large packet going through or a small real payload + a padding. Thus to really implement this level of obfuscation would require us to coalesce the non-onion packets with their padding into a single TCP package. Easily overlooked, but if we're going sledgehammer mode and pad everything we must make sure those efforts are not 06:37 < cdecker[m]> in vain ;-) 06:40 < _tnull> instagibbs: Yup, timed/Poisson mixing would probably help with that somewhat, but then again we probably want to be cautious how much latency we're adding to *all* messages. Size padding would at least an initial step. 06:40 -!- tnull [~tnull@user/tnull/x-8645464] has joined #lightning-dev 06:44 < _tnull> cdecker: Right, such nuances was what I referred to with "At least that's what we should aim for" above, as I'm not entirely sure we can catch all special at one go, without overhauling too much of the protocol.. 06:50 -!- tnull [~tnull@user/tnull/x-8645464] has quit [Quit: tnull] 07:25 < cdecker[m]> We could also go the other way, and trade off time for privacy instead of bandwidth for privacy: by taking large messages and splitting it into randomly sized smaller packages and then adding random delays in-between those chunks we can make large onion packages look like many smaller control packages, at the expense of simulating a much slower link between the peers. 07:25 < cdecker[m]> Both variants seem very heavy handed though, and imposing this larg(ish) cost to performance for privacy's sake may cause many users to opt out of these obfuscation techniques, if the cost is perceived as too high. 07:29 -!- jon_atack [~jonatack@user/jonatack] has quit [Read error: Connection reset by peer] 07:29 -!- jonatack1 [~jonatack@user/jonatack] has joined #lightning-dev 08:23 -!- test_ [flooded@gateway/vpn/protonvpn/flood/x-43489060] has joined #lightning-dev 08:27 -!- flooded [flooded@gateway/vpn/protonvpn/flood/x-43489060] has quit [Ping timeout: 260 seconds] 08:34 -!- achow101 [~achow101@user/achow101] has quit [Quit: Bye] 08:34 -!- achow101 [~achow101@user/achow101] has joined #lightning-dev 08:37 < BlueMatt[m]> Padding few-byte messages out to a packet doesn’t seem like a high cost to me :p 08:37 < BlueMatt[m]> Going full cbr would be 08:42 -!- jarthur [~jarthur@user/jarthur] has joined #lightning-dev 08:46 -!- b_101 [~robert@static-198-54-129-102.cust.tzulo.com] has joined #lightning-dev 10:31 -!- b_101_ [~robert@189.236.37.53] has joined #lightning-dev 10:33 -!- b_101 [~robert@static-198-54-129-102.cust.tzulo.com] has quit [Ping timeout: 250 seconds] 11:30 -!- b_101 [~robert@static-198-54-129-102.cust.tzulo.com] has joined #lightning-dev 11:31 -!- b_101_ [~robert@189.236.37.53] has quit [Read error: Connection reset by peer] 11:32 -!- flooded [flooded@gateway/vpn/protonvpn/flood/x-43489060] has joined #lightning-dev 11:34 -!- test__ [flooded@gateway/vpn/protonvpn/flood/x-43489060] has joined #lightning-dev 11:35 -!- b_101 [~robert@static-198-54-129-102.cust.tzulo.com] has quit [Ping timeout: 245 seconds] 11:35 -!- b_101_ [~robert@189.236.37.53] has joined #lightning-dev 11:36 -!- test_ [flooded@gateway/vpn/protonvpn/flood/x-43489060] has quit [Ping timeout: 260 seconds] 11:36 -!- test_ [flooded@gateway/vpn/protonvpn/flood/x-43489060] has joined #lightning-dev 11:37 -!- flooded [flooded@gateway/vpn/protonvpn/flood/x-43489060] has quit [Ping timeout: 240 seconds] 11:40 -!- test__ [flooded@gateway/vpn/protonvpn/flood/x-43489060] has quit [Ping timeout: 240 seconds] 12:32 -!- b_101 [~robert@static-198-54-129-102.cust.tzulo.com] has joined #lightning-dev 12:32 -!- b_101_ [~robert@189.236.37.53] has quit [Read error: Connection reset by peer] 12:37 -!- b_101 [~robert@static-198-54-129-102.cust.tzulo.com] has quit [Ping timeout: 250 seconds] 12:37 -!- b_101 [~robert@189.236.37.53] has joined #lightning-dev 13:34 -!- b_101_ [~robert@static-198-54-129-102.cust.tzulo.com] has joined #lightning-dev 13:36 -!- b_101 [~robert@189.236.37.53] has quit [Ping timeout: 260 seconds] 13:46 -!- b_101 [~robert@static-198-54-129-102.cust.tzulo.com] has joined #lightning-dev 13:48 -!- b_101_ [~robert@static-198-54-129-102.cust.tzulo.com] has quit [Ping timeout: 258 seconds] 14:30 -!- b_101_ [~robert@189.236.37.53] has joined #lightning-dev 14:30 -!- b_101 [~robert@static-198-54-129-102.cust.tzulo.com] has quit [Ping timeout: 244 seconds] 14:41 -!- flooded [flooded@gateway/vpn/protonvpn/flood/x-43489060] has joined #lightning-dev 14:44 -!- test_ [flooded@gateway/vpn/protonvpn/flood/x-43489060] has quit [Ping timeout: 258 seconds] 15:27 -!- b_101 [~robert@static-198-54-129-102.cust.tzulo.com] has joined #lightning-dev 15:30 -!- b_101_ [~robert@189.236.37.53] has quit [Ping timeout: 250 seconds] 15:30 -!- bitdex [~bitdex@gateway/tor-sasl/bitdex] has joined #lightning-dev 16:11 -!- bitdex [~bitdex@gateway/tor-sasl/bitdex] has quit [Ping timeout: 240 seconds] 16:13 -!- bitdex [~bitdex@gateway/tor-sasl/bitdex] has joined #lightning-dev 17:00 -!- Netsplit *.net <-> *.split quits: faceface, _aj_, valwal 17:00 -!- _aj_ [aj@azure.erisian.com.au] has joined #lightning-dev 17:00 -!- faceface [~faceface@static.191.119.201.195.clients.your-server.de] has joined #lightning-dev 17:00 -!- faceface [~faceface@static.191.119.201.195.clients.your-server.de] has quit [Changing host] 17:00 -!- faceface [~faceface@user/faceface] has joined #lightning-dev 17:00 -!- _aj_ [aj@azure.erisian.com.au] has quit [Changing host] 17:00 -!- _aj_ [aj@user/aj/x-5857768] has joined #lightning-dev 17:00 -!- Netsplit over, joins: valwal 17:10 -!- jarthur [~jarthur@user/jarthur] has quit [Quit: jarthur] 17:12 -!- test_ [flooded@gateway/vpn/protonvpn/flood/x-43489060] has joined #lightning-dev 17:15 -!- flooded [flooded@gateway/vpn/protonvpn/flood/x-43489060] has quit [Ping timeout: 246 seconds] 19:10 -!- riclas [~riclas@26.27.71.148.rev.vodafone.pt] has quit [Ping timeout: 260 seconds] 20:59 -!- flooded [flooded@gateway/vpn/protonvpn/flood/x-43489060] has joined #lightning-dev 21:03 -!- test_ [flooded@gateway/vpn/protonvpn/flood/x-43489060] has quit [Ping timeout: 246 seconds] --- Log closed Wed Jul 26 00:00:10 2023