On Friday 07 March 2008 14:40, Matthew Toseland wrote: > 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) > I've changed the behaviour in 18562/18563 slightly. We now take the 32 bytes for the hash into account when padding, so we have 32+64, 96+64, 160+64, 224+64 ... (The main motivation was to reduce the max padded size to 1280 from 1312).
32+64: nothing (one or two acks) 96+64: CHK request, CHK insert, opennet announcement, CHK offer, swap reply, lots of other stuff 160+64: SSK request, get offered CHK, offer SSK[, SSKInsertRequestNew], get offered SSK 224+64: [SSKDataFoundNew, SSKInsertRequestAltNew], swap commit/complete 1120+64: bulk transmit, block transmit, time deltas, SSK pubkey[, SSKData, SSKDataInsert] -------------- 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/20080318/c2f442ba/attachment.pgp>
