[freenet-dev] SSK packet sizes quick fix

[Matthew Toseland]

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 : http://emu.freenetproject.org/pipermail/devl/attachments/20080307/91f6da63/attachment.pgp