Once-starving GnuPG crypto project gets a windfall. Now comes the hard part
arstechnica.com
arstechnica.com
However the heck they want to spend it. These are donations. If the guy has been working so hard just to make the world a better place and he wants to disappear with the money, I'd be bummed and I imagine lots of other people would too, but they were donations. A "thank you for busting your back for so long", not a "hey, now you've made it to the big leagues, better saddle up (the way I want you to, by the way)."
We've been using this software (probably worth many millions a year in the private sector) for free for how long? At least for libgcrypt, the initial commit was November 8, 1997. 17+ years ago.
That said, what are the chances this awesome, passionate developer is going to deliberately drop this project he's poured blood, sweat, and probably some tears into? What are the chances that he doesn't labor over the decision on how to spend the money, and consult his peers?
I sincerely hope this doesn't turn into some donation-gate fiasco where everybody's miffed about how the money that was freely donated got spent. This guy has changed the world and deserves to take the money as thanks and not added responsibility. He's already been shouldering that responsibility for years.
More to the point, how do you figure that GPG is on the "critical path" of 50% of Google's business?
> More to the point, how do you figure that GPG is on the
> "critical path" of 50% of Google's business?
Reading that reminded me of some comments[1] made by the author of ObjectivePGP, a very recent effort to create an OpenPGP compatible Objective-C library:
> Today I regret that I have not made any notes during programming, so that I could now quote all my moments or doubt, all WTF? instances (I think that some of them are still present in source comments). Many sudden turns of events, lots of dead ends and a massive amount of uncertainty await for the person implementing this protocol. Now I understand why OpenPGP does not have many implementations — the protocol itself is simply quite difficult to implement.
and
> Now, with all I have learned during the time I spent working on it, I would have written the library in an entirely different way. ... I have even made a note in my TODO “Need to rewrite the whole thing!”. This is true, but if I keep on rewriting it all the time, I will not finish anything else.
[1] http://blog.krzyzanowskim.com/2014/07/31/short-story-about-o...
Add in some personal preferences and you can easily find someone calling "good code" crap
I fear he'll anyway just hire some help for himself to work on this stuff...
This guy has sacrificed a lot and built something that is pretty critical to people all over the world. As a pretty casual, I recall directing direct answers from the author in hours from the author. If the code is mess, at least it has been implemented in such a way that the mess is harder to exploit.
The two most recent upsets were GPG deliberately breaking a whole bunch of compatability, meaning newer versions will not decrypt older files. For people who use GPG for e.g. securing transferred documents that might be called in court, it's pretty upsetting, to put it mildly, that the maintainer has told us we're on our own if we want to be able to access old files[1]. Since this is one of the core uses for GPG it's generated a lot of angst.
The more obnoxious one for me is going out of his way to break a whole bunch of GPG integration, complete with acerbic error messages for people who had been relying on it. Making encryption harder to use will not improve security.
[1] Sure, you can keep old sources around and hope GPG 1.x will still build 10 years from now, but that's a bit of a gamble.
Edit: see quoted text above.
Anyway, if the spec is foobared and leads to ugly implementations, surely breaking compatability is the only sane choice? If you have legal compliace isdues, pay the 100000 euros required to forward-port what you need - or re-enceypt your data?
On a side note: do you need to use signatures in your legal compliance? It would be interesting if there are legal frameworks based on/depending on PGP/GPG.
In the case of data encrypted 20 years ago with legacy era PGP, it has done its job, and now it is time to destroy or migrate the data to crypto with an appropriate lifespan.
See: http://www.keylength.com/en/compare/ for key guidance
Some algorithms and parts of the protocols as used by the 20 years old PGP-2 software are meanwhile considered unsafe. In particular the baked in use of the MD5 hash algorithm limits the security of PGP-2 keys to non-acceptable rate. Technically those PGP-2 keys are called version 3 keys (v3) and are easily identified by a shorter fingerprint which is commonly presented as 16 separate double hex digits.
With GnuPG 2.1 all support for those keys has gone. If they are in an existing keyring they will eventually be removed. If GnuPG encounters such a key on import it will not be imported due to the not anymore implemented v3 key format. Removing the v3 key support also reduces complexity of the code and is thus better than to keep on handling them with a specific error message.
There is one use case where PGP-2 keys may still be required: For existing encrypted data. We suggest to keep a version of GnuPG 1.4 around which still has support for these keys (it might be required to use the --allow-weak-digest-algos option). A better solution is to re-encrypt the data using a modern key.
https://gnupg.org/faq/whats-new-in-2.1.html
This only affects data encrypted by PGP-2, the original Phil Zimmerman PGP. If you are on GPG 1.4 or 2.0 and want to switch over to 2.1 this shouldn't be a problem.
GPG even doesn't inform the users in the runtime that it silently removes user's "old format" keys from the set of keys they had. They just "dissaper."
The people who use the PGP the longest are the ones most inconvenienced. The old data, supposed to be backups, can't be read by the new version.
Sounds like the age old, More Taste! Less Filling! Backward compatibility for insecure algorithms is exactly the code which should be jettisoned. We have VMs which run Amiga and DOS, if you're terrified of not being able to decrypt then grab a cup of coffee and get to re-encrypting with a key that doesn't inline MD5!
You did get the part where this is free software, and you are free to fork it if you wish?
I tend to think it's the users responsibility, by choosing to use the package, to actually understand how it works. The maintainer owes you nothing. It's stated right there in the license.
P.S. The scare quotes do not help your argument. The old keys are technically weak. That happens with crypto from time to time. If you can't plan for that, might as well keep it cleartext.
Keep that around for a year or two, then drop support fully.
Actually, if you are writing archiving software, yeah. Especially for official or legal records.
If you have legal compliance issues like that, surely you have enough money to pay someone to maintain a tool (even a GPG derivative!) that promises never to break backwards-compatibility?
It seems like people are angry that something that was maintained for free is no longer being maintained for free. Given that they have never lifted a finger to help out (either financially or by providing code), that seems a bit petty.
If it's from Goodin, you should always take it with a teaspoon of salt. He is often in way over his head with certain subjects he decides to write about, best example being BADBIOS, the story about a hearsay BIOS uber-virus. Made everybody shit their pants for days (even the MSM picked it up) and after weeks of waiting, the swarm of curious FW/BIOS analysts that were demanding dumps from Goodins source finally declared the story BS.
That aside, the following paragraph alone says a lot about Goodin's ham-handed journalism:
Still, it's not clear whether it makes sense to dump massive amounts of cash to refurbish code in such disrepair.
I glimpsed over the 1.4 branch for a few minutes (I bet longer than Goodin) and while some parts look complicated, it is not remotely as ugly as for example fetchmail or certain parts of the glibc.
BADBIOS is a particularly unreasonable thing to hold over his head. Goodin is a journalist, not a security researcher. He depends on researchers as sources for his story (and in that regard, he is unusually well-sourced; possibly second only to Krebs). Security researchers were not unanimous about BADBIOS. Some of them --- Robert Graham jumps to mind --- were happy to entertain the idea that Dragos really did have a mysterious malware infection. It doesn't help that so many researchers are friends of Dragos.
Matthew Green is a radiant cut emerald of a crypto source. He's a professor of cryptography at Johns Hopkins and a former appsec consultant at Avi Rubin's old company. As far as news sources go, he's extraordinarily well-connected to crypto research; much more so than Schneier, who is reverently quoted everywhere without a peep from HN.
I think Green is being a bit unfair to GPG in this piece, and that it's reasonable to take issue with that. I don't think it's reasonable to direct that ire at Goodin.
I've worked with plenty of unprofessional reporters who butcher stuff, and don't care about the details. Dan isn't like that.
My main issue with the article was the way he presented the story as if it was based on facts instead of a few unproven claims. Subsequently, the story spread to other non-technical platforms, re-reported as fact.
> Robert Graham (...)
Well, that doesn't really matter.. extraordinary claims were made in the complete absence of extraordinary proof. And then a multi-page story was written based on nothing.
> I think Green is being a bit unfair to GPG in this piece
I agree, his comments were slightly smug.
No, it fucking doesn't raise that question. As far as I am concerned the money is already spent. And that's the way it should be, because Werner Koch has already devoted years of his life to developing this stuff.
WK has unreasonable opinions, e.g., see this thread: http://www.reddit.com/r/programming/comments/2uw2gt/the_worl...
Having tried to integrate PKCS#11 support into GnuPG (rejected with bogus and dodgy arguments, see threads documented here: http://zvrba.net/software/gpg_pkcs11.html), I can testify that the codebase is messy and complex.
Just ditch it and make something from scratch. I have more faith in the competence of NetBSD-associated people than in WK.
Maybe this is because it was being maintained by a single underfunded developer. I'm not sure how the fact that we're now funding that programmer enough that he can hire a second developer (as was his stated intent) that this brings up questions of whether the money is well spent.
Ars Technica? More like Talking-out-their-arse Technica. Non-technical people writing about code critiques they can only understand second-hand is pretty much worthless.
The plus side is that GnuPG by design has a relatively limited attack surface. It's tough to conduct a side-channel attack that requires thousands of message stimulus-response tests to get a single key or message bit, given that each iteration of that attack will (in typical GPG usage) require manual intervention.
As long as your crypto isn't "online", GPG is still a pretty safe bet. You can't say the same thing about a lot of newer crypto libraries.
However, if you're doing something like encrypting a session cookie, you should use Nacl, not GPG.
That's how I understood it anyway!
How long do you think that will last when everyone encrypts all their email?
It's very tempting, especially for smart, multilingual, incredibly talented individuals to just roll this as if the libraries below you don't matter. Crypto is, unfortunately, the leakiest of the leaky abstractions you can end up building on. No matter what, I always have someone else (and preferably several someone elses) check my work when it comes to authentication systems and encryption.
IANAL,EIIWTWNBFLA,UHTPMTGMROOTS. tpateck is a much better person to talk to than me if you need to find someone to help you deal with these issues most subtle.
Here's what they've found lately:
CVE-2014-4617 (DOS only)
CVE-2013-4576 (RSA Key Extraction via Low-Bandwidth Acoustic Cryptanalysis -- awesome, but not exactly practical)
CVE-2013-4402 (DOS only)
CVE-2013-4242 (RSA side channel attack)
CVE-2012-6085 (invalid keys could corrupt memory)
-- 5 years with not a single security hole --
CVE-2007-1263 (bug in signed message verification)
Compare this with the security history of the browser you are using to view this comment, and weep..
One article. 180keur in donations in a day.
If only one project can be in the spotlight a day, there aren't that many projects that can get a respectable amount of funding this way.
According to TFA, he's raised nearly $300K so far; rather than using that all to hire coders, it might be worth taking $100K of that, setting up a foundation, and hiring a full-time fundraising/development person. A good one should be able to bring in enough to pay for themselves and ensure a steady stream of ongoing cash, which would be much better than having to rattle the tin cup when things get dire.
https://g10code.com/about.html
It's certainly more than the developer expected or made in previous years, but all together it's not as much as it appears to be.
"A real audit of the [GnuPG] code would be great," Green said. "The problem
is it would be really expensive and I'm not sure it's worth it."
"Meanwhile, Google and Yahoo are proceeding with End-to-End, a project that aims to rewrite PGP code from scratch to make e-mail encryption easier."
That's rather limited.
[1] https://www.mailpile.is/blog/2014-10-07_Some_Thoughts_on_Gnu...
> The financial strain Koch has endured underscores a cruel irony that has only recently come to light.
No, that's like saying that women being treated lesser than men "has only recently come to light". Open source, even (especially!) the core, important stuff is blasphemously underfunded, and it always has been. Everyone knows this, even those who deny it.
Furthermore, the psychology is uncomfortably close to the psychology of misogyny: historical precedent, deeply rooted social structures (in this case driven by software economics), by and large nobody wants to pay the significant costs of fixing it, and every now and then a truckload of goodwill is dumped on the fire to douse it so we can all forget about the broken system we're working with until the next time it breaks.
The crucial difference, and I believe flaw in your argument, is that female developers being paid less than male developers to do the same job is much more clear-cut evidence of some kind of bias than a developer on an open source project being paid less than a developer on a closed-source project.
The latter is enough apples to oranges that you might as well be wondering why an entry-level doctor gets paid more than an entry-level airline pilot.
[1] - http://minilock.io/
They've recently launched Peerio as well which is kind of a closed email-like system with easy to use end-to-end encryption based on miniLock.
What about the rest of the scorecard?
They factored the JS into a Chrome application awhile back, and while Chrome-extension JS crypto isn't particular safe either (there are realistic side-channel attacks on it), it's not the cluster•••• that content-controlled JS crypto is.
There are much, much bigger problems with Cryptocat than Javascript. I would also recommend avoiding the mobile apps, which are native.
The scorecard lists "good features" and gives you a tick if you claim to offer that feature. The score card does not currently test any of those and certainly hasn't tested the auditing or done their own audit.
I think the article[ed:1] misses the point, btw. Yes, managing keys might be tricky - but it's not really rocket science. The thing that's hard is managing trust -- which key one trusts etc. The CA system for web is completely broken. I had some hope for cacert.org -- I think that model (perhaps expanded to include recommending signing gpg-keys as well as x509 certs) has a lot of merit.
I think web of trust is the only thing that can work for managing trust. But it needs to be accessible. Have post offices and banks sign gpg keys on when people come in with valid id. Cacert is a different take -- I like to look on it as a "strucutred eternal keysigning party". I trust that model a lot more than the classic CA model. But as it is based on the CA model, it suffers the same problems with centralized trust. Centralized trust is great for organizations, it's not so great for individuals.
I think the best model would be a world-wide web of trust for gpg, helped by formal and informal signing organizations (ie: like cacert, signinparties -- and with the help of banks, governments, DMV and similar institutions that traditionally help with issuing IDs). Then there should be support for anchoring DNS/CAs (and CAs for openssh) with gpg. So that if you trust someone is a representative of an organization linked to a domain name, you can trust them to autorize a CA for that name (there's technical details here, but I think the idea should be clear enough).
CAs go away, everyone can sign their own certs -- and there's an easy way to link x509 and gpg trust.
People will still lose their keys, and get invalid keys signed etc -- key management is hard. But the really confounding thing is trust -- and knowing how to determine which keys are "proper" keys for a given entity. That's really trust management, not (just) key management.
[ed:1 whops, that was the other article on making key management easy ;-) But I suppose this comment is relevant wrt how to make encryption more readily available...]
Almost nobody can use PGP/GnuPG properly and OTR is reasonably easy to use for most people. Isn't this alone a good reason to just tell people to ignore PGP/GnuPG altogether?
to whit:
Wed Jan 11 00:33:40 EST 2006, CLAY SHENTRUP
CLAY at BROKENLADDER.COM wrote:
>
> On 1/10/06, Daniel Guido <dguido at
> gmail.com> wrote:
>>
>> Correct me if I'm wrong, but there is no
>> working implementation of OTR for e-mail
>> yet is there?
>
> There can't be really. The sender and
> receiver have to agree upon a shared secret
> at the time of transmition, which requires
> at least 3 passes.So, again, what's wrong with telling people to ignore PGP/GnuPG altogether?
-- Assange to Google's Schmidt: 'I don't use email'
http://www.computerworld.com/article/2496908/encryption/assa...
And as Assange said, if you are e.g. a journalist in the government watchlist, it could be worse (more dangerous) than not using gpg/pgp.
Text messages using OTR seems like a better way. For widespread crypto usage, telling people to ignore pgp/gpg and use texts with OTR seems more reasonable than keeping projects like GnuPG alive.
If I were running a company like Facebook who's interested in spying on people, I might even fund projects like GnuPG so that unrealistic geeks keep thinking this is a viable solution.
As for facebook, as long as they keep the XMPP access open and supported[1], at least they do support OTR. Unlike eg: google.
I don't really understand this "gpg is impossibly hard"-stance. Yes, security is hard. Why recommend OTR? Don't get me wrong, I love OTR -- but verifying OTR keys, and transporting identities across devices (eg: when getting a new phone) is pretty difficult too. Are you saying wrong use of OTR is better than wrong use of gpg, because most people that use OTR use it in a way that allow for MITM anyway?
But most importantly, the point you seem to ignore, it's not secure if you don't verify keys. I'd say most people don't verify keys with OTR -- hence they're not using it in a manner that's actually secure. I do agree that it's a lot better than people using Snapchat.
https://news.ycombinator.com/item?id=6990602
https://news.ycombinator.com/item?id=5990288
Edit: this is a nice walkthrough of a simple RNG bug https://nakedsecurity.sophos.com/2013/07/09/anatomy-of-a-pse...