Natanael_L

What's your usecase here? Internal or external messaging?

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.

Downgrade protection, malleability protection, sidechannel protection, disambiguation, context binding, etc...

You want software to be implemented by experts using known best practices with good algorithms and audited by other experts.

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)

... At which point the only new data that chatgpt can reliably scrape is its own answers...

Everything is open source so yes you can, it's mostly a question of practicality.

There's already third party clients, account hosting servers, etc, as well as different apps building on the same system (and which can use the same accounts and data store!) like blogs and more. Most devs are trying to coordinate their custom extensions so it doesn't cause conflict.

If it weren't coordinated we'd easily end up in the same place as Mastodon with their spurious server blocks where large parts of conversations are broken for most users.

Before Musk, Twitter used to fight those requests.

The platform can not be called better, with more bugs and errors than ever.

Why don't they apply those rules to Republicans? Why can they specifically post stuff like private info about Hunter?

Musk is reposting actual neonazi accounts

Most of that doesn't deserve to be called an improvement. That message encryption is one of the worst designs I've ever seen. The algorithm isn't open enough that anybody can see if what it's doing matches the code.

And instead of censoring "secretly" in partnership with the US government they do so in partnership with the Indian government as well as individual Republican politicians.

It's used in a not particularly advanced way - bluesky uses repositories per each user for all their public social activity (posts, likes, etc) and it creates a Merkle tree as an index for them and signs that index (this enables stuff like authenticated content addressing and efficient verification).

SQLite simply stores those posts and that signed Merkle tree. The PDS account host server also has another SQLite DB with a list of its accounts.

They have fancier stuff in their appview server and relay server