Memory Safe TLS Library Now Has AWS Crypto and FIPS

https://www.memorysafety.org/blog/rustls-with-aws-crypto-back-end-and-fips/

by SGran • 2 years ago

47 38 2 years ago

memorysafety.org

Thaxll2• 2 years ago

But AWS Crypto is made in C/C++/ASM, so yes the wrapper is sort of safe but the implementation is not.

steveklabnik6• 2 years ago

All safe code is inherently built on top of unsafe code.

Thaxll2• 2 years ago

The Go crypto implementation uses some unsafe/asm part but it does not rely on external C/C++ lib. Very different.

MattPalmer1086• 2 years ago

Yes, but ideally you want the unsafe code to be as small and auditable as possible.

Most of the actual code here is unsafe.

pizlonator11• 2 years ago

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.

jaas2• 2 years ago

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.

pizlonator11• 2 years ago

Is it just a perf issue, or something else?

the84722• 2 years ago

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.

woodruffw2• 2 years ago

Generally speaking, an optimizing compiler is not going to introduce a branch (especially a data-dependent branch) where one doesn't exist in the code.

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

[1] https://blog.regehr.org/archives/1054

pizlonator11• 2 years ago

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.

bradfitz• 2 years ago

"On the other hand, Fil-C is quite slow. It's 200x slower than legacy C right now. "

pizlonator11• 2 years ago

It's slow for good reasons, like ensuring that I have a super reliable compiler that lets me port a lot of stuff without dealing with miscompiles.

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

senkora• 2 years ago

This is legitimately very interesting but I can't help but notice that every single one of your commit messages is either "more shit" or a misspelling thereof: https://github.com/pizlonator/deluded-openssl-3.2.0/commits/...

pizlonator11• 2 years ago

So?

Dolamifa• 2 years ago

This is an exciting update! Leveraging AWS libcrypto is a smart move that will allow Rustls to access robust and validated cryptography while focusing development efforts elsewhere. Achieving FIPS 140-2 validation expands possibilities for regulated industries to securely adopt Rustls. Kudos to the team on enabling more widespread usage of this critical communication security technology!

Memory Safe TLS Library Now Has AWS Crypto and FIPS

Related Stories