Hacker News Reader

Comment by some_furry | Hacker News Reader

https://soatok.blog/2024/11/15/what-to-use-instead-of-pgp/

I wrote this to answer this exact question last year.

> The only downside to Sigstore is it hasn’t been widely adopted yet.

Which, from where I stand, means that PGP is the only viable solution because I don't have a choice. I can't replace PGP with Sigstore when publishing to Maven. It's nice to tell me I'm dumb because I use PGP, but really it's not my choice.

> Use SSH Signatures, not PGP signatures.

Here I guess it's just me being dumb on my own. Using SSH signatures with my Yubikeys (FIDO2) is very inconvenient. Using PGP signatures with my Yubikeys literally just works.

> Encrypted Email: Don’t encrypt email.

I like this one, I keep seeing it. Sounds like Apple's developer support: if I need to do something and ask for help, the answer is often: "Don't do it. We suggest you only use the stuff that just works and be happy about it".

Sometimes I have to use emails, and cryptographers say "in that case just send everything in plaintext because eventually some of your emails will be sent in plaintext anyway". Isn't it like saying "no need to use Signal, eventually the phone of one of your contacts will be compromised anyway"?

> Which, from where I stand, means that PGP is the only viable solution because I don't have a choice.

You don't have a choice today. You could have a choice tomorrow if enough people demanded it.

Don't let PGP's convenience (in this context) pacify you from making a better world possible.

I agree with that. But I feel like I have been reading for years that there is really no reason to use PGP, and I have tried for years to use alternatives, but the fact remains that I still need to use PGP, either because it is mandatory or because in some cases the alternatives are not practical.

To me, there will be no reason to use PGP the day I find practical alternatives for the remaining use-cases I have. And I feel like signing git commits is not a weird use-case...

Does the GnuPG project sign its git commits with PGP?

Not sure what you are trying to say

Of course it does, and all released software and tarballs as well.

The fact that every email encryption integration exports secure context messages into insecure contexts when decrypting (which is how encrypted messages end up cited in plaintext) means email can't be secured.

This is true both for GPG and S/MIME

Email encryption self-compromises itself in a way Signal doesn't

offtopic question:

as a recent dabbling reader of introductory popsci content in cryptography, I've been wondering about what are the different segmentation of expert roles in the field?

e.g. in Filippo's blogpost about Age he clarified that he's not a cryptographer but rather a cryptography engineer, is that also what your role is, what are the concrete divisions of labor, and what other related but separate positions exists in the overall landscape?

where is the cutoff point of "don't roll your own crypto" in the different levels of expertise?

You did not ask me, but you should do your due diligence because there are way too many armchair cryptographers around here.

My job title is in the Security Engineer family.

I do not have a Ph.D in Cryptography (not even an honorary one), so I do not call myself a Cryptographer. (Though I sometimes use "Cryptografur" in informal contexts for the sake of the pun.)

Interesting. In a general sense, where does it fall on the xkcd#435 scale?

What you actually want doing crypto is a security engineer, not a cryptographer. To quote Shamir's Law, "cryptography is bypassed, not attacked". No-one ever attacks the crypto, they attack the way it's used, so you need an experienced cryptoplumber to set it up correctly, not a cryptographer who will design a mathematically elegant whatsit and announce "there, solved!".

Ideally, this person will also design the system that uses the crypto, because no matter how skilled the people on a standards committee might be their product will always be, at best, a baroque nightmare with near-infinite attack surface, at worst an unusable pile of crap. IPsec vs. Wireguard is a prime example, but there are many others.

There isn't one, but the modal professional cryptography engineer probably has a graduate degree in cryptography.

There's no clear segmentation. There's symmetric and asymmetric primitives (and stuff that doesn't fit into these like ZKP), algorithms, protocols, research in many different types of attacks against each of these, research in design and defenses, and plenty of people will cover completely different subsets.

"don't" roll your own cover everything from "don't design your own primitive" to "don't make your own encryption algorithm/mode" to "don't make your own encryption protocol", to "don't reimplement an existing version of any of the above and just use an encryption library"

(and it's mostly "don't deploy your own", if you want to experiment that's fine)

I wonder if there is a concrete point at which it turn into “this is common sense security that even you should know about” like not conflating hashing and encryption, or “you should just have someone else do do security for you”? I guess at larger entities you have a CISO role but what about in smaller, scrappy endeavours, how does one know where one is at the limit of their due-commonsense and hand it off?

Most practitioners in security --- from information security to compliance to systems security to software security to red-teaming --- have very little competence with cryptography. Cryptography is hyperspecialized. It is not part of the toolkit of any ordinary professional.

(That's nothing to do with how hard cryptography is, just with how little demand there is for serious cryptography engineering, especially compared with the population of people who have done serious academic study of it.)

Reply on news.ycombinator.com