Memory Safe TLS Library Now Has AWS Crypto and FIPS(memorysafety.org) |
Memory Safe TLS Library Now Has AWS Crypto and FIPS(memorysafety.org) |
https://github.com/pizlonator/deluded-openssl-3.2.0
It's based on Fil-C https://github.com/pizlonator/llvm-project-deluge/blob/delug...
There's no unsafe code in it. The whole thing is recompiled with Fil-C. Works well enough that I can run a memory-safe curl and a memory-safe ssh.
Fil-C will be fast, don't worry.
(The manifesto enumerates the hilarious reasons for the slowness. If you had read that, you probably wouldn't have cited the 200x.)
The underlying cryptography is still a mix of C and asm, that's the best option we have now particularly if we want support for things that make it deployable, like FIPS. We are looking for ways to improve the safety of the underlying crypto in the future.
To my knowledge, the bigger reasons for writing assembly for low-level cryptography are (1) performance, and (2) avoiding UB. The latter, particularly around C's type promotion and signed integer shifting rules, are a significant source of bugs[1].
It really depends!
Fil-C is memory-safe down to the libpizlo POSIXish syscall layer, and then even those syscalls do memory safety checks (so you can't read(2) into an OOB area of a buffer, for example).
So, some safe code is built on a crapton of unsafe code, while other safe code is built on a tightly controlled TCB. There's a big spectrum there.
Most of the actual code here is unsafe.
I think on some x86 cpu tuning levels this can happen around 1bit integers (aka bools) when the cost model says it's cheaper for whatever reason
(carry: bool, c: u64) = a.carrying_add(b)
d += carry as u64
(carry: bool, c: u64) = a.carrying_add(b)
if carry
d += 1
You can't count on that, especially if you give the compiler a loop that has a versioning opportunity.
1. Performance
2. Defense against side channel attacks (e.g. constant time operations)
It’s totally possible and it’s a thing compilers for memory safe languages sometimes have to do internally.
It wouldn’t take a lot of language engineering to make it nice. You’d end up being able to take that asm code more or less as is and annotate it with just a type proof so that Rust/Go/Fil-C can call into that shit without worrying about it blowing up your rules.
They’re not the same thing.
If they were the same thing then there would be no point to memory safety at all.
Cool man. Reaching for insults isn’t a good way to have a conversation. Good luck on your project.
Moreover, some of the assembly cores are a couple dozen lines for the hottest loops. I guess you could call the whole Go package a safe wrapper around that unsafe code, but I am used to think of a wrapper as not the place where the substantial logic is.
It's also meaningfully different from AWS-LC, discussed here, which has the entire cryptographic operation (like a signature or encryption API) implemented in C. (It's still great progress to move the TLS and X.509 implementations to a safe language, as that's where most memory safety bugs are!)
I think we’re making two different points. I am talking about at a very high level, when people say “yeah it’s safe but there’s unsafe under there” that that is always the case at some point in the stack. Even a pure Go or pure Rust program ends up needing to interact with the underlying system, whose hardware isn’t safe. There is still some code that has to reach outside of the ability of the language to check that it conforms to their abstract machines in order to do things at that level.
I don’t disagree that minimizing the amount of unsafety is a good general goal. Or that because there’s unsafe inside, that the code is not overall safe. Quite the opposite! I’m saying that not only is it possible, but that it’s an inherent part of how we build safe abstractions in the first place.
(Oh and to be honest, I wish Rust had gotten the same level of investment around cryptography that Go has had. Big fan. Sucks it never happened for us. I’m glad to see continued improvements in the space, but like, I am not trying to say Go is bad here in any way.)
Anyway, not sure why relying on C/C++ would have helped us here.
Good to know there's someone in charge specifically of the cryptographic stuff for Go at Google though.
I can't comment on the rest, but the security track record of the crypto libraries is stellar compared to pretty much any other library (and it already was before my tenure).
(BTW, I am not at Google anymore, although I still maintain specifically the crypto libraries.)