Is PGP a zombie technology that won’t ever die because there are organizations that have nailed their identity to it?
(For everything you think you should use PGP for please use Age - https://github.com/FiloSottile/age)
(For everything you think you should use PGP for please use Age - https://github.com/FiloSottile/age)
Most people should just use GPG for stuff like this.
Is the antipathy towards GPG based on it being too easy to misuse/misapply, or is it because it's broken when used properly?
That greatly misrepresents my position. Generally I prefer that things follow some sort of open standard. For offline capable, stateless encryption that leaves the OpenPGP standard. I have spent some time looking at it and judge it to be completely OK and worthy of use. I was even inspired to write a series of articles about it in an attempt to counteract the misinformation that I have seen:
Cryptography tools should do one thing and do it well. Most of PGP’s problems stem from it including the kitchen sink.
If you need signatures, use minisign.
This is public key cryptography 101 stuff...
This thread has been both interesting and educational.
Frankly in my reading of your question you come across as very arrogant, where you use the guise of a “serious question” to show off your knowledge cryptography.
There have been many articles written that push back against the narrative a small cohort of security people push that GnuPG and OpenPGP by extension should be avoided at all costs. Personally, I find it has stood the test of time admirably and that its "multi-tool" functionality unlocks features I use almost every day like a web of trust in Keybase and using it as an ssh agent. I actually don't want another tiny tool in age. With Sequoia the future of PGP looks bright.
I've reviewed both the design and implementation for age in the past and only found nitpicky things to improve (mostly related to HKDF).
I can take a fresh look and make a pretty PDF on paragonie.com if you care so much.
Hell, I have shirts older than the language it's written in.
In 20 years, I might not even be able to find a working compiler to build it, after the shiny-object crowd moves on to something else.
You know what I'll still be able to decrypt? An ASCII-armored, GPG encrypted, TAR archive.
Personally, I am not interested in the latest evolutionary improvements on file formats. Evolution produces a lot of interesting things; most of them are dead ends. What I want is the cockroach of file formats. The coelacanth.
Using common libraries, I can create a python program to decrypt a file produced by age in a few hours, I think.
No. Brand new means completely new. Something that's going on 3 years old isn't brand new anymore.
A more appropriately term is relatively new. Civilization is relatively new compared to the age of the universe. Age is relatively new compared to modern computers.
But neither civilization nor age are brand new.
You want a specific tool for each of these use-cases. Choose one from the list for each use case.
1. Private messaging: Signal, WhatsApp, Cwtch
2. File encryption: age
3. Encrypted backups: age + a Reed-Solomon encoder for catching flipped bits
4. Digital signatures: minisign, signify, OpenSSH signatures
The problem with GPG (and with PGP in general) is it tried to do too many things. Complexity is the enemy of security.
WhatsApp’s record over the last decade does not inspire confidence, and the issues raised this year alone are quite serious:
https://wikipedia.org/wiki/Reception_and_criticism_of_WhatsA...
It's just a foundation-sort of program that does encryption and signing of arbitrary data, using one format for keys, and allowing working with those keys whether they're in the same computer or in a smartcard/hsm. That simplifies key management, since it allows you to have one Yubikey with your PGP key on it and do basically anything crypto related.
But what I believe someguydave was referring to was stuff like smartcard/Yubikey support, not different uses of encryption and signing.
https://twitter.com/FiloSottile/status/1474941666545086465 ¯\_(ツ)_/¯
Bug jedisct1 if you want YubiKey support for minisign.
I fear that I might of caused this idea. I have as a result added the following footnote to the article that I suspect is the cause[1]:
>Please note that the single flipped bit here is not a realistic example and that in practice damage tends to encompass one or more media blocks. Such blocks tend to be multiples of 512 bytes.
I am afraid that someone might actually implement this...
This list item was prompted by a private discussion with friends.
It's probably maybe fine, and of course code can change at any time, but with software focused on security, it would seem more necessary than, say, an audio player (excluding improbable situations).
Either way, It's nice to see a GPG alt written in Go.
Which is surely a strong argument for having keys that are standalone and portable across different communication media, rather than having them be coupled to accounts on particular services (or, worse, to personal information like an SSN or phone number).
(Also, the use case here is clearly much, much narrower than for age and minisign. Which is good, assuming the problem it solves is the problem you have, but should still be noted.)
Are any of the big language-specific ecosystems capable of that? (npm, crates.io, composer, PyPI, CPAN, Maven, rubygems, etc.)
For example, it would be nice to delay automatic updates of WordPress plugins and themes until after there is more than just the uploader's identity as a single point of failure guaranteeing that the update is genuine.
(Obviously the perfect way to do things given enough developer resources is to review all code yourself before installing manually, but it would be nice to improve situations where those resources are not available.)
The intention was to allow security vendors to offer code reviews of open source dependencies, and you can choose which you trust. This mechanizes Linus's Law and ensures there's an audit trail with "many eyeballs".
> The intention was to allow security vendors to offer code reviews of open source dependencies
What I care most about is just quorum publishing where multiple independent identities sign a release, so that an attacker has to compromise multiple trusted identities to execute a supply chain attack. I'm not too excited about reviews beyond that. The main thing is to upgrade collective ecosystem security by hardening automatic updates.
And, yes, there is a lot of work necessary to get WordPress to use Gossamer. I can't guarantee a deadline right now, but 2022 looks hopeful.
Huh? Unless you're signing it (in which case of course it's not deniable, it's a signature) it has no such nature.
Do you care to elaborate on those good reasons that the web of trust "failed"?
The most widespread practical use of PGP's signature capabilities are for package systems, where the actual contents of the package aren't confidential to begin with; PGP is only being used to sign. But PGP signatures are clumsy and archaic, and there are better tools to get the same capability without PGP's baggage --- notably the "signify" scheme that OpenBSD came up with and that minisign implements.
I'm not sure where you're heading when you think that the general populace would be any less confused about that.
https://blog.cryptographyengineering.com/2016/03/21/attack-o...
age doesn't replace everything PGP does, which is good, because PGP does too many things. It just replaces the use case of file encryption (which itself is arguably too general; it's perhaps best to think of age as a good fallback for encryption use cases that don't have a better domain-specific tool). See https://latacora.micro.blog/2019/07/16/the-pgp-problem.html
https://news.ycombinator.com/item?id=27181576
Obviously consider the source, but: I think that thread is better reading than the article.