On Mon, Apr 11, 2016 at 04:09:05PM +1000, Andrew McGlashan via luv-main wrote:
Okay, I've got to ask.
What exactly does gpg2 offer that makes it more suitable than gpg for most usage?
It depends on whether you mean GPG 2.0.x or 2.1.x. I skipped 2.0 because it was too annoying, but 2.1 is what I'm using these days. I still keep 1.4 around for those ancient relics who insist on using either old style keys (the kind Kleopatra made by default until last year when certain people got smacked upside the head for not making encryption subkeys by default) 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).
There should be a /feature/ comparison, where is it?
In the Changelogs. Anyway, short version is that 2.1 has finally dropped support for the old PGP 2.x era keys (those 1K RSA ones from the mid-90s that no one should be using anyway). OTOH it has greater support for EC keys including, well, this: gpg (GnuPG) 2.1.11 libgcrypt 1.6.5 Supported algorithms: Pubkey: RSA, ELG, DSA, ECDH, ECDSA, EDDSA Cipher: IDEA, 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH, CAMELLIA128, CAMELLIA192, CAMELLIA256 Hash: SHA1, RIPEMD160, SHA256, SHA384, SHA512, SHA224 Compression: Uncompressed, ZIP, ZLIB, BZIP2 Compression will probably be dropped altogether in a later version, people are far better off just tying the thing to available common algorithms which provide more efficient compression like xz anyway. Though there's a fair argument for moving the compression out of GPG itself, but still integrating it with GPGME so that it can remain functionally present without tying up the essential functions of GPG. The whole suite, however, is more than just an OpenPGP implementation. For example by default GPGME includes support for GnuTLS (i.e. how to connect to all those keyservers securely), GPG, an S/MIME implementation, dirmngr (which now supports proxying through tor directly instead of having to pipe everything through proxychains or something like it). There's also been an update to the pubring format; it now uses the keybox format (.kbx) which facilitates faster searches for keys, whereas the original format was basically just a flat file and thus suffered when selecting keys from larger keyrings. The work to add encryption curves is what Werner is working on right now, but there will be greater additions later this year (after the revision of RFC 4880 is complete in around July).
gpg 1.x is still maintained, it works and the vast majority of users /seem/ to use it and only it.
That's changing, mainly due to curves anf the fact that the version of gpg-agent with 2.0 was awful. I consider 2.0 a stepping stone to better things that are being implemented in 2.1. That said I do still keep 1.4 around in case I need backwards compatibility with something.
I compiled gpg2 to make a 16384 length key... but that turned out to be completely painful, if not, almost impossible to use. Besides RSA keys are the past, but maybe not so if so many people are only using gpg (v1.x)
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. Regards, Ben