[HN Gopher] The FIPS 140-3 Go Cryptographic Module
___________________________________________________________________
The FIPS 140-3 Go Cryptographic Module
Author : FiloSottile
Score : 187 points
Date : 2025-07-15 20:42 UTC (1 days ago)
(HTM) web link (go.dev)
(TXT) w3m dump (go.dev)
| aranw wrote:
| I'm curious to understand what implications this will have on Go
| and where it is used? How does this differ to other languages as
| well? I don't fully understand what it will mean for Go and its
| community
| tptacek wrote:
| None; it's an optional package you use when your users require
| FIPS 140.
| aranw wrote:
| Ahh okay I didn't realise it is just a package. I wondered if
| it was more than that and included stuff with the compiler or
| something
| haiku2077 wrote:
| It's also a new compiler option to transparently replace
| calls to the crypto stdlib package with FIPS versions
| haiku2077 wrote:
| It means companies with US government contracts writing Go code
| can use the standard library crypto package in native Go
| instead if having to enable CGO and using a crypto library
| written in C. CGO is kind of a pain in the ass to develop with
| compared to fully native Go code, especially when cross-
| compiling (and cross compilation is very common now that ARM is
| common on both laptops and servers).
|
| This also now makes Go a very convenient language to write US
| Gov software in.
|
| If you have never heard of FIPS before ignore this entirely and
| continue to live in happiness.
| aranw wrote:
| > This also now makes Go a very convenient language to write
| US Gov software in.
|
| This is something I wondered. Will we now see even more
| adoption of Go? Will Go be a more attractive option compared
| to language X/Yv
| haiku2077 wrote:
| Yeah, honestly, this just rocketed Go to possible one of
| the best languages to write these services in. You can
| write a fully self-contained and compliant program using
| just the standard library, where a lot of other languages
| need to be linked to a commercial SSL library.
| tptacek wrote:
| 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.
| twoodfin wrote:
| 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?
| YawningAngel wrote:
| 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.
| tptacek wrote:
| 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.
| EvanAnderson wrote:
| > 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.
| LtWorf wrote:
| > If you can get a government contract in the first place
| you are already administratively competent enough to use
| FIPS.
|
| My personal experience disagrees.
| FiloSottile wrote:
| > 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.
| chrisabrams wrote:
| > 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?
| tptacek wrote:
| crypto/, not crypto/fips140.
| FiloSottile wrote:
| 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.
| tptacek wrote:
| Not a nitpick! I was just wrong!
| bravesoul2 wrote:
| That's a nice solution when managing a platform. You can
| "upgrade" all your teams, and/or easily detect they have
| upgraded.
| 3eb7988a1663 wrote:
| 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.
| tialaramex wrote:
| > 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.
| FiloSottile wrote:
| 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
| tialaramex wrote:
| > 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.
| FiloSottile wrote:
| 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.
| wahern wrote:
| > 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
| hamburglar wrote:
| This is huge. I've spent years jumping through hoops to get Go
| projects signed off for FIPS-140 and I always worried that
| something was going to go wrong and we'd have a compliance
| nightmare on our hands. They just made it super easy.
| aranw wrote:
| Did this make Go a less attractive option compared to other
| languages then? I'm interested in understanding how this will
| help Go and the community
| caleblloyd wrote:
| Yes. Any language that dynamically links to the OS crypto
| library (like OpenSSL) is more attractive because your
| Government customer can install your software on their OS
| with their FIPS compliant OS crypto library.
|
| This moves the needle for Go but you still need to cut a FIPS
| version of your software since this crypto is still
| statically linked. I like this option quite a bit if the
| Government customers get on board with it.
|
| There are some Go forks maintained by Microsoft and RedHat I
| believe that do dynamic linking for crypto which requires
| CGO.
| haiku2077 wrote:
| > This moves the needle for Go
|
| To clarify, you could previously link to an external SSL
| library (typically something like BoringSSL) and people did
| do that. However, it makes cross compilation a pain
| compared to native Go.
| dangoodmanUT wrote:
| I think this was in MS Go before, right?
| FiloSottile wrote:
| No, the Go 1.24 native module effort that they talk about in
| https://devblogs.microsoft.com/go/go-1-24-fips-update/ is this
| effort, which Microsoft was not involved in. We simply decided
| to delay the official announcement until the module reached the
| In Process list.
|
| The system libraries approach used by Microsoft Go is cgo based
| IIUC, and I think derived from Go+BoringCrypto. I understand
| they are working on migrating their bindings to fit better
| downstream of the new native mode.
| metaltyphoon wrote:
| > and I think derived from Go+BoringCrypto
|
| It's based on OpenSSL
| FiloSottile wrote:
| Yes, it calls out to OpenSSL on Linux and to CNG on
| Windows. I think, but I am not certain, that at least the
| OpenSSL cgo bindings are derived from the Go+BoringCrypto
| ones (which makes sense, since the BoringSSL and OpenSSL
| APIs are still very similar).
| dadrian wrote:
| If DOGE had done nothing other than get rid of FIPS validation,
| the GDP unlock alone would have solved the debt problem.
| dlock17 wrote:
| Companies don't need any additional reasons to skimp out on
| security.
|
| The money could probably be more wisely spent if not following
| FIPS but without FIPS the average company wouldn't direct that
| money towards security at all.
| tptacek wrote:
| No. FIPS has literally nothing to do with security.
| dlock17 wrote:
| I may be thinking more about FedRAMP in general rather than
| just FIPS140-3, but mandating things like keeping user
| passwords out of logs is a security improvement.
|
| And the average company needs to be dragged kicking and
| screaming to care about security at all.
| tptacek wrote:
| This is about exclusively using "validated"
| implementations of specific cryptographic constructions.
| You can avoid it simply by not encrypting stuff at all,
| which is an indication of how little it has to do with
| security.
| hamandcheese wrote:
| > You can avoid it simply by not encrypting stuff at all,
| which is an indication of how little it has to do with
| security.
|
| The consequences of encrypting wrongly quite possibly are
| worse than if you never encrypted at all.
| tptacek wrote:
| Good thing FIPS 140 does virtually nothing to prevent
| cryptographic vulnerabilities, then.
| Spooky23 wrote:
| Remember when HN was losing its collective mind over
| Dual_EC_DRBG? That was delivered to customers with a FIPS
| validated software stack.
| hamandcheese wrote:
| Both of these things can be true at the same time:
|
| - "Don't use unproven cryptography" is a reasonable
| policy.
|
| - Policymaking can be subverted by bad actors.
| Spooky23 wrote:
| Yes, but neither of those things have anything to do with
| FIPS 140-3.
|
| FIPS validation address the compliance problem of needing
| validation. Beyond that, the benefits are ambiguous at
| best.
| tguvot wrote:
| fedramp requires to encrypt a bunch of stuff
| Spooky23 wrote:
| FedRAMP is more a cheatsheet for compliance people.
| Someone in a federal agency had an auditor validate that
| the required NIST controls were done.
|
| The most useful thing about FIPS 140 is that it's a great
| way of quickly identifying clueless security people.
| thayne wrote:
| > but mandating things like keeping user passwords out of
| logs is a security improvement.
|
| That has nothing to do with FIPS 140.
|
| FIPS 140 is just requirements for "cryptographic
| modules".
|
| It specifies which algorithms are allowed and requires
| that you use modules that have been "validated" by going
| through an expensive and slow auditing process.
|
| While I don't think it is completely useless to have
| those requirements, it has some problems, such as:
|
| - it takes a very long time for anything to get
| validated. For example, Ubuntu 22.04 only recently got
| its crypto packages validated after being "in process"
| for years.
|
| - bug fixes have to go through the validation process
| too, so if a vulnerability is found, you can be left
| vulnerable for a while
|
| - For many languages and runtimes, using FIPS certified
| modules is a royal pain. For example, for several
| versions of node, there was no good way to run it in a
| FIPS compatible way, because it required a newer version
| of openssl than the latest FIPS certified version. AWS
| lambdas, even in GovCloud don't include FIPS certified
| crypto, so you have to bundle it in your package and make
| sure to use your local library instead of the system
| library, which can be quite difficult depending on the
| language. Prior to this change in go, using FIPS in go
| required using cgo to link to a FIPS certified c library,
| and make sure you either did some fancy link magic to get
| any libraries you used to also use that, or don't use any
| libraries that use the standard crypto library.
|
| - It doesn't include many algorithms that are widely used
| and generally considered secure including Ed25519,
| chacha20-poly1305, argon (along scrypt, bcrypt, etc.),
| etc. This can cause problems with compatibility with
| other systems.
| __bjoernd wrote:
| Luckily, FedRAMP have updated their FIPS guidance just
| this year to allow using crypto modules that have been
| validated and then received security patches. They
| realized that security patching is important and you
| don't need to recertify every patch before using it
| anymore.
|
| https://www.fedramp.gov/rev5/fips/
| dchest wrote:
| FYI, Ed25519 is now included.
| jandrewrogers wrote:
| This has relatively little to do with actual security. It
| is compliance and certification theater for the most
| part. In many cases you can avoid it entirely by
| outsourcing caring about it to the customer. This isn't
| always a bad thing; sometimes they understand and can
| deliver on their requirements much better than you can.
| api wrote:
| Doesn't it at least keep snake oil crypto out of
| government? If it were removed it should be replaced by
| something. No standard would lead to a lot of crap being
| deployed.
| akerl_ wrote:
| It's way better at preventing usage of modern crypto than
| it is at blocking snake oil.
| api wrote:
| You seem to be assuming modern well designed crypto would
| win in government contracting with no standard.
| akerl_ wrote:
| I'm speaking from experience, not assuming.
|
| The way you get quality products is by requiring and
| validating quality, not by picking a lowest common
| denominator and then pinning it in place for a decade
| with paperwork and calcified standards bodies.
| tptacek wrote:
| A lot of FIPS-compatible crap is already deployed, and
| our most secure and trusted cryptography generally _wasn
| 't_ created under any standards regime.
| thayne wrote:
| I wouldn't say nothing. It is intended to ensure some level
| of security. And in some ways it can lead to decreased
| security if you comply with it (for example, if a
| vulnerability is found in your crypto library, you have to
| wait for the fix to be "validated" before you can patch
| it).
|
| But yeah, complying with FIPS doesn't necessarily mean you
| are secure, and it is definitely possible to be secure
| without being FIPS compliant.
| tptacek wrote:
| FIPS-140 doesn't even speak to most cryptographic
| vulnerabilities; it could prevent you from using, like,
| the PKZip cipher rather than AES, but not (really) from
| having code that could be induced into reusing a GCM
| nonce.
|
| It is of no security value.
| tguvot wrote:
| fedramp as of last year allows to use not fips validated
| version in order to patch security vulnerabilities
| dadrian wrote:
| There's a difference between FIPS validation and FIPS-
| approved algorithms. We can say "you have to use the FIPS-
| approved algorithms", but skip the useless validation step.
| firesteelrain wrote:
| Does the use of the library in your application still require the
| application itself to be FIPS validated? This just makes it a
| little easier to go through full, validated NIST compliance,
| right?.
| FiloSottile wrote:
| [ Big _I am a cryptographer, not your cryptographer_ disclaimer
| ]
|
| It depends, but if you are targeting Security Level 1 (which is
| what most folks think about when they think about FIPS 140) you
| generally don't need your entire application to be validated,
| only the cryptographic module.
|
| So _(again, depending on your requirements and on the Operating
| Environment you deploy to and on what algorithms you use and
| how)_ setting GOFIPS140 might actually be all you need to do.
| firesteelrain wrote:
| Thank you. I will remember this the next time this comes up
| at work
| bradfitz wrote:
| Congrats, Filippo!
| midocon wrote:
| This is at est!
| justincormack wrote:
| Yes its been a long journey since the early boringssl versions
| a decade ago.
| midocon wrote:
| This is a test
| SAI_Peregrinus wrote:
| The "Uncompromising Security" section[1] is particularly
| interesting to me. FIPS-140 compliance usually leads to reduced
| security, but it looks like the Go team found ways around the
| main janky bits. It's nice that there's now a FIPS-140 module for
| FedRAMP that doesn't require avoiding VMs to stay secure, for
| example.
|
| [1] https://go.dev/blog/fips140#uncompromising-security
| p_l wrote:
| Part of the issue was that there are multiple FIPS-140
| versions, and the Go support is for FIPS-140-3, which is
| honestly quite updated and less annoying. To the point I
| actually recommended running our entire environment (for a
| pretty big cloud company) FIPS-140-3 mode (maybe not fully
| compliant for everything, but essentially going with
| "FIPS-140-3 as default but outside of FedRAMP we're not going
| to consider it a breaking change if it doesn't pass") because
| the only thing we might really be missing was ChaCha ciphers
| which mainly would impact clients running from mobile devices
| or otherwise lacking in power/AES accelleration... and we had
| no such clients
| jeffrallen wrote:
| > although it doesn't necessarily improve security, FIPS 140
| compliance is a requirement in certain regulated environments
|
| LOL. At least they don't bury the lede.
___________________________________________________________________
(page generated 2025-07-16 23:01 UTC)