Thread

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

18 points · 5 comments · zx2c4

Loading the complete thread in the background. This saved snapshot is available now. Refresh

westurner · 1790434779 · focus · HN ↗
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) or PQ-only 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.
1. twiss · 1790586307 · focus · HN ↗
  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: <a href="https://www.netmeister.org/blog/pqc-use-2026-09.html" rel="nofollow">https://www.netmeister.org/blog/pqc-use-2026-09.html
  1. westurner · 1790625227 · focus · HN ↗
    Some notes on PQC and MTC roadmaps in "Shipping post-quantum cryptography to Python – The Trail of Bits Blog" <a href="https://news.ycombinator.com/item?id=48789958">https://news.ycombinator.com/item?id=48789958
eqvinox · 1790572735 · focus · HN ↗
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.
clivedup · 1790602004 · focus · HN ↗
Posting this to HN as if we're a jury.
pamcake · 1790605244 · focus · HN ↗
What's up with all the likes, urgency, and pressure? Is this part of some kind of operation?
nateb2022 · 1790609930 · focus · HN ↗
Alberto (<a href="https://github.com/golang/go/issues/81639#issuecomment-5855332392" rel="nofollow">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 (<a href="https://github.com/golang/go/issues/81639#issuecomment-5840291260" rel="nofollow">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.
pseudohadamard · 1790691478 · focus · HN ↗
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.

Open on Hacker News to reply ↗

Unofficial Hacker News client; not affiliated with Y Combinator.