Ultimately it's about uplink. If you download much more than you upload, your anonymity suffers significantly, and you are a drain on the network, so we will add an optional feature to ensure that your node doesn't stick out this way. Cautious users won't turn it off.
So, lets assume a continuous, 1Mbps stream of SSKs. Each is just over 1kB. That's around 128 per second. That would saturate the CPU of a typical node, and can be generated at 1/3rd the cost. The keys would propagate to downstream nodes and slow them down too, however on a darknet the impact on downstream nodes would be low unless they were very close together key-wise (very difficult to do), or the attacker had many entry points. Moreover he cannot recycle keys on a given node. So it's not a particularly good attack... We may have to add some means to detect it, however: - Common uplink of much more than 1Mbps is very unlikely in the next few years for reasons relating to *DSL technology. - A 64-bit CPU should in theory do significantly more than 100 verifies per second. Unfortunately we do not yet have working BigInteger acceleration on x86-64 (either by using libgmp via JNI, as we do on 32-bit x86, or via running freenet on Kaffe/GCJ, which will use gmp if available). Lets call it 150/sec. - A dual-core CPU will certainly do very nearly twice the number per second. Lets call it 300/sec. This is more than enough to handle a 2Mbps DoS attempt. - Typically there will be other nodes trying to communicate with our node; all the bandwidth will not be occupied by a single node. The sort of amount of bandwidth needed to perform this attack could more easily be used for a more traditional bandwidth DoS. I therefore propose we use 2048-bit keys for SSKs. On Thu, Jan 05, 2006 at 05:27:21PM +0000, Matthew Toseland wrote: > In 0.7, we have to create new DSA groups, because the message hash is > 256 bits instead of 160. We have code to generate DSA groups > (freenet/crypt/DSAGroupGenerator) of a configurable key and hash size > (subject to the simplification that key size is a multiple of hash > size). > > We now have the security/performance tradeoff of what key size to > actually use. > > Here goes (on my Athlon XP 2800+, a mid-range computer by Freenet > standards): > Keysize/bits Sign/ms Verify/ms Verifies/sec Signs/sec > 1024 1.1848 3.4894 286 844 > 1536 1.9513 5.8842 169 512 > 2048 3.0466 9.531 104 328 > > Which is appropriate? Some issues: > - It is possible to transmit a new-style SSK in just over 1kB. This is > partly so that we can do streaming over SSKs more conveniently. > - Many nodes will have 128kB+/sec of downlink, and some will have that > sort of uplink. However, a node downloading much more than you upload > is strongly discouraged as it blows your anonymity. > - An attacker who sends a stream of garbage data can do a CPU DoS, > however he will be quickly detected as it will not verify. This should > result in closing the connection and telling the user of the attack. > - However, because signatures are significantly faster than verifies, an > attacker could generate a series of *valid* SSKs, and fire them at the > node. If he could grab a big enough piece of the node's bandwidth he > might be able to do a CPU DoS. Worse, these would be forwarded across > the network, since they are valid SSKs. > - When reading SSKs from the datastore, we only need to check the > datastore hash, not verify the signature. Therefore, if an attacker > repeats blocks, we do not need to reverify them. -- Matthew J Toseland - toad at amphibian.dyndns.org Freenet Project Official Codemonkey - http://freenetproject.org/ ICTHUS - Nothing is impossible. Our Boss says so. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: <https://emu.freenetproject.org/pipermail/devl/attachments/20060105/c1c32fd5/attachment.pgp>
