Currently we use 256-bit AES (more or less) to encrypt packets, and 2048-bit DSA and secp256r1 for Diffie-Hellman/STS/JFK for creating those keys. This is of course ridiculous, as you can see below, and is also slow and oversized. We need to decide on what keys we want to use before we implement the next stage of crypto changes. http://www.keylength.com/en/3/
I propose that we use: - 128-bit AES for packet encryption. - secp256k1 for DSA (signing the connection setup, to prove that the node is not being spoofed) - secp256k1 for Diffie-Hellman (generating the private key) Advantages: - We can use JCA for packet crypto (once we switch to 128-bit block size): 128-bit AES is exportable. Of course the paranoid would say the reason it's exportable is the NSA can crack it. But it's gonna be a long time before we have any hope against them - and it's pretty much certain that nobody else can crack it. Anyway, this makes the code easier / cleaner / more standard. - 128-bit AES uses about 40% less CPU than 256-bit AES. - The above is consistent, it's listed as "Long-term protection" on the standard linked above. - secp256k1 should be just as secure as secp256r1, but it's much faster. Note that Bitcoin uses secp256k1 to protect sometimes large amounts of money. - Diffie-Hellman (ECDH) doesn't need very strong security. We rekey every hour, so cracking an exchange will only allow you to decrypt one hour's worth of data. - Signing the connection setup doesn't need very strong security either. Ideally we'd like to be able to change the key, say once a year. But again, borrowing a supercomputer to impersonate one node isn't very realistic, even on darknet, or on a seednode; it'd be easier just to add a bunch of evil seednodes, although some schemes to secure opennet might be interesting. - I don't think it's worthwhile to go for an even smaller key size, simply because secp256k1 is likely to be fast enough. Obviously this is more than sufficient for opennet, given our higher level attacks. IMHO it is probably sufficient for darknet too. Having said that, on darknet, cracking a node's identity gives you a lot more than it does on opennet. Also in future we will have an option to do tunneling on darknet, and the tunnels will only be as strong as the nodes' darknet identities - even if we had a stronger key for encrypting the tunnel, stealing the node's connection setup identity would probably let you steal it, but the above is probably still strong enough. The second question is what to use for SSK keypairs? Some keys are more important than others. E.g. the auto-update key. However it is possible to change them - in particular the auto-update key has been changed several times, it's a hassle but it's possible. It will need to be changed again when we move to ECC-based SSKs. Our options are: - Use secp256k1 for everything. Probably ideal. - Allow smaller keys if wanted, or even force them for small blocks. - Allow larger keys. The problem with allowing larger keys is that above 256-bit ECC (128-bit effective), there are no -k curves, they are all purely random. Meaning they are much much slower. So if we were to be really paranoid and support secp384r1 or even secp521r1, verifying the SSK on each hop might cause significant CPU usage. So I'm inclined to just go for secp256k1 for everything... Another possibility: There is actually another set of standard curves, sect*. These use a different kind of arithmetic (binary fields rather than prime fields). Do we want to look at these? Are they less safe than prime fields? The relevant bug is here: https://bugs.freenetproject.org/view.php?id=5690
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Devl mailing list [email protected] https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
