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

31–40 of 40 posts

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

#31

Post by senkora »

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.

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

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

#32

Post by pizlonator »

steveklabnik wrote: post #30
pizlonator wrote: post #22

Earlier quoted context omitted.

You’re disingenuously conflating calling into a pile of userland unsafe code that does crypto using arrays and ptr math, which also does unsafe syscalls, with making all that memory safe except the syscall. They’re not the same thing. If they were the same thing then there would be no point to memory safety at all.

> You’re disingenuously Cool man. Reaching for insults isn’t a good way to have a conversation. Good luck on your project.

Using disingenuous arguments will get you to nothing but bad ideas. I'm just trying to help you out.

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

#33

Post by the8472 »

woodruffw wrote: post #20
the8472 wrote: post #18

Earlier quoted context omitted.

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.

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.r…

Afaik there's no guarantee that the compiler won't perform such changes. Even if it happens to generate the expected instructions today it could change with the next compiler release.

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
could be turned into

   (carry: bool, c: u64) = a.carrying_add(b)
   if carry
     d += 1
And I recall doing some bittwiddling to get something like a cmov but the compiler recognized the pattern and turned it back into a branch (this was for performance optimization, not crypto, but still...)

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

#34

Post by pizlonator »

woodruffw wrote: post #20
the8472 wrote: post #18

Earlier quoted context omitted.

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.

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.r…

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

You can't count on that, especially if you give the compiler a loop that has a versioning opportunity.

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

#35

Post by pizlonator »

senkora wrote: post #31
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.

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

So?

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

#36

Post by GrumpySloth »

woodruffw wrote: post #20
the8472 wrote: post #18

Earlier quoted context omitted.

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.

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.r…

I’ve had rustc turn my branchless code consisting purely of bitwise operations into branching code. There was probably nothing rustc-specific about it. Just LLVM estimating that branches would be faster in that case.

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

#37

Post by GrumpySloth »

steveklabnik wrote: post #28
FiloSottile wrote: post #23

Earlier quoted context omitted.

Not really, a number of our crypto implementations are pure Go. In fact, we always have a pure Go fallback that you can select with "-tags purego". As of Go 1.23 we will be systematically testing it, too, because it enables other compilers like TinyGo. They might be slower, but with the notable exception of AES (because implementing AES in constant time without AES-NI is hell) the pure Go implementations are just as…

Sorry, just to be clear, I don’t know anything about Go’s crypto implementations, I was purely responding to the parent who claimed they were wrappers around asm. 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…

There is also the compiler. A language may claim to be implemented without any unsafe code in the standard library, but all that happened is the unsafe code got hidden in the compiler, in how it generates code, in intrinsics etc.

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

#38

Post by littlestymaar »

FiloSottile wrote: post #27
littlestymaar wrote: post #26

Earlier quoted context omitted.

And they now have to deal with the same kind of timing attacks related stuff as everybody else https://github.com/golang/go/issues/49702 (and they'll likely lag behind)

Do you know of any cryptography implementation that sets the Data Independent Timing flag? We've been trying to figure out what others are doing about it, because as far as I can tell nobody is. Anyway, not sure why relying on C/C++ would have helped us here.

The point is not about relying on C/C++, it's about using existing implementations instead of re-inventing the wheel all the time. This is a cultural thing when it comes to Go and it has bitten them multiple times, like when they tried not to use the system's libc on MacOS or when they had issues when dealing with memory pages on Linux.

Good to know there's someone in charge specifically of the cryptographic stuff for Go at Google though.

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

#39

Post by FiloSottile »

littlestymaar wrote: post #38
FiloSottile wrote: post #27

Earlier quoted context omitted.

Do you know of any cryptography implementation that sets the Data Independent Timing flag? We've been trying to figure out what others are doing about it, because as far as I can tell nobody is. Anyway, not sure why relying on C/C++ would have helped us here.

The point is not about relying on C/C++, it's about using existing implementations instead of re-inventing the wheel all the time. This is a cultural thing when it comes to Go and it has bitten them multiple times, like when they tried not to use the system's libc on MacOS or when they had issues when dealing with memory pages on Linux. Good to know there's someone in charge specifically of the cryptographic stuff fo…

Go has good reasons not to bring C/C++ into every build, starting from the ability to cleanly cross-compile.

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

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

#40

Post by Dolamifa »

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