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...

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

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.

Show replies

Replying to

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.

Replying to

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.

Show replies