Conversation

The lack of any higher level crypto primitives in the Swift standard library seems to have resulted in people just deciding to shell out to openssl to generate a CSR, which feels like an important lesson

125

Replying to

This feels like not *necessarily* the wrong implementation but I’d prefer the library that shells out to OpenSSL to be part of the Swift standard library

Replying to

and

Involving unnecessary CLI interfaces and parsing in both directions is far worse than using it directly. It can be used in a separate process (which does not imply any isolation without further work) without involving the CLI interface if that was actually the goal.

Replying to

and

I'm thinking about GPG and Git here as examples, although Git was specifically designed to operate this way and maybe GPG is not a great model for anything security-related

Replying to

and

there was efail.de where some of the vulns were due to integrity errors from shelling out to GPG not being propagated to the MUAs, which is one of the risks of shelling out

Replying to

This makes me want to get started again on my Go GPG library interfaces again, but I know I’ll forget about it until the next time.

Replying to

Use modern, secure cryptography instead. Secure messaging should be done with proper secure messaging protocols. Standalone authenticated file encryption should be done with github.com/FiloSottile/age. File signing should be done with signify/minisign which have libraries available.

github.com

GitHub - FiloSottile/age: A simple, modern and secure encryption tool (and Go library) with small...

A simple, modern and secure encryption tool (and Go library) with small explicit keys, no config options, and UNIX-style composability. - GitHub - FiloSottile/age: A simple, modern and secure encry...

Replying to

Should use a proper secure messaging protocol with forward secrecy, proper verification tools, session cross-signing (if relevant), etc. for that niche. Building it out of age + signify (or far worse, PGP) is a bad idea. Separately, building it on top of email is a bad idea.

Replying to

So, sure, I’ll definitely buy the forward secrecy argument. It does conflict with the idea of files encrypted at rest (unless you e.g. derive the session key from a file password, I guess?), but I’ve not kept up my studies wrt forward security.

Replying to

It doesn't conflict with it. You're also mixing up different use cases where the proper security properties require different cryptography and approaches. Authenticated encryption + signing of files does not give you a secure messaging system. It would be misuse of age+signify.

11:35 PM · Aug 3, 2021Twitter Web App

Replying to

You can use Matrix as something that's federated and can replace email. It has built-in end-to-end encryption, key distribution, forward secrecy, cross-signing of sessions, etc. Far from perfect and leaks metadata, but not as much as email, and it's drastically better than it.

Replying to

If self-hosting / federation are not an important requirement then there are more private messaging systems than Matrix not leaking nearly as much metadata to servers, etc. As a federated replacement for email though, Matrix is entirely suitable already. Email is legacy like SMS.

Show replies

Replying to

I should clarify that I’m not trying to be contentious here, it’s just that every time I’ve asked these questions in general it’s gotten lost in the noise, so I do appreciate you taking the time to answer.