GnuPG 2.1.0 “modern” released

[cryptbe]

Congratulations Werner and GnuPG team!

> GnuPG now support Elliptic Curve keys for public key encryption. This is defined in RFC-6637. Because there is no other mainstream OpenPGP implementation yet available which supports ECC, the use of such keys is still very limited. [1]

Google End-To-End [2] supports ECC by default. We are working on supporting Ed25519, but encrypting and signing with NIST curves should work and be compatible with GnuPG. That said, we've had a lot of compat issues, so it'll be great if Hacker News readers and GnuPG users can help test our implementation against GnuPG. You can generate keys in GnuPG and import them to End-To-End and vice versa, or you can encrypt/sign messages on one software and decrypt/verify them on the other. If you found a bug or anything that doesn't work as expected, you can report it at https://code.google.com/p/end-to-end/wiki/Issues?tm=3. If it's a security bug you're eligible for a monetary reward under our bug bounty program :-).

[1] https://gnupg.org/faq/whats-new-in-2.1.html#ecc [2] https://code.google.com/p/end-to-end/

[a3_nm]

Hopefully this is not too obvious, but what is the advantage of ECC crypto compared to what GnuPG 2.0 is using?

[JoshTriplett]

One particularly nice feature of the new version: gpg-agent no longer just stores the passphrase and hands it out to gnupg. Instead, gpg-agent actually holds the private keys and does crypto operations with them, and never lets any other process have the private keys or the passphrase (other than the pinentry program that prompts for the passphrase).

See https://gnupg.org/faq/whats-new-in-2.1.html#nosecring

[zokier]

Does that kinda imply that gpgagent would be usable as a building block for programmable access to gpg, ie next-gen gpgme?

[Florin_Andrei]

I suppose that doesn't apply to using smartcards, as the private key never leaves the card anyway.

[tptacek]

This is great news, but if you're life-or-death dependent on crypto (and PGP is one of the very few tools you might ever consider being life-or-death with), you might consider letting the modernized GnuPG (and particularly it's ECC code) percolate a bit.

[teamhappy]

Looks like you know more about this than I do. Is the crypto code new to libgcrypt or just to GnuPG? Given your statement I assume it's the former.

---

Apparently libgcrypt hasn't been updated since late August[1]. Also relevant, GnuPGP 2.1 has been in Beta for over 4 years[2].

[1]: http://directory.fsf.org/wiki/Libgcrypt [2]: ftp://ftp.gnupg.org/gcrypt/gnupg/unstable/

---

Just for the record, I agree that under severe circumstances choosing the new ECC features might do more harm than good. However, given the context that somebody else asked whether it's a good idea to wait for a 2.1.1 release, I'd say no, use 2.1 right away. Interpreting version numbers like that (especially when the crypto routines have their own module anyway) seems overly suspicious and might do more harm than good as well.

[rasengan]

Don't use PGP if in a life or death situation. Once someone steals the key you're going to be really screwed because all the emails you thought were so private are suddenly not private at all.

[diafygi]

> For many people the NIST and also the Brainpool curves have an doubtful origin and thus the plan for GnuPG is to use Bernstein’s Curve 25519 as default. GnuPG 2.1.0 already comes with support for signing keys using the Ed25519 variant of this curve.

That's great to hear, but it seems like this represents a split from the OpenPGP standard, which requires NIST curves[1]. Will other OpenPGP implementations (e.g. OpenPGP.js), start to have to offer extensions to be compatible with GPG?

[1] - http://tools.ietf.org/html/rfc6637#section-4

[cryptbe]

Great question. The core crypto library in End-To-End has already supported ECDH on Curve25519 and Ed25519 since day one [1]. We're discussing with GnuPG team on extending RFC 6637 to include these algorithms in the OpenPGP standard.

[1] https://code.google.com/p/end-to-end/source/browse/javascrip....

[peterwwillis]

Favorite easter egg: in https://gnupg.org/faq/whats-new-in-2.1.html the examples showing how modern gpg works includes the identities 'Glenn Greenwald', 'Laura Poitras', 'Daniel Ellsberg', and 'Edward Snowden'.

[Osaka]

It's all well and good adding support for new algorithms, and streamlining the UI. But still, access to the key servers are done over plaintext[1]. Which could allow an attacker to modify your request/response from the keyservers.

Am I correct in believing that this is a critical issue not to address?

[1] "Support for keyserver access over TLS is currently not available but will be added with one of the next point releases. " -- https://gnupg.org/faq/whats-new-in-2.1.html

