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