On Friday 16 Nov 2012 13:01:46 Juiceman wrote: > 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.
One of the problems is higher levels of ECC-based crypto will use considerably more CPU than we do now. Our current DSA2048 is way below what is really appropriate for 256-bit crypto. > > 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 > > >
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Devl mailing list [email protected] https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
