
GnuPG 2.1.0 “modern” released - bruo
http://lists.gnupg.org/pipermail/gnupg-announce/2014q4/000358.html
======
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](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](https://gnupg.org/faq/whats-new-in-2.1.html#ecc) [2]
[https://code.google.com/p/end-to-end/](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?

~~~
cryptbe
Speed. Key generation (and most other operations) in ECC is order of magnitude
faster than in RSA, DSA or ElGamal. Last time I checked it took End-To-End's
Javascript library seconds to generate a key pair in RSA, but only
milliseconds in ECC.

~~~
tedunangst
Key gen time probably doesn't matter too much in the particular case of pgp,
but key size is a big deal. Keys that you might conceivably type by hand.
Keys, not fingerprints, that can fit in tweets. Or tattoos. :)

~~~
glass-
Do you know of anyone with a signify (or reop) key tattoo yet?

~~~
tedunangst
Heh. No, I'm not trying to encourage that, but I think it's useful as rough
measure of practical size for exchanging data. Like "Olympic swimming pools"
is a popular measure.

------
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](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?

~~~
JoshTriplett
Yes, exactly; with 2.1 out, I expect future versions to start moving towards a
usable "libgpg".

------
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](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.

~~~
tptacek
It's gcrypt, but I have no idea who has looked carefully at that code.

~~~
sarciszewski
Out of curiosity, and I apologize if this is radically off-topic, do you have
a list of "usual suspects" for auditing crypto libraries (GPG, OTR, etc.)?

(Or is the answer simply: the modern-crypto list subscribers?)

~~~
tptacek
Thai Duong, Juliano Rizzo, Kenny Patterson's team at Royal Holloway, Daniel
Bernstein, Trevor Perrin, Nate Lawson, the Riscure guys, the Cryptography
Research team at Rambus.

~~~
e12e
Are there any well funded national intelligence organizations that does this,
and still do public recommendations? In theory the NSA, MI5 etc should be
advising their various governments and businesses on how to protect secrets
(not just military, but protecting against corporate espionage, protecting
journalistic foreign sources (think: Chinese dissidents etc)). Obviously the
NSA have some very real trust issues -- but does anyone have an update on
whether or not they've actually sacrificed large parts of their mission on the
altar of total information awareness? Does Navy Intelligence still provide
support for Tor?

------
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](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...](https://code.google.com/p/end-to-
end/source/browse/javascript/crypto/e2e#e2e%2Fecc).

~~~
diafygi
I spent the weekend digging into both End-to-End and OpenPGP.js, and it
appears the End-to-End has the primitives for Ed25519, but it doesn't
recognize signature packets that use Ed25519. Is there an e2e bug tracking
compatibility with GPG 2.1 signatures that use Ed25519?

------
peterwwillis
Favorite easter egg: in [https://gnupg.org/faq/whats-new-
in-2.1.html](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](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.

~~~
otoburb
D.J. Bernstein stated that he wasn't aware of any patents that applied to
Curve25519[1]. This leads to the following statement in the GnuPG v2.1 FAQ[2]:

>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.

[1] [http://cr.yp.to/ecdh/patents.html](http://cr.yp.to/ecdh/patents.html)

[2] [https://gnupg.org/faq/whats-new-in-2.1.html](https://gnupg.org/faq/whats-
new-in-2.1.html)

------
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

~~~
Fastidious
Please, post the same for OS X (Yosemite)! I tried and it seems 'modern'
requires extra libraries not present.

------
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.

~~~
tedks
How would you lose portability by moving to a high-level language?

Further, why would timing attacks necessarily be more or less of an issue in a
higher-level language than C? This is a genuine question.

I feel like in any case, there are some things that should just not be done in
C. For example, the base64 encoder/decoder that gpg uses for ASCII-armoring
should not be written in C; in general any parser should not be written in C;
there's no reason for the code that interfaces with the user (for example,
checking a password given to gpg-agent) to be written in C. You could write
these in OCaml, use the FFI to natively link them into a single executable,
and you'd have safety for string handling while retaining fine-grained control
of the hardware during crypto.

However, I'm skeptical that you literally cannot use OCaml to implement crypto
that's secure against timing attacks. You can always fall back to C for
primitive operations, and you can control the garbage collector enough that gc
pauses wouldn't be an issue.

IMO, the most compelling reason not to do this is that for all its fatal
flaws, C is the most widely-used systems programming language, and so it has
the largest share of experts ready to review code. But this doesn't seem like
a good enough reason, given the severity of memory corruption bugs.

~~~
kazinator
The way you lose portability by moving to a high level language is that you
don't have an implementation of that high level language for as many
platforms. You're not losing abstract portability in the sense that the
semantics of the high level code is very highly machine-independent. But an
actual port requires an actual toolchain.

C is not inherently portable, and it takes a lot of know how, care, testing,
and sometimes luck, to write C that is portable.

C is de facto portable in the sense "able to be actually ported" by having the
tools --- but possibly at the cost of combing the code for nonportabilities
that have to be uprooted.

------
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.

~~~
edwintorok
The _previous_ announcement refers to beta, this is the final.

------
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

~~~
AlyssaRowan
I take your point, but honestly I don't think at this time that Curve25519 (or
_properly implemented_ RSA-3072) will fall cryptologically in any reasonable
timeframe without either a quantum computer or a _really_ fundamental
development in factoring/discrete logs that would probably threaten RSA-4096
roughly as badly.

Ed448-Goldilocks is great, and may indeed be a good contender for certificates
as it seems to represent a good inflexion point of security versus
performance.

The Crypto Forum Research Group at the IRTF is currently considering
recommendations to make to the TLS Working Group (and perhaps to be used more
widely) regarding elliptic curves: I've been a, um, vocal participant there
already. I've raised this development there, as it may spur the discussion
forward.

Goldilocks is one of the potential curves on the table there. There's
potential enthusiasm for recommending two curves: one strong, fast curve with
≈128-bit workfactor (quite likely Curve25519 in my opinion) and one super-
strength curve, at least 192-bit workfactor (possible candidates include MS
Research "NUMS" P384/P512, Curve41417, Ed448-Goldilocks, and E-521). The
option of generating entirely new Brainpool-style random curves isn't off the
table either, and some have been asking for that, but I'm _really_ not sold:
the software performance of random curves is absolutely dreadful, the
implementation can be the kind of hairball we want to avoid, those asking seem
to be asking because they're heavily committed to hardware with aged generic
(RSA-targeted) hardware multipliers with anti-side-channel blinding that is no
longer great and doesn't work right over special primes - and besides, if we
wanted Brainpool, we could just use Brainpool. (Brainpool is indeed in this
GnuPG release if you want it.)

If I was not performance-sensitive and wanted the highest level of security I
could reasonably get from curves, maybe I'd choose E-521, which has impressive
rigidity, being independently discovered and confirmed by multiple research
teams, and good performance for its class due to being a Mersenne prime. But
you do pay quite a bit of performance to go from the ≈224-bit to the ≈250-bit+
range, and it's not clear to me that's particularly meaningful in all cases.
(Of course, maybe PGP _is_ one of those cases, and performance isn't usually a
big deal there unless it's _really_ bad.)

Regarding SPHINCS, 41KB signatures are remarkable for what they are, but not
practically ideal for OpenPGP, especially with the way the keyservers are now,
but you know, I could maybe live with it. I could see it start to get ugly for
keys with a lot of verifying counter-signatures on them, however.

Do remember OpenPGP _doesn 't_ bring everything to the table: for example,
forward security. And MUAs have a reputation for _awful_ UX regarding it -
operator error is extraordinarily frequent. But it seems to at least be Pretty
Good in practice. Thanks Werner & team!

~~~
nullc
I'm kinda bummed that all the considered sexy curves are cofactor!=1, beyond
losing a bit of rho security, it makes implementations more complex and
complicates derivation schemes. (I think it also shows there is more
flexibility in supposedly rigid schemes than people give credit for; IIRC
brainpool _required_ cofactor 1, but a speedup is suggested (montgomery ladder
instead of using a slower constant time addition law) and tada, relaxed in
future curve specs. This is especially acute for PGP where performance on this
sort of scale is basically a non-issue: practically no one needs to verify
tens of thousands of PGP signatures per second.

Indeed, PGP doesn't bring everything to the table (You fail to mention non-
repudiation, but the fact that I can't authenticate a pgp message without
producing a transferable signature is a pretty big flaw for general
correspondence)... but, considering the the limitations and usability
concerns, it appears to me to be most suited and widely used for higher
security applications authenticating software distributions with long term
keys, which effectively all the rest of our computer security ends up resting
on it. Other things end up being protected by OTR, TLS .. or not at all. :( We
effectively have no general widely deployed "high security" option for long
term person to person encryption and authentication except PGP.

~~~
wbl
This is incorrect. Cofactor 1 does not have a complete addition law, nor did
original specs forbid cofactor >1 on security grounds. The Montgomery ladder
doesn't have certain kinds of weaknesses common in naive implementations of
Weierstrass form addition. Clearing the cofactor is easier. I can fit
Montgomery ladder in 10 lines, and can't do that with a secure Weierstrass
implementation.

------
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?

