Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Memory Safe TLS Library Now Has AWS Crypto and FIPS

memorysafety.org

Post reply on HN
Print view View original

1–10 of 40 posts

Re: Memory Safe TLS Library Now Has AWS Crypto and FIPS

#4

Post by Thaxll »

steveklabnik wrote: post #3
Thaxll wrote: post #2

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.

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

Re: Memory Safe TLS Library Now Has AWS Crypto and FIPS

#5

Post by pizlonator »

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.

Re: Memory Safe TLS Library Now Has AWS Crypto and FIPS

#6

Post by jaas »

Thaxll wrote: post #2

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

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.

Re: Memory Safe TLS Library Now Has AWS Crypto and FIPS

#7

Post by pizlonator »

Thaxll wrote: post #4
steveklabnik wrote: post #3

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.

That's great! Is Go's use of unsafe mostly about perf, or is it about other stuff (some functionality you can't get without unsafe)?

Re: Memory Safe TLS Library Now Has AWS Crypto and FIPS

#8

Post by kramerger »

Thaxll wrote: post #4
steveklabnik wrote: post #3

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.

Out of curiosity, why would you ever need unsafe code in go?

Re: Memory Safe TLS Library Now Has AWS Crypto and FIPS

#9

Post by pizlonator »

jaas wrote: post #6
Thaxll wrote: post #2

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

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?

Re: Memory Safe TLS Library Now Has AWS Crypto and FIPS

#10

Post by bradfitz »

pizlonator wrote: post #5

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. "
Post reply on HN