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. -------------- 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/91f6da63/attachment.pgp>
