On Tue, Apr 12, 2016 at 11:41:02AM +1000, Trent W. Buck via luv-main wrote: > Ben McGinnes via luv-main writes: > > > [...] I still keep 1.4 around for [...] or making 16K keys (they're a > > waste of time and effort, if you must be that paranoid then 8K is > > still fine and 4K for comms ... well, it was good enough for Ed > > Snowden). > > [...] > > Large key support from 2.1 will basically stop at 8K, if you really > > want to make a 16K key then the easiest way is to modify the source > > for 1.4. You'll need to raise the key size maximums and increase the > > secmem. I'll leave the rest as an exercise to those who should know > > better, but otherwise think they know what they're doing. > > When someone says "I need 16K RSA keys", > don't they really mean "I want EC keys"?
Pretty much, certainly for any kind of effective use. > Because, like, RSA needs to be a lot longer than EC to provide the same > security level. It's a bit rough, but 256-bit symmetric encryption from something like Twofish, Camellia or Serpent is about equivalent to an EC key twice the size (maybe a little less) and an RSA or El-Gamal key of about 15K (but everyone rounds up to 16K). Rijndael (aka AES) is slightly weaker than the other three but a lot faster (which is why it won the AES competition and it still hasn't been broken so seems "good enough" for most people ... at least when they're not using something that shares primes [insert pointed look at SSL here]). It's also been subjected to more efforts to try to break it. The definitions for SECRET level in Australia and the USA stipulate 192-bit symmetric encryption or its equivalent at 3072-bit asymmetric. So that's usually set to 192-bit AES and 3072-bit RSA. The TOP SECRET specifications are 256-bit symmetric and an unspecified asymmetric equivalent. > Obviously there's problems with that in practice (for GPG) because you > need to interact with people still running gpg1 --- cf. EC in OpenSSH. True, but then there are people who go to the extra effort of creating 8K or even 16K keys, but still default back to Triple-DES or even CAST5 for the symmetric component of their messages. These same people then point to the NSA hoovering up everything they can to crack it one day, FFS! How many times do we have to say it? Triple-DES was *designed* by the NSA and its original theoretical security level of 168-bit has already been *publicly* knocked down to 112-bit or less. As far as I'm concerned if you can't be bothered editing your algorithm preference order in gpg.conf and editing your keys and subkeys (actually they're set according to each UID) to match then you have no business trying to make keys larger than the default maximums. That said, I still encourage everyone to make 4K keys by default for at least the cert key and the encryption subkey, signing subkeys are fine at 2K (mine is 3K with 4K for the other two). I know I haven't posted to luv-main in a while and I know everyone else posting to this thread probably already knows my GPG bona fides are, erm, pretty good these days, but I'm also fairly sure there's more than a few lurkers right now asking "who the fsck is this guy and why should I care?" Er ... short version: if you attended any of the original CryptoParties in Melbourne in 2012/2013 I was the one teaching GPG, I ported PyME (GPGME Python bindings) from Python 2 to Python 3 and they're currently in my branch(es) on git.gnupg.org (yeah, that means I'm the only Australian on the GPG dev team ... actually the only member of the team in the southern hemisphere). Regards, Ben P.S. Don't worry about DECO and ITAR, I've already made sure it's all cleared and there are no problems. I even added my ITAR questionaire results to the git server in a branch for a newer part of GPGME and Python dev, so it's on the record. ;)
signature.asc
Description: PGP signature
_______________________________________________ luv-main mailing list [email protected] https://lists.luv.asn.au/cgi-bin/mailman/listinfo/luv-main
