I’m definitely down with using something more modern and applicable, but (aside from atrocious usability issues) I have trouble understanding what’s so fatally flawed about PGP as a de facto standard.
Conversation
And the problems with the other ones are lack of widespread support in mail/file/desktop clients compared to PGP, which is a fixable problem, but we gotta settle on a smaller subset of things before that’ll happen.
1
Meanwhile, I still need to interact with PGP signed/encrypted files, so making a library that does that properly instead of shelling out to GPG is something that has potential benefit to me.
1
PGP for secure messaging especially via email is very misguided. Even a decent implementation wouldn't have decent / expected security properties. A secure messaging system should have automatic rotation of long-lived keys, forward secrecy for sessions, proper verification, etc.
1
1
If you want federated, end-to-end encrypted messaging use Matrix instead of insecure cryptography poorly bolted onto a protocol ill suited for it. It doesn't solve the hard problems. Can't paper over the fact that it's fundamentally designed wrong with awful security properties.
1
1
In general, I’m happy to concede that there’s not a great one-size-fits-all solution for what PGP tries to tackle, namely encryption/signing of files at rest (for multiple recipients) and encryption/signing of ephemeral/ish messages in transit, which is more session-oriented.
1
You can consider signify+age as a replacement for GPG. It's just not a good approach to secure messaging outside of niche use cases. For example, the best approach for accepting anonymous submissions of encrypted files would be age. It's anonymous authenticated file encryption.
1
2
If you want to prove authenticity too, you need to sign it with signify. However, you still have authenticated encryption with age alone without signify. It just doesn't assert an origin so while someone can't tamper with the message, they could outright replace it with another.
1
1
I’ll need to dig into that more, then, sounds like that pairing covers about 90% of what I’m interested in.
1
1
Signify signatures are a line with "untrusted comment: ..." followed by a line with base64 encoded signature.
Encoded data is "Ed" (in case it ever needs a new algorithm), 64-bit key id (no security relevant beyond helping with rotation) and raw ed25519 signature (~20 bytes).
1
1
Minisign extends with with trusted (verified) comments and optional built-in pre-hashing support. If you don't use those extensions, minisign signatures are compatible with signify.
Signify also knows how to verify files via a signed BSD-style hash file (minisign doesn't).
Age gives you authenticated encryption for files with either public/private keys or passphrases. Creator of the file is anonymous when using either native age keys or passphrases. I think it would be nice if it provided signing but leaving it up to signify/minisign is fine too.
2
1
Since it has authenticated encryption, age does essentially have signing when using passphrases.
It's a design choice to omit having a way to declare who is creating an encrypted file when encrypting to someone's public key. They'd rather leave it up to signify/minisign for now.
1
1
Show replies
Yeah, I read the slides/site respectively. Very well documented (unlike the typical GNU Sea Of Docs that GPG has). And I’m pretty familiar with signify as a long-time OpenBSD user, though I hadn’t really read up on it much.