Hacker News Reader

Comment by tptacek | Hacker News Reader

It's interesting and kind of neat in an inside-baseball way that the standard Go cryptographic library (already unusual in the major languages for being a soup-to-nuts implementation rather than wrappers around an OpenSSL) is almost fully NIST-validated; in particular, it means vendors who want to sell into FedGov can confidently build with the Go standard library.

Having said all this: nobody should be using crypto/fips140 unless they know specifically why they're doing that. Even in its 140-3 incarnation, FIPS 140 is mostly a genuflection to FedGov idiosyncrasies.

View on HN

> Applications that have no need for FIPS 140-3 compliance can safely ignore [this page], and should not enable FIPS 140-3 mode.

https://go.dev/doc/security/fips140

Yup.

> Having said all this: nobody should be using crypto/fips140 unless they know specifically why they're doing that. Even in its 140-3 incarnation, FIPS 140 is mostly a genuflection to FedGov idiosyncrasies.

What should folks use then?

crypto/, not crypto/fips140.

To nitpick, there is no special crypto/fips140 package. (Ok, there is, but it just has an Enabled() bool function.)

FIPS 140-3 mode is enabled by building with GOFIPS140=v1.0.0 (or similar, see https://go.dev/doc/security/fips140), but it shares 99% of the code with non-FIPS mode.

Still, your message is right, just GOFIPS140=off (the default!), not GOFIPS140=v1.0.0.

Not a nitpick! I was just wrong!

That's a nice solution when managing a platform. You can "upgrade" all your teams, and/or easily detect they have upgraded.

Would you say there’s a brown M&M’s aspect (intentional or otherwise) to FIPS-140, or is it all just bowing to the sovereign for his indulgences?

Not really. It isn't hard to use FIPS validated software, it's just annoying to do because most libraries you would want to use aren't FIPS compliant by default for good reasons. If you can get a government contract in the first place you are already administratively competent enough to use FIPS.

Yeah, I don't think there's any malice to any of this; FIPS is just the product of a particularly conservative (backwards-looking, path-dependent) and market-unaccountable standards process. It's like what would happen if JPMC had so much market power that they could make their own cryptographic standard; it would, I am saying, suck ass, without anyone meaning for it to.

> If you can get a government contract in the first place you are already administratively competent enough to use FIPS.

Speaking as a sysadmin for a local government roped into FIPS requirements by way of FBI CJIS compliance I can safely say your assumption of competence is incorrect.

It may be that just everyone else is even moreso incompetent.

> If you can get a government contract in the first place you are already administratively competent enough to use FIPS.

My personal experience disagrees.

Does that mean it might be easier, regardless of language, to shell out to your cryptographic Go binary rather than deal with OpenSSL? I dislike a lot of Go, but they have been pretty good about backwards compatibility.

> already unusual in the major languages for being a soup-to-nuts implementation rather than wrappers around an OpenSSL

What does "Soup-to-nuts" require in this context? Should I expect that Go has for some reason re-implemented the x86-64 machine code to do ChaCha20 or do you still consider it a "Soup-to-nuts" implementation if they reuse the same machine code for this that you'd find in everybody else's implementation so long as they wrote their own wrapper code ?

Unlike say compression there's no real room in these core features to innovate. You can't pick different "nothing up my sleeve" numbers, you can't can't offer more parametrisation, anything like that would be an incompatibility - it's intentionally a standardized component.

Off the top of my head, there might be some old assembly by Andy Polyakov and by Vlad Krasnov that was contributed to both Go and OpenSSL. Even there, we’ve been working for years to port hand-written assembly to higher level generators, and there’s not as much as you’d think. Everything else is original.

Besides integrating properly with Go applications, this lets us optimize for readability and correctness, with IMHO excellent empirical results.

https://words.filippo.io/a-literate-go-implementation-of-pol...

https://go.dev/blog/tob-crypto-audit

https://www.youtube.com/watch?v=lkEH3V3PkS0

> there’s not as much as you’d think

Nah, I'm pretty sure there's exactly as much (assembly) as I'd think because I spent some time prodding it before writing the question in the first place.

You likely understand what it does much better than me, but I'm under no illusion that there's a lot of this code, nor indeed that it's problematic to use this code.

However I'm not at all convinced that porting "hand written assembler to higher level generators" is a good strategy for this specific code. It serves to launder the creativity, so that maybe some day one lawyer can convince another lawyer that A and B are distinct works despite every actual process along the convoluted path from A to B being mechanical... but it doesn't seem like it gets us closer to having a sustainable alternative.

And that's what I actually am interested in here, I think we want a Special Purpose language focused on emitting guaranteed constant time machine code for an algorithm. So that actually gets to the same Readability and Correctness goals you state, but rather than hoping to get away with writing Go (or any GP language) we accept that it's never going to make sense for a General Purpose language to prioritise this. IMO We're more or less guaranteeing one day we accidentally ship an Oracle.

Well, ML-KEM has zero assembly and was written entirely from scratch, for example, so it must be more than you'd think if you think we "reuse the same machine code for this that you'd find in everybody else's implementation." In fact, almost everyone else's was found to be producing a variable-time DIV instruction, while ours was unaffected.

Porting the assembly to higher-level generators has nothing to do with lawyers (??), the goals are stated in https://go.dev/wiki/AssemblyPolicy.

The idea that one day we'll write All Of The Cryptography Code Once And For All In The Perfect Language and reuse that across languages comes up pretty regularly, and has never panned out.

ML-KEM? How did you get from ChaCha20 to ML-KEM? Is it just that you skimmed the original comment and are focused on a different topic altogether? I was trying to understand what constitutes "Soup-to-nuts" here because I think Thomas is putting the distinction in the wrong place.

Still, now we're here:

It's foolish to wait for a "perfect language" but it's not foolish to look for a way to improve the status quo, and I don't buy that just because it so happens it "never panned out" previously that won't ever change.

Which actually gets me back to that DIV instruction. What ensured Go couldn't have this problem? Just luck? The IRA's warning to Thatcher seems very applicable.

Thomas and I are both talking about the Go cryptographic library overall, not about the ChaCha20 implementation in particular. Anyway, I don’t find arguing semantics around the “soup-to-nuts” expression particularly productive.

We avoided the DIV by deliberately not using a modulus operation and doing Barrett reduction instead.

> I think we want a Special Purpose language focused on emitting guaranteed constant time machine code for an algorithm.

https://github.com/jasmin-lang/jasmin

Reply on news.ycombinator.com