On Friday 07 March 2008 14:13, Matthew Toseland wrote: > One of the problems alluded to in the other mail was that SSK inserts and > successful SSK requests are traceable to a global traffic analyst capable of > detecting freenet traffic and packet sizes. Specifically, this is true > because of the huge size of the messages. Which also exacerbates MTU > problems. Details: > SSK insert reques: 1274 bytes > SSK data found: 1168 bytes > > Even with padding, these become extremely obvious, unless there is a vast > amount of small messages coalesced with them and concealing them. Which is > not normally the case, and IMHO is not a reliable cloak even on high traffic > nodes. > > So our profile currently looks like this: > > 64+64: 37 (lots of stuff) > 128+64: 101 (CHK request, SSK request, swap reply, most opennet stuff, data > insert, offers, get offered CHK, CHK insert request[, SSKInsertRequestNew]) > 192+64: 165 (get offered SSK[, SSKDataFoundNew, SSKInsertRequestHeaders]) > 256+64: 197 (swap commit/complete) > 320+64: 229 (nothing) > 1088+64: 1061 (bulk transmit, block transmit, time deltas, SSK pubkey[, > SSKData, SSKDataInsert]) > 1152+64: 1125 (nothing) > 1216+64: 1189 (SSK data found) > 1280+64: 1253 (nothing) > 1344+64: 1317 (SSK insert request) > > Formatting: > <payload size including overhead of 27 bytes>+<average random padding and hash > size>: <size of message> (messages). Note that the [] above refer to my > proposed new messages. Also the above demonstrates why I am unwilling to use > multiples of 32 instead of 64 for padding. > > We are therefore reasonably safe from packet size analysis ... except for SSK > data found and SSK insert, which are *easily* identifiable. And the latter's > size is a problem. > > I propose to split up SSKInsertRequest and SSKDataFound as follows: > > SSKDataFoundNew: UID(8) + headers(136) = 144 > SSKData: UID(8) + data (1024) = 1032 > SSKInsertRequestNew: UID (8) + key (66) + htl (2) = 76 > SSKInsertRequestHeaders: UID (8) + headers (136) = 144 > SSKDataInsert: UID (8) + data (1024) > > So: > > For an SSK insert, we have a 76 byte insert request (could be a lot of > things), which is then Accepted (8 bytes, again could be almost anything, but > requests are accepted too). Then we send the data and the headers (144 and > 1032). > > Right now, only certain messages are subject to congestion control and > bandwidth limiting: bulk transmit packets and block transmit packets. We > could send SSKData/SSKDataInsert as throttled packets (we might need to > increase the timeout to compensate for this). If we do, the 1032 byte packet > and the 144 byte packet will not usually be combined, so the former will not > be distinguishable from a bulk/block transfer (if one is going on), and the > latter could be a get-offered-SSK, or an offer-SSK combined with one or more > other messages if we're lucky. Thus hopefully as soon as the attacker reaches > a busy node he will lose the trail. > > We could further improve things by making 1088 the biggest packet payload we > send. This would prevent the 1032 and 144 being combined into a signature > 1176 byte packet when there is low traffic. It would cost a small amount of > efficiency on links with high MTUs, but it would prevent major problems on > links with low MTUs. > > So: > 5 new messages. > 2 of which go through PeerNode.sendThrottled(). > Some rewriting of the SSK requestors/insertors code. Which can be tested using > freenet/node/simulator/. > Timeouts may need tweaking, we can allocate fairly generous ones to start > with. >
Here are my notes on packet sizes. They might interest some folk here, and they should be archived somewhere other than my TODO file! Base internal overhead: 27 Hash overhead: 32 Average padding overhead: 32 Current: 64+64: 37 (lots of stuff) 128+64: 101 (CHK request, SSK request, swap reply, most opennet stuff, data insert, offers, get offered CHK, CHK insert request[, SSKInsertRequestNew]) 192+64: 165 (get offered SSK[, SSKDataFoundNew, SSKInsertRequestAltNew]) 256+64: 197 (swap commit/complete) 320+64: 229 (nothing) 1088+64: 1061 (bulk transmit, block transmit, time deltas, SSK pubkey[, SSKData, SSKDataInsert]) 1152+64: 1125 (nothing) 1216+64: 1189 (SSK data found) 1280+64: 1253 (nothing) 1344+64: 1317 (SSK insert request) That last one really sucks! Multiples of 32: 32+48: 5 (nothing) 64+48: 37 (lots) 96+48: 69 (CHK request, CHK insert, opennet announcement, CHK offer, swap reply) 128+48: 101 (SSK request, get offered CHK, offer SSK[, SSKInsertRequestNew) 160+48: 133 (get offered SSK) 192+48: 165 ([SSKDataFoundNew, SSKInsertRequestAltNew) 224+48: 197 (swap commit/complete) 256+48: 229 (nothing) 1056+48: 1029 (nothing) 1088+48: 1061 (bulk transmit, block transmit, time deltas, SSK pubkey[, SSKData, SSKDataInsert]) Computation: (size + acks etc (one byte each) + 2 per message + 27) -> round up to next 64, add random 0...63 bytes. Then add the 32 bytes hash. So... lots is shorter than 14, for example. 14 + 2 + 27 -> 43 -> 64 -> 96 -> 128 64-29 = 35. Anything up to 35 fits in a minimal packet (128). For a CHK request, a data insert, an announcement, a CHK found, we have 50 (44 if we drop the 8 in the CHK request for nearest-so-far) 50 + 2 + 27 -> 79 -> 128 -> 160 -> 192 Anything up to 99 fits in a normal packet. Including a request, a lot of acks, etc. Size 3: 192 -> 160. 192-59 = bulk transmit: 1036 block transmit: 1024+8+4+4+4=1044 CHK request: 50* SSK request: 83* Rejected Overload: 9 Accepted: 8 Data Not Found: 8 Recently Failed: 12 CHK found: 44 Route Not Found: 10 Insert request: 52 Insert reply: 8 Data insert: 44 (only used for CHKs) Transfers completed: 9 Insert rejected timeout: 8 DataInsert rejected: 10 SSK insert request: 1024+32+136+8+64+2+8=1274 (ouch!) SSK data found: 8+136+1024=1168 SSK accepted: 9 SSK pubkey: 1032 SSK pubkey accepted: 8 Opennet completed ack: 8 Opennet connect destination: 24 Opennet connect reply: 24 Opennet announcement: 42 Opennet announce reply: 24 Announce completed: 8 Opennet disabled: 8 Opennet noderef rejected: 12 Opennet node not wanted: 8 Offer key: 32(auth)+34 or 32(auth)+66 = 66 or 98 Get offered key: 9+32+34 or 9+32+66 = 75 or 107 Get offered key invalid: 10 Swap request: 14 Swap rejected: 8 Swap reply: 44 Swap commit: 24+#peers*8 (so typically 188) Swap complete: 24+#peers*8 (so typically 188) Location change: 8 Detected IP: 11 (IPv4, no hostname) or 23 (IPv6, no hostname) Time: 8 Time deltas: up to 64*8*2+8 = 1032 Void: 0 Disconnect: 8 + attached message length Suppose we split the big messages: SSKDataFoundNew: 8+136 (just the headers and the UID) SSKData: 8+1024 SSKInsertRequestNew: 8(uid)+66(key)+2(htl) SSKInsertRequestAltNew: 8(uid)+136(headers) SSKDataInsert: 8(uid)+1024(data) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: <https://emu.freenetproject.org/pipermail/devl/attachments/20080307/5d6d9510/attachment.pgp>
