Ubuntu Developing "crypto-config" For System-Wide Cryptography Configuration

[phoronix]

Phoronix: Ubuntu Developing "crypto-config" For System-Wide Cryptography Configuration

A new Ubuntu utility seeing an uptick in development recently is crypto-config as a means of system-wide cryptography configuration...

https://www.phoronix.com/news/Ubuntu-crypto-config

[milo_hoffman]

Red Hat/Fedora already has system wide default crypto policies via crypto-policies. https://gitlab.com/redhat-crypto/fedora-crypto-policies

Its very handy.

[Britoid]

Red Hat/Fedora already has system wide default crypto policies via crypto-policies. https://gitlab.com/redhat-crypto/fedora-crypto-policies

Its very handy.

The only problem is its python dependency.

[Jumbotron]

Although I’m sure it’s not exclusive to, this config could be getting itself wired up for the day that the entirety of Ubuntu including the kernel is not only atomic but snapped.

[mortn]

The only system-wide cryptography setup should be for transparently secured system to system communication, or? But even for that you would want to have a specific system user owning the private keys to enable that. If you tie crypto to a system do you then need to restart the system to rotate keys? If not, is it then considered system-wide?
What is the use case(s) for system-wide cryptography?

[adrien-n]

Author here.

What is the use case(s) for system-wide cryptography?

The point of a Linux distribution is to have a consistent set of software where everything integrates and plays well together. The configuration of cryptography is something where distributions typically fall short today.

I have a table somewhere which shows how 6 or 7 widely-used packages taken at random all have different TLS configurations: ciphers, elliptic curves, key sizes, ...

Trying to unify everything makes some things obvious. One example is postgresql which uses P-256 and for compatibility and future-proofness, one would like to also handle e.g. P-384. Unfortunately the code is not appropriate for several curves. Therefore it's not possible to have a nice upgrade path where you would support P-256 but also a stronger curve and once the migration to the stronger curve is far enough, stop offering P-256. This shows how not having a unified configuration can hurt.

Now, do the same, but times 1000 packages.

As for keys, this is not a topic for crypto-config.

Finally, a word about rebooting: I'd like to avoid requiring that for new configurations to take effect and have a detection like with needrestart in order to offer rebooting the relevant services only. That's a topic for later however.

[docontra]

The only system-wide cryptography setup should be for transparently secured system to system communication, or? But even for that you would want to have a specific system user owning the private keys to enable that. If you tie crypto to a system do you then need to restart the system to rotate keys? If not, is it then considered system-wide?
What is the use case(s) for system-wide cryptography?

It's system-wide cryptographic options (which key/key exchange/hmac/whatever algorithms are enabled/disabled, key sizes, etc). The issue this software tries to help with is "there are at least three crypto libraries[1] in very widespread use across our packages and it's a PITA to configure them all". It's not a "one private key to rule them all" situation.

[1]: openssl, gnutls, nss (Mozilla), among many, many others (libressl, boringssl, mbedssl, wolfssl, the list goes on and on)

[NotMine999]

The only problem is its python dependency.

What? NO RUST dependency?

Well that surely can't be State Of The Art coding, right? Better investigate Red Hat/Fedora for using child labor.

[sarmad]

Although I’m sure it’s not exclusive to, this config could be getting itself wired up for the day that the entirety of Ubuntu including the kernel is not only atomic but snapped.

Do you know what the status of that is? I thought Ubuntu Core Desktop was aiming for a release by 24.04.

[Delgarde]

It's system-wide cryptographic options (which key/key exchange/hmac/whatever algorithms are enabled/disabled, key sizes, etc). The issue this software tries to help with is "there are at least three crypto libraries[1] in very widespread use across our packages and it's a PITA to configure them all". It's not a "one private key to rule them all" situation.

The catch is that most things I might want to secure these days run in containers... where such system-wide configuration is irrelevant. And conversely, anything not in a container is probably something I'm happy to trust to OS-shipped defaults.