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
5
11
125
Conversation
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
1
1
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.
1
11
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
4
1
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
1
1
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.
1
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.
2
4
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.
1
1
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.
1
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.
2
2
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.
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.
2
2
Securing email is hopeless. It has a ridiculous amount wrong with it and even deploying authenticated transport encryption via DNSSEC+DANE, server-based anti-spoofing via DNSSEC+DMARC+DKIM, etc. has incredibly low adoption and major groups fighting against deploying it at all.
2
2
Show replies