I tend to think seednodes are more likely bound by bandwidth constraints than CPU, at least the one I run. However I agree that the packet size going over the MTU is a dealbreaker.
Sent from my wireless phone. On Nov 16, 2012 7:04 AM, "Matthew Toseland" <[email protected]> wrote: > Nextgens is making some largish changes to connection setup and link > encryption, to improve security and performance. > > Nextgens wants to use 128-bit AES for link encryption, on the theory that: > 1) On opennet, even with the optimisations we have proposed, there are > much easier attacks than breaking AES128. > 2) Even on darknet that's still probably true. > 3) Using AES256 properly would require using secp521r1 (or at least > secp384r1) for connection setup (currently we use 2048-bit DSA, we are > about to switch to using ECDSA with secp256r1; see keylength.com). > 4) secp521r1 is 10x slower than secp256r1. So on opennet seednodes, CPU > usage for handshaking would be a problem. We can maybe reduce this a bit by > using a lot more seednodes. Also, we can reduce CPU usage for ECDH > dramatically by using NSS, although it's ugly due to bugs that haven't been > fixed in years; arguably we shouldn't be using code that is effectively > unmaintained, but the other side of the argument is it's just Sun's glacial > release cycle (bugs in the Java side of NSS are mostly fixed in Java 1.7). > 5) For opennet initial connection setup with a seednode, packets would > have to increase in size by about 415 bytes. This might well push them over > the MTU; the "anonymous initiator" packets are already rather large. > Reassembling connection setup packets ourselves is a bad idea, and sending > packets over the MTU is dangerous - that is, they get dropped across most > of the internet. > 6) We could support 128-bit crypto for opennet and 256-bit crypto for > darknet (possibly configurable by the user, although I doubt 256-bit is > possible on opennet due to packet size issues). This would solve most of > these problems, but would involve more code complexity. Nextgens is opposed > to it for this reason. > > Currently we use Rijndael with 256-bit key and 256-bit block size (and > 2048-bit DSA). AES is Rijndael with 128-bit block size; we should use the > standard, but that doesn't settle what key length to use. Using ECDSA is > necessary because a bigger DSA would make for very large packets, and in > any case ECC is preferable for both security and performance. > > _______________________________________________ > Devl mailing list > [email protected] > https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl >
_______________________________________________ Devl mailing list [email protected] https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
