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
signature.asc
Description: PGP signature
_______________________________________________ luv-main mailing list [email protected] https://lists.luv.asn.au/cgi-bin/mailman/listinfo/luv-main
