11–20 of 40 posts
But AWS Crypto is made in C/C++/ASM, so yes the wrapper is sort of safe but the implementation is not.
All safe code is inherently built on top of unsafe code.
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.
Earlier quoted context omitted.
All safe code is inherently built on top of unsafe code.
The Go crypto implementation uses some unsafe/asm part but it does not rely on external C/C++ lib. Very different.
Or you could just use memory-safe OpenSSL. 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.
"On the other hand, Fil-C is quite slow. It's 200x slower than legacy C right now. "
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.)
Earlier quoted context omitted.
All safe code is inherently built on top of unsafe code.
Ish. 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.
Earlier quoted context omitted.
All safe code is inherently built on top of unsafe code.
Yes, but ideally you want the unsafe code to be as small and auditable as possible. Most of the actual code here is unsafe.
Earlier quoted context omitted.
The Rustls TLS implementation and certificate verification are all safe Rust. 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.
Is it just a perf issue, or something else?
1. Performance
2. Defense against side channel attacks (e.g. constant time operations)
But AWS Crypto is made in C/C++/ASM, so yes the wrapper is sort of safe but the implementation is not.
Earlier quoted context omitted.
Ish. 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.
You’re describing exactly what I am describing: you still call out into a syscall that is not safe. You prevent that by checking things in the wrapper. Very standard.
But AWS Crypto is made in C/C++/ASM, so yes the wrapper is sort of safe but the implementation is not.
The issue with writing crypto code in anything above assembly is that there's a risk that optimizing compilers could turn your finely crafted constant time, constant power code into something which is not that.
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].