Crashes with env var GODEBUG=fips140=only

[bryopsida]

Environmental Info:
K3s Version: All post golang 1.24

Describe the bug:
K3S does not startup when setting environment variable: GODEBUG=fips140=only

This is due to sha1 hash usage in cluster/encrypt: https://github.com/k3s-io/k3s/blob/main/pkg/cluster/encrypt.go#L31

FIPS mode can be checked before selecting a hash see: a8161f4 as an example.

One impact to this would be, all cluster members would need to have FIPS mode enabled to derive the same key from the passphrase.

An additional thing to note is SHA1 is no longer considered secure so migrating to a different hash algorithm regardless of FIPS mode may be desirable.

https://en.wikipedia.org/wiki/SHA-1

I'm willing to stand up some PRs to fix this if it's a change that would be accepted.

Steps To Reproduce:

• Install K3S
• set environment variable GODEBUG=fips140=only on the process start/restart it

Expected behavior:
K3S Starts up

Actual behavior:
K3S Crashes

[brandond]

This use of SHA1 is not related to digital signature; PBKDF2-HMAC-SHA1 is still secure. Note for example that git still uses SHA1; if all you need is a hash it is fine.

That said, it being broken when FIPS is enabled is irritating; we'll have to figure out how to work around it. This will be a bit fussy as AFAICT disabling FIPS mode also disables SHA1 in the decrypt path, which means the data will need to be migrated to a different bootstrap key with a different hash alg BEFORE enabling FIPS.

[bryopsida]

Note for example that git still uses SHA1; if all you need is a hash it is fine.

That's true but I believe some hosted providers are using an extended/patched version SHA1-CD, but with the key derivation iterations that may not be a concern here but that's beyond my understanding.

This will be a bit fussy as AFAICT disabling FIPS mode also disables SHA1 in the decrypt path, which means the data will need to be migrated to a different bootstrap key with a different hash alg BEFORE enabling FIPS.

Would it be possible to slice it into a few phases? IE something like this.

1. Both encrypt/decrypt sides check FIPS enablement, if FIPS is enabled use an approved KDF and hash on both sides allowing new clusters where all members have the policy enabled to be created, but leave existing behavior intact for envs where the policy is not enabled.

2. Add toggle/cli arg to optional opt into SHA-256 that mimics the above FIPS behavior

3. Flip behavior of toggle from opt in to default on but add a fallback mechanism where if it fails it will go back sha1 and migrate (there's some assumptions here that the failure can be detected due to using decryption that supports AEAD like AES GCM) when failure is detected decrypt using SHA1, re-encrypt using SHA-256 etc.

4. Eventually, if it makes sense to, remove the split logic and just have the SHA-256 usage.