Golang: Crypto/fips140: do not bloat crypto code unnecessarily | Hacker News Reader

Golang: Crypto/fips140: do not bloat crypto code unnecessarily

github.com

19 pointszx2c48 comments

From having had my own prior interactions with you, I am entirely unsurprised that you're getting some cold shoulder due to other people's experiences with you.

As far as I can tell you're great at cryptography code. You've gotten better at the social parts of collaborative software engineering, but there's still room to grow.

Alberto (https://github.com/golang/go/issues/81639#issuecomment-58553...) found only a 75kB difference between the 'bloat' and your proposed patch in a stripped binary; and Roland (https://github.com/golang/go/issues/81639#issuecomment-58402...) contended:

> the symbols in your tester2 program account for ~67kb out of a 2.3mb binary

OP did find a "600k difference" in an unstripped comparison but if binary size was critical enough that 600k was a big deal, I'd assume users would be stripping the binaries outright or using a different language (tinygo perhaps) if a <100kb diff was on their list of concerns.

Isn't there still need for non- or post- FIPS-140 -like cipher restrictions in non FIPS-140 environments?

How much code is needed to implement Classical+PQ (Hybrid PQ) or PQ-only (Only PQ) cipher selection restrictions just?

FWIU, with golang:

  # This allows X25519MLKEM768 (Hybrid PQ)
  GODEBUG=fips140=on

  # This prevents any PQ ciphers from being used:
  GODEBUG=fips140=only

tlsref needs to be revised to specify PQ cipher lists.

FIPS-140 doesn't yet require PQC, nor does Go in FIPS mode (or any other mode).

So, if you only want PQC, you'll have to do that manually either way. But, I think you'll find many servers aren't ready for that: https://www.netmeister.org/blog/pqc-use-2026-09.html

Some notes on PQC and MTC roadmaps on "Shipping post-quantum cryptography to Python – The Trail of Bits Blog" https://news.ycombinator.com/item?id=48789958

mozilla/ssl-config-generator is now tlsref/configurar: https://github.com/tlsref/configurator .. http://configurator.tlsref.org/

It's been 2-4d since a maintainer replied. Why escalate the situation by trying to raise HN attention to it?

What's up with all the likes, urgency, and pressure? Is this part of some kind of operation?

That's not just some random guy, zx2c4 is the author of WireGuard and I'd trust him to get things right more than, oh, about 99.9% of people doing crypto out there. And the problem isn't so much the code size, it's the huge amount of unnecessary complexity and attack surface that this all this stuff adds.

Having said that, I'm not sure there's much chance of it being adopted. Crypto people really want to have all the complexity all the time, which this is the exact opposite of. I mean, do you really need a custom AVX2-accelerated SHA256 implementation so you can generate a 128-bit random value? Or all of SHA256 and SHA3 and cSHAKE and SHA512? This is what makes WireGuard so secure, there's only one mode and that's secure-by-default.

Reply on news.ycombinator.com