[onlydnaq]

I don't believe that this is a critical issue. The PGP-trust model doesn't need you to trust neither the keyserver nor the connection to the keyserver. You are supposed to look at the actual key, and the actual signatures of the key to decide if you trust it.

Anyone can usually upload any key to the keyserver, so even if you use TLS that wouldn't make a difference from a security perspective.

[carlchenet]

  - Commands to create and sign keys from the command line without any
    extra prompts are now available.

=> thanks god, at last

[Torgo]

This should allow interoperability with Google's Chrome End-to-End GMail PGP extension. I hope this ends up in package managers quick.

[exabrial]

ECC support?? FINALLY

[hughes]

What happened to the patent issues around ECC? I thought Blackberry/Certicom were holding that tech pretty close.

[zmanian]

Anyone have any guidance on building this on Ubuntu Trusty?

[dfc]

    # wget http://GPG/source/gpg-blah-tar.gz
    # wget http://GPG/source/gpg-blah-tar.gz.asc
    # gpg gpg-blah-tar.gz.asc
    # apt-get build-dep gnupg2
    # apt-get install devscripts ubuntu-dev-tools
    # apt-get source gnupg2
    # cd <The gnupg2 version directory something like gnupg2-2.0.26 >
    # uupdate ../gnupg-2.1.0-blah-tar.gz
    # cd <the directory uupdate tells you to cd into>
    # dpkg-buildpackage -uc -us -nc 
    # dpkg -i ../gnupg2*.deb

[zmanian]

Here is the build process that worked for me

sudo apt-get install pinentry-curses

add pinentry-program /usr/bin/pinentry-curses to ~/.gnupg/gpg-agent.conf

#cd

#wget ftp://ftp.gnupg.org/gcrypt/gnupg/gnupg-2.1.0.tar.bz2

#wget ftp://ftp.gnupg.org/gcrypt/gnupg/gnupg-2.1.0.tar.bz2.sig

#gpg --verify gnupg-2.1.0.tar.bz2

#tar -xvf gnupg-2.1.0.tar.bz2

#cd gnupg-2.1.0

#make -f build-aux/speedo.mk native

#export LD_LIBRARY_PATH="/home/[user]/gnupg-2.1.0/PLAY/inst/lib"

#cd PLAY/inst/bin

#./gpg2

[na85]

It will end up in your package manager eventually.

[maxtaco]

Great news and congrats to the GnuPG team. A practical near-term consideration: there are plenty of installs of GPG v1 still in the wild --- people who never even upgraded to 2.0. It might not be a good idea to rush to ECC keys if you want to interoperate with these legacy installs. But for the long term, this is a great development.

[Tepix]

What's a good, cheap smartcard to use with GPG 2.1? Ideally it should support ECC as well as RSA (4096 bits).

[beagle3]

Second that question. In fact, I'd be happy for a not-so-cheap one (up to $100). Do ECC smartcards compatible with GPG2.1 exist?

[zvrba]

Another large codebase in C that deals with security. How thoroughly has it been audited and tested for bugs? Should we soon expect a new "Heartbleed"? Why or why not?

[orik]

If you wrote it in a language you consider "more secure" you'll open yourself to timing attacks and loose portability.

[zvrba]

Could all the downvoters explain why this isn't or shouldn't be a genuine concern? I know that GnuPG is not a network server, but there's a still lot of potential for various exploits in format parsers, etc.

[mkesper]

When rust becomes stable, this probably would be a good candidate.

[gcv]

Seeing as this is crypto software, is it a good idea to wait for a 2.1.1 bugfix release?

[Florin_Andrei]

Well, this announcement refers to a beta version. Draw your own conclusions.

[jangid]

With each new release I feel kind of nostalgic. I have been using this since year 2001.

[sarciszewski]

Excellent news! Ed25519 signatures ftw :D

[nullc]

Pfft. Not Ed448-Goldilocks? I'd rather not use a long term identity key with less security than the 4096-bit RSA that people are already widely using for long term keys.

Or really, wheres the SPHINCS+Ed25519 option for pgp master keys? :P

[Tomte]

GnuPG scares me. In all kinds of ways.

And Werner Koch must be some kind of demi-god.

[hatsuseno]

I'm curious, why does GnuPG scare you?

[kopparam]

I feel quite the opposite Tomte, a world without GPG would mean that the bad guys who want to invade innocents' privacy have an all access pass to our inbox. That world would be horrific.