Good to see this project make progress -- well done to the development team. Whatever you think about pgp, it's not going away anytime soon, and a new implementation is an opportunity to brush away some cobwebs and even improve the ecosystem[1].

[1] https://sequoia-pgp.org/holistic-approach/

With all the great encryption utilities like age[0], Signal, or Veracrypt, can anyone please tell me what the point is in using pgp anymore? It's old, it's clunky, it requires careful use to be safe.

Why not use something more modern?

0. https://github.com/FiloSottile/age

Signal and veracrypt are not PGP replacements, not even remotely close.

Regarding age, one reason is that it only supports a small fraction of PGP functionality thus useless for many real world applications. Another is that it operates on top of a fundamentally different model and for many folks that model is worse and potentially less secure than PGP's if you try to replicate PGP functionality by composition [1].

Modern doesn't necessarily equal good. PGP is mature and solid which is why it's still widely used and remains popular.

[1] https://neilmadden.blog/2019/12/30/a-few-comments-on-age/

I am going to be sending email long after those tools are gone, and for the time being, the only option for securing that I have is PGP.

This does not mean I think PGP is great, it just means it is working now, across many MUAs.

I agree that PGP is clunky. Maybe it's just me, but I often find that modern is the opposite of safe and robust.

I'm not sure where that's the case, but it's certainly not the case with cryptography, where "clunky" means "mired in design decisions made before the era of authenticated cryptography".

To me, "old and clunky" also tends to imply "memory unsafe", or "written in Perl so old that a pipe filter in the wrong place in the input coughs up a shell", or "better make sure nobody's name is O'Connor because that includes SQL metadata", or "lol remember temp file races". But I'm prepared to concede that there may be places where the old stuff is better than the new, and eager to hear examples.

My 10Mbps hub (yes, not a switch) has been with me for decades. I've owned lots of smarter (switched, managed) and faster (100Mbps and then 1Gbps) devices that used less power (turns out when 10Mbps was invented nobody cared about "power saving"...) but over the years lots of those have dropped dead whereas the 10Mbps hub still works, which is why I still own it even though it isn't currently wired up, I know that sooner or later a 1Gbps switch will die and I'll hook that 10Mbps hub in there until a new one arrives.

Now, is it "better"? Overall, no. Or else I wouldn't keep buying Gigabit switches. But is it more robust? Yes. And if that's what you care about...

Thanks very much for the additional depth on what “old and clunky” could mean in cryptography. I am no expert in this area, and I agree that all these nightmare scenarios you mention (and many more, I’m sure) are very concerning. I prefer to use old (tested and tried) Unix/BSD tools for interactive development rather than their latest rewrites or modern GUIs. In drug design, I’d rather have a clearly understood 30-year-old assay with known failure modes rather than the latest promising experiment that may still have unknown failure modes. But generally speaking, I am a sucker for new tech and I seem to never learn to stop playing with new shiny toys. In a field with explosive growth field, like machine learning, at least I can use the benchmarks against the state of the art to help me decide how or when to advance technologies (every month or so, it seems). So.. is it worthwhile to learn to use age?

cperciva's spiped is, at least, deliberately old-fashioned; and I'd be inclined to trust it over most newer designs. (Wireguard does appear to be pretty awesome.)

I do agree that lots of legacy cryptosystems just aren't very good.

compatibility. Many existing systems, including secure email and packaging systems such as apt use PGP keys.

Sure in theory you could encrypt your email with age, but how many clients support that flow? How do you distribute the public keys?

Part of the point of sequoia as I understand it is to make PGP a little less clunky and easier to use safely.

stop with that FUD. PGP is a standard and an implementation. You can have secure (Open)PGP implementation. at least there's a official spec, which is not there for age, which complicates reimplementation

Anyone has a good tutorial on how to use sq, their command line utility?

It's not a tutorial in the classic sense, but as the CLI is rather simple, and as there are examples, I'd point you at the official docs (man page like):

https://docs.sequoia-pgp.org/sq/index.html

The sub commands feel like they are pretty much self-explanatory to me, e.g., encrypt, decrypt, verify are pretty clear in what they will do, and the options for those sub-commands seem not to cryptic either to me, but that's naturally a bit opinionated.

Besides that the initial release news article of the sq tool has some quick demo: https://sequoia-pgp.org/blog/2021/01/26/202101-sq-release/

What would be your use cases for sq?

"seem not too cryptic"

nice.

Great!

Perhaps coincidentally, on PGP 30th birthday!

Not a coincidence -- in the first paragraph! :)

I know they plan to relicense from GPL to MPL eventually, but I wish they would do it sooner rather than later.

I don't even mind the GPL, in fact most of the code I've ever written is GPL. But there are plenty of projects for which I would prefer a different license.