> It's encouraging to see the GnuPG project benefitting from similar largess. But it also raises the question: how is the money best spent?
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.
Yeah, I hope he sees a minimum of $500k - $1mil, which is about representative of what he'd have accrued spending that much time at a regular, somewhat modestly-paid tech job.
I'm more concerned he might mismanage the money. He seems like a really nice guy but seems to have no great business/finance perspective. Still, he is free to do whatever the fuck he wants with my small donation. I feel like I owe him a lot more than that.
This. The article says Google and Facebook each gave him 50 big ones. Which != 0, but I can't help but thinking that's like .00001 seconds of Google profits, given to a project that is probably on the critical path of >50% of their business.
Google's profit was $13G in 2013, according to Wikipedia. Thus $50,000 amounts to about 2 minutes of their profit stream. You are off by seven orders of magnitude...
More to the point, how do you figure that GPG is on the "critical path" of 50% of Google's business?
It's not like the first time he's handling money like that the GnuPG development. In the past, he received two separate grants for exactly that by the German government, and he even employed developers for some time.
> Matt Green, a professor specializing in cryptography at Johns Hopkins University, said he has looked at the GnuPG source code and found it in such rough shape that he regularly assigns chunks of it to his students for review. "At the end I ask how they felt about it and they all basically say: 'God, please I never want to do something like this again,'"
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.
Dear Werner - if you are reading this: Please ignore all the articles and comments about "how is the money best spent"! They don't know what they are talking about! Instead take 2-3 weeks free and bring your whole family somewhere in Mediterranean Sea to the long deserved holidays so you can rest from all the financial burden, take a fresh breath and gather new energy and motivation for the project! And please again: ignore those comments! Greetings from Munich!
Indeed. I notice he has a family to support, otherwise I'd have proposed "please use half of the money on wine, women and song, and the rest you can just waste". Whatever he decides to do with the donations, I'll say he's earned the right to do anything he wants.
I fear he'll anyway just hire some help for himself to work on this stuff...
The vitriol in the article is pretty surprising to me. Monday morning quarterbacking of an open source project is pretty noxious. Is there some other story that I'm not aware of here?
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 vitriol in the article is pretty surprising to me. Monday morning quarterbacking of an open source project is pretty noxious. Is there some other story that I'm not aware of here?
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.
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.
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.
It affects the data encrypted by GPG until that "new and improved" version, as long as the keys have "older" format. Until recently the GPG was able to use such "older format" key for both encryption and decryption. Now it can't do both. And that was even not necessarily known by the users, that they used something "older": you saw the shorter fingerprint but otherwise everything worked.
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.
We must maintain perfect backward compatibility back to the beginning of time! We must have pristine clean and cruft-free code to help ensure mistakes are easy to catch!
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.
While I agree that support needs to be dropped eventually. Printing a warning and only allowing decryption with weak keys would have been a better option IMO.
Keep that around for a year or two, then drop support fully.
> For people who use GPG for e.g. securing transferred documents that might be called in court
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.
A legitimate concern, but just as with outdated file formats, I don't think it unreasonable to expect users to forward-port their data. If you have some spreadsheets or dtp documents authored on mac os 9, you might have a hard time using them today. As for old versions - with vms I think we're in a better place for forward-security than we used to be. The day we can't boot up an amd64 linux vm seems to be far, far in the future
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.
I think that's you're really hitting the nail on the head here.
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.
Could you please post some links with explanations about incompatibilities? I still use GPG 1.4.18; I'm willing to upgrade if necessary, but am I also supposed to re-encrypt everything?!
Is there some other story that I'm not aware of here?
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.
That's not fair. I've talked to Dan Goodin a number of times regarding some pretty complicated stuff, and he's listened carefully, demanded clarification when I was unclear, and didn't cherry-pick a splashy quote or two and then ignore the substance of the interview. Most people I've talked to seem to agree with me that Goodin is one of the better journalists covering security topics.
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 pitch stories regularly to reporters. Dan is by far one of the best reporters in the business, and is the person I go to whenever I have something that is interesting, but far too technical for the mainstream press. He always does an excellent job with it, particularly if I give him a few days.
I've worked with plenty of unprofessional reporters who butcher stuff, and don't care about the details. Dan isn't like that.
> Goodin is a journalist, not a security researcher. He depends on researchers as sources for his story
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
> But it also raises the question: how is the money best spent?
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.
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.
> The main problem with the code, he said, is it hasn't been properly maintained over the years.
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.
Not much to add here myself other than something for the folks who are less steeped in networking and security concerns: you should not try to audit this stuff yourself. Parent to this post can help you find a good auditor for your language.
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.
If you assume the rest of his comment is true (I'm no crypto expert but it seems intuitive enough for me, and he is a crypto expert!), having something like a session cookie (which can be attacker controlled) encrypted with GPG (which means it's now "online", without manual intervention) has now increased the attack surface considerably; it gives up the neat offline part of GPG and makes it easier to attack.
It has gotten a lot better lately. It was designed in the era before people quite realized that everything should be a library first and an application using that library second, and that still shows. However, the most recent version pulls all the interesting cryptographic operations out of the application and puts them into gpg-agent, paving the way for a future libgpg that holds no key material and just asks the agent to perform signing/encryption operations. I'm really looking forward to that.
Its actually 120k in direct donations, 60k from CII, 50k from facebook and another 50k from stripe. Even at just under 300k it still isn't much for a development team.
Honestly... given that likely millions of people read about this yesterday, I think it's showing of how ineffective internet donations can be that it was a worldwide top story and only generate a few hundred thousand dollars.
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.
I imagine if there were a concerted fundraising campaign behind it, they could raise much more. The money they got off the story is just the lowest of the low-hanging fruit.
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.
If I understood correctly, if given as salaries, half of the received money will go to taxes (for Germany, like most of Europe, it's typical tax to the salaries) as the developer handles everything through his company. And everything donated through paypal will also be additionally charged.
"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."
I wonder what Green means as the alternative to auditing the GnuPG code. Doing nothing? Or could he be arguing that it would be better to start from scratch? Is there a replacement in the wings? Or even as a glint in someone's eye?
In <https://github.com/google/end-to-end> I see that "End-To-End is a Chrome extension that helps you encrypt, decrypt, digital sign, and verify signed messages within the browser using OpenPGP."
Overall a bad article, but the issues it brings up are important:
> 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.
I don't think you're going to find a lot of sympathy in drawing parallels between gender equality issues and open-source issues. (And you're likely to get blowback for stepping on a third rail type of issue, whether fair or not.)
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.
People were talking about potential weaknesses in Cryptocat for some time. Cryptocat ignored those people, then bickered with them. Then someone released a PoC and Cryptocat it turns out was really broken.
You can't use OTR for email. Well not in a meaningful way, anyway.
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...]
It certainly doesn't have to be. A person's trust of long-time friends is an important metric for network security. Not every key-signing party involves government ids.
What do you mean by people can't use OTR for email in a meaningful way?
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?
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.
I meant that there cannot be a reasonable OTR implementation for email. You can stop using email if you want - I love it, as the last vestige of useful decentralised service on the Internet (I run my own email service, and many organisations do too). You can encrypt your email -- but not with OTR. S/MIME and gpg/pgp do work.
I kind of thought that the web itself was a major example of a useful decentralized service on the internet; kind of odd for email to be described as the last beside of that.
To the extent that HTTPS is the protocol of the web, its primary implementation (the CA system) is, in every meaningful way, centralized along exactly the same lines as much of the rest of society: in governments and corporations.
It was. It technically still is. But large parts of what makes the web useful -- content and search/indexing is being trapped in silos like Google, G+, Twitter, Facebook, Blogspot etc.
gpg/pgp do work for those who can use it properly, which is a tiny minority. Can your parents or non-tech savvy friends use gpg/pgp? Probably not.
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.
I'm not convinced most people that can't use gpg "properly" are able to use OTR "properly".
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?
I don't think you need to be convinced. When 99% of people look at the choice between (a) Thunderbird+Enigmail and (b) TextSecure, they know which one is easier to use (your Mom probably knows more than you do in this regard), not to mention OTR has properties that PGP/GPG lacks such as PFS.
Textsecure is nice, but it's not really an alternative to encrypted email. It doesn't support off-line use, it's inconvenient for sharing large documents.
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.
Care to elaborate on that? I'm in the habit of more or less trusting the EFF, but I don't use cryptocat (no need for it) and I have heard that it is insecure. My understanding (possibly flawed), is that it was mostly tied to the JS Crypto implementation.
You can look around for what other crypto and security people thought of the EFF scorecard. It was not well-regarded.
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.
That scorecard carefully says that it's not an endorsement of any product yet here in this thread we have someone using it as an endorsement of a product.
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.
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.