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.
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Devl mailing list [email protected] https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
