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)
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
You need a private PKI, not keyring. They're subtly different - a PKI can handle key rotation, etc.
Yes there aren't a lot of good options for that. If you're using something like a Microsoft software stack with active directory or similar identity/account management then there's usually some PKI support in there to anchor to.
Across organisations, there's really very very few good solutions. GPG specifically is much too insecure when you need to receive messages from untrusted senders. There's basically S/MIME which have comparable security issues, then we have AD federation or Matrix.org with a server per org.
> You could say, we do not need gpg, because we control the mailserver, but what if a mailserver is compromised and the mails are still in mailboxes?
How are you handling the keys? This is only true if user's protect their own keypairs with strong passwords / yubikey applet, etc.
What you described IS WHY age is the better option.
GPG's keyring handling has also been a source of exploits. It's much safer to directly specify recipient rather than rely on things like short key IDs which can be bruteforced.
Automatic discovery simply isn't secure if you don't have an associated trust anchor. You need something similar to keybase or another form of PKI to do that. GPG's key servers are dangerous.
You technically can sign with age, but otherwise there's minisign and the SSH spec signing function
Then your next best bet is Matrix.org. Not to the same security standard as Signal, but if you don't have a specific threat against you then it's fine.
Asking for an equivalent to GPG is like asking for an equivalent of a Swiss knife with unshielded chainsaws and laser cutters.
Stop asking for it, for your own good, please. If you don't understand the entire spec you can't use it safely.
You want special purpose tools. Signal for communication, Age for safer file encryption, etc.
What exact problems did you have with age? You're not explaining how it broke anything. Are you compiling yourself?
Age has yubikey support and can do all you described.
> if your fancy tool has less than 5 years of proven maintenance record, it won't do. Encryption is for the long term. I want to be able to read my stuff in 15-30 years.
This applies to algorithms, it does not apply to cryptographic software in the same way. The state of art changes fast, and while algorithms tend to stand for a long time these days there are significant changes in protocol designs and attack methods.
C2PA has the problem that it has a ton of optional metadata support and no well-defined strict validation procedure, so it's trivial to make fake photos appear valid using currently available C2PA enabled software.
They absolutely must define a much stricter mode that actually means something, and distinguish it from what they have now (which is essentially prototype level in terms of security model)
Also, the RPi is the wrong kind of hardware for attestation, at least use something like USB Armory which provides a user programmable ARM TrustZone environment.
Since USB Armory supports pinning multiple keys for secure boot (and IIRC protected storage), you could even deliver it set up with a manufacturer attestation key and allow the user to load and pin their own attestation key (useful for an organization like a news company) as well as allowing "dual boot" between the attested firmware signed by the pinned manufacturer key and the user's own firmware. I've wanted that kind of behavior in consumer hardware for a long time, where you have full freedom between using the locked down OEM environment or your own and switching between them freely.
(I assume the USB Armory might also not be ideal in terms of ability to sleep and boot speed, etc, but if you have a quicker smaller controller that's the main board then it could wake the one that supplies attestation and make that functionality available after it's done booting)
Declaring them absolute also don't solve these problems, because sometimes you can end up with conflicts between absolute rights, where you are not able to protect both rights at once.
By that logic we shouldn't recommend cars with high safety ratings, because we can always train users to drive motorized unicycles at 200 MPH. Clearly there's no fault with the unicycle regardless of how many people crash, it behaved as specified.
But you can't trivially define your own scopes wherein each has their own independent set of trusted CA:s. That's part of what's missing. But default it's universal or per program.
Just look at every kind of umbrella organization out there like industry specific auditors with a scope limited to a field (medical, finance, food safety), or even hobby organizations with a parent organization auditing local chapters.
You don't go to the social security office to look up your neighbors phone number when you need to talk to them. The attributes people care about are often more local, more narrow.
People first go to local trust anchors to get information about things (and their software clients could then traverse various directories up to a root and back down, if necessary). I need my client to be able to understand an assertion from an entity far more personal to me than a distant CA. The CA:s are most useful in ephemeral connection, not long term ones.
This is what I mean when I say the CA system isn't expressive enough.
The problem with this is that a tool that is too generic is itself dangerous, because it creates cross protocol attacks and confusion attacks like in https://efail.de for PGP email.
I think that a better approach is to bind identities from multiple purpose built cryptographic protocols.
As I've mentioned in another thread, I think we're more likely to get there via the route of E2EE documents collaboration tools. Something that cleanly breaks away from the email model, and adds enough value to make the switch worth the effort.
I think we're more likely to "accidentally" end up there via E2EE document collaboration tools that are in development now.
One day, a while after they become usable and common, people will just realize they've been sharing documents E2EE in place of sending email, and they'll be using it for basically everything that matters.
It would be a proper restart and allow for significant improvements in usability and security and everything else.