CRYPTO-POLICIES(7)

✨ bestie, you have landed on CRYPTO-POLICIES(7) ✨ aka the manual page that explains how your entire system agrees on which crypto is cute and which crypto has been cancelled 💅

💖 NAME 💖

crypto-policies — system-wide crypto policies overview 🫶

🦋 DESCRIPTION 🦋

okay so first thing, and this is important: the security of the cryptographic components of the operating system does not stay constant over time. it moves. it evolves. it's giving fashion. 📈📉

Algorithms — think cryptographic hashing and encryption — typically have a lifetime, and once that lifetime is up they're either considered too risky to use, or just plain insecure. so we need to phase out those algorithms from the default settings, or completely disable them if they could cause an irreparable problem. no cap. 😤

back in the day, algorithms were not disabled in a consistent way, and different applications applied different policies (the chaos... I cannot 😭). but now the system-wide crypto-policies that the crypto core components follow let us consistently deprecate and disable algorithms system-wide. slay. ✨

Several preconfigured policies (DEFAULT, LEGACY, FUTURE, and FIPS) and subpolicies are included in the crypto-policies(7) package. System administrators or third-party vendors can define custom policies and subpolicies. yes, you too can be a policy girlie 💅

The recommended way to modify the effective configuration is to apply a custom subpolicy on top of a predefined policy. why? because that way your configuration gets to evolve with future updates of the predefined policies while your desired modification stays exactly where you put it. 🫶

if you instead modify the effective configuration by defining a fully custom policy, your configuration is locked in and will not evolve with future updates of the predefined policies. it's giving "I did this to myself" 💀. The syntax to define custom policies and subpolicies is described in the CRYPTO POLICY DEFINITION FORMAT section below. keep scrolling bestie.

for rationale (aka receipts), see RFC 7457 for a list of attacks taking advantage of legacy crypto algorithms. 📜

---

🌈 COVERED APPLICATIONS 🌈

Crypto-policies apply to the configuration of the core cryptographic subsystems, covering TLS, IKE, IPSec, DNSSec, and Kerberos protocols — i.e., the supported secure communications protocols on the base operating system. that's the whole squad. 👑

Once an application runs in the operating system, it follows the default or selected policy and refuses to fall back to algorithms and protocols that are not within the policy — unless the user has explicitly requested the application to do so. so: the policy applies to the default behavior of applications when running with the system-provided configuration, but the user can override it on an application-specific basis. main character exception, honestly. 🙈

The policies currently provide settings for these applications and libraries:

• Kerberos 5 library (scopes: krb5, Kerberos)
• OpenSSH SSH2 protocol implementation (scopes: OpenSSH, SSH)
• OpenSSL TLS library (scopes: OpenSSL, SSL, TLS)
• libssh SSH2 protocol implementation (scopes: libssh, SSH)

Applications using the above libraries and tools are covered by the cryptographic policies unless they are explicitly configured otherwise. iykyk. 💖

---

👑 PROVIDED POLICIES 👑

🌸 LEGACY 🌸

This policy ensures maximum compatibility with legacy systems; it is less secure and it includes support for TLS 1.0, TLS 1.1, and SSH2 protocols or later. The algorithms DSA and 3DES are allowed, while RSA and Diffie-Hellman parameters are accepted if larger than 1024 bits. This policy provides at least 64-bit security. (yes, sixty-four. be nice to her.)

• MACs: all HMAC with SHA-1 or better + all modern MACs (Poly1305 etc.)
• Curves: all prime >= 255 bits (including Bernstein curves)
• Signature algorithms: with SHA1 hash or better (DSA allowed)
• TLS Ciphers: all available >= 112-bit key, >= 128-bit block (including 3DES, excluding RC4)
• Non-TLS Ciphers: same as TLS ciphers with added Camellia
• Key exchange: ECDHE, RSA, DHE
• DH params size: >= 1024
• RSA keys size: >= 1024
• DSA params size: >= 1024
• TLS protocols: TLS >= 1.0, DTLS >= 1.0

🎀 DEFAULT 🎀

The DEFAULT policy is a reasonable default policy for today's standards. It allows the TLS 1.2, and TLS 1.3 protocols, as well as IKEv2 and SSH2. The Diffie-Hellman parameters are accepted if they are at least 2048 bits long. This policy provides at least 112-bit security — with the exception of allowing SHA-1 signatures in DNSSec, where they are still prevalent. (she's doing her best ok 🥺)

• MACs: all HMAC with SHA-1 or better + all modern MACs (Poly1305 etc.)
• Curves: all prime >= 255 bits (including Bernstein curves)
• Signature algorithms: with SHA-224 hash or better (no DSA)
• TLS Ciphers: >= 128-bit key, >= 128-bit block (AES, ChaCha20, including AES-CBC)
• non-TLS Ciphers: as TLS Ciphers with added Camellia
• key exchange: ECDHE, RSA, DHE (no DHE-DSS)
• DH params size: >= 2048
• RSA keys size: >= 2048
• TLS protocols: TLS >= 1.2, DTLS >= 1.2

🦋 NEXT 🦋

The NEXT policy is just an alias to the DEFAULT policy. that's it. that's the whole policy. she's a remix. 💀✨

💜 FUTURE 💜

A conservative security policy that is believed to withstand any near-term future attacks — at the expense of interoperability. It may prevent communication with many commonly used systems that only offer weaker security. This policy does not allow the use of SHA-1 in signature algorithms. The policy also provides some (not complete) preparation for post-quantum encryption support in form of 256-bit symmetric encryption requirement. The RSA and Diffie-Hellman parameters are accepted if larger than 3071 bits. This policy provides at least 128-bit security. 🔮

• MACs: all HMAC with SHA-256 or better + all modern MACs (Poly1305 etc.)
• Curves: all prime >= 255 bits (including Bernstein curves)
• Signature algorithms: with SHA-256 hash or better (no DSA)
• TLS Ciphers: >= 256-bit key, >= 128-bit block, only Authenticated Encryption (AE) ciphers
• non-TLS Ciphers: same as TLS ciphers with added non AE ciphers and Camellia
• key exchange: ECDHE, DHE (no DHE-DSS, no RSA)
• DH params size: >= 3072
• RSA keys size: >= 3072
• TLS protocols: TLS >= 1.2, DTLS >= 1.2

🐝 BSI 🐝

A security policy based on recommendations by the german government agency BSI (Bundesamt fuer Sicherheit in der Informationstechnik, translated as "agency for security in software technology") in its ruleset BSI TR 02102 (TR - technical recommendation). The BSI TR 02102 standard is updated in regular intervals. 📅

This policy does not allow the use of SHA-1 in signature algorithms (except DNSSEC and RPM).

The policy also provides some (not complete) preparation for post-quantum encryption support in form of 256-bit symmetric encryption requirement.

The RSA parameters are accepted if larger than 2047 bits, and Diffie-Hellman parameters are accepted if larger than 3071 bits.

This policy provides at least 128-bit security, excepting the transition of RSA.

• MACs: all HMAC with SHA-256 or better + all modern MACs
• Curves: all prime >= 255 bits (including Bernstein curves)
• Signature algorithms: with SHA-256 hash or better (no DSA)
• TLS Ciphers: >= 256-bit key, >= 128-bit block, only Authenticated Encryption (AE) ciphers
• non-TLS Ciphers: same as TLS ciphers with added non AE ciphers
• key exchange: ECDHE, DHE (no DHE-DSS, no RSA)
• DH params size: >= 3072
• RSA keys size: >= 2048 (until end of 2023, then it will switch to 3072)
• TLS protocols: TLS >= 1.2, DTLS >= 1.2

Note that compared to others profiles Chacha20 and Camellia are not recommended by the BSI. 🙅‍♀️

⭐ FIPS ⭐

A policy to aid conformance to the FIPS 140 requirements. This policy is used automatically by a dracut initramfs module and a systemd service if the kernel is booted with fips=1 to switch the system into the FIPS 140 mode. This policy provides at least 112-bit security. 🛡️

• MACs: all HMAC with SHA1 or better
• Curves: all prime >= 256 bits, hybrid ML-KEM
• Signature algorithms: with SHA-256 hash or better (no DSA), pure ML-DSA
• TLS Ciphers: >= 128-bit key, >= 128-bit block (AES, including AES-CBC)
• non-TLS Ciphers: same as TLS Ciphers
• key exchange: ECDHE, DHE (no DHE-DSS, no RSA), KEM-ECDH
• DH params size: >= 2048
• RSA params size: >= 2048
• TLS protocols: TLS >= 1.2, DTLS >= 1.2

💀 EMPTY 💀

All cryptographic algorithms are disabled (used for debugging only, do not use). seriously bestie. it's a debugging tool, not a lifestyle. 🚫🙈

💖 CRYPTO POLICY DEFINITION FORMAT 💖

okay bestie so the policy definition files? they're giving very much INI file energy — a simple key = value situation, but with some extra little quirks that you absolutely need to know about. let's go one by one:

• Comments? # is your girl. everything on the line after that character is straight up ignored, no cap.
• You can also do line continuation: a backslash \ immediately followed by the end-of-line character means the next line gets glued onto the current line — after the backslash and the EOL characters are removed. it's giving "we're one line actually" 💅
• Value types for integer options can be decimal integers, like option = 1. slay.
• Multiple-choice options? you set them to a list of values: option = value1 value2. and then you can also alter that list by prepending/omitting/appending values: option = prepended -omitted appended. a follow-up reassignment resets the list, btw. ⚠️ important: that second syntax cannot be combined with the first one in the same directive. pick a lane. also, setting an option to an empty list is possible with option =.
• The asterisk sign can be used for wildcard matching as a shortcut for specifying multiple values when setting multiple-choice options. but listen — wildcard matching can lead to future updates implicitly enabling algorithms that aren't available yet in the current version. if that stresses you out (valid), do not use wildcard-matching outside of algorithm-omitting directives. periodt.
• and to limit the scope of a directive so it only affects some backends, you use the extended syntax: option@scope = ..., option@{scope1,scope2,...} = .... you can negate scopes with option@!scope / 'option@{scope1,scope2,...}. scope selectors are case-insensitive 🫶

---

✨ the options you can use (the whole menu) ✨

• mac: List of allowed MAC algorithms
• group: List of allowed groups or elliptic curves for key exchanges for use with other protocols
• hash: List of allowed cryptographic hash (message digest) algorithms
• sign: List of allowed signature algorithms
• cipher: List of allowed symmetric encryption algorithms (including the modes) for use with other protocols
• key_exchange: List of allowed key exchange algorithms
• protocol: List of allowed TLS, DTLS and IKE protocol versions — but mind that some backends do not allow selectively disabling protocol versions and only use the oldest version as the lower boundary. 😭
• min_dh_size: Integer value of minimum number of bits of parameters for DH key exchange
• min_dsa_size: Integer value of minimum number of bits for DSA keys
• min_rsa_size: Integer value of minimum number of bits for RSA keys
• min_ec_size: Integer value of minimum number of bits for EC keys (Applies to Java back end only)
• sha1_in_certs: Value of 1 if SHA1 allowed in certificate signatures, 0 otherwise (Applies to GnuTLS back end only.)
• arbitrary_dh_groups: Value of 1 if arbitrary group in Diffie-Hellman is allowed, 0 otherwise
• ssh_certs: Value of 1 if OpenSSH certificate authentication is allowed, 0 otherwise
• etm: ANY/DISABLE_ETM/DISABLE_NON_ETM allows both EtM (Encrypt-then-Mac) and E&M (Encrypt-and-Mac), disables EtM, and disables E&M respectively. (Currently only implemented for SSH, do not use without @SSH scope.)

bestie, quick note on the file names: full policy definition files have the suffix .pol, and subpolicy files have the suffix .pmod. Subpolicies do not have to have values set for all the keys listed above. no pressure 🎀

and here's the tea on how they stack: the effective configuration of a policy with subpolicies applied is the same as a configuration from a single policy obtained by concatenating the policy and the subpolicies in question. literally just glued together.

---

🗂️ policy file placement and naming 🗂️

• The policy files shipped in packages are placed in /usr/share/crypto-policies/policies and the subpolicies in /usr/share/crypto-policies/policies/modules.
• Locally configured policy files should be placed in /etc/crypto-policies/policies and subpolicies in /etc/crypto-policies/policies/modules.
• The policy and subpolicy files must have names in upper-case except for the .pol and .pmod suffix, as the update-crypto-policies command always converts the policy name to upper-case before searching for the policy on the filesystem.

iykyk: capitalize those filenames or the lookup will simply not find you 💀

---

🎮 COMMANDS 🎮

• update-crypto-policies(8) — This command manages the policies available to the various cryptographic back ends and allows the system administrator to change the active cryptographic policy. it's the main character fr.

---

📌 NOTES 📌

known notable exceptions 👀

• Go-language applications do not yet follow the system-wide policy.
• GnuPG-2 application does not follow the system-wide policy.

In general only the data-in-transit is currently covered by the system-wide policy.

If the system administrator changes the system-wide policy with the update-crypto-policies(8) command it is advisable to restart the system, as the individual back-end libraries read the configuration files usually during their initialization. The changes in the policy thus take place in most cases only when the applications using the back-end libraries are restarted. so like… reboot energy. 🔄

removed cipher suites and protocols 🗑️

The following cipher suites and protocols are completely removed from the core cryptographic libraries listed above (yes, gone gone):

• DES
• All export grade cipher suites
• MD5 in signatures
• SSLv2
• SSLv3
• All ECC curves smaller than 224 bits
• All binary field ECC curves

cipher suites and protocols disabled in all predefined policies 🚫

The following ciphersuites and protocols are available but disabled in all predefined crypto policies:

• DH with parameters < 1024 bits
• RSA with key size < 1024 bits
• Camellia
• RC4
• ARIA
• SEED
• IDEA
• Integrity only ciphersuites
• TLS CBC mode ciphersuites using SHA-384 HMAC
• AES-CCM8
• all ECC curves incompatible with TLS 1.3, including secp256k1
• IKEv1

notable irregularities in the individual configuration generators 🙈

• OpenSSL: Disabling all TLS and/or all DTLS versions isn't actually possible. Trying to do so will result in the library defaults being applied instead. 💀 not you thinking you could just turn it all off.
• OpenSSL: The minimum length of the keys and some other parameters are enforced by the @SECLEVEL value, which does not provide a fine granularity. The list of TLS ciphers is not generated as an exact list but by subtracting from all the supported ciphers for the enabled key exchange methods. For that reason there is no way to disable a random cipher. In particular all AES-128 ciphers are disabled if the AES-128-GCM is not present in the list; all AES-256 ciphers are disabled if the AES-256-GCM is not present. The CBC ciphers are disabled if there isn't HMAC-SHA1 in the hmac list and AES-256-CBC in the cipher list. To disable the CCM ciphers both AES-128-CCM and AES-256-CCM must not be present in the cipher list.
• OpenSSH: DH group 1 is always disabled on server even if the policy allows 1024 bit DH groups in general. The OpenSSH configuration option HostKeyAlgorithms is set only for the SSH server, as otherwise the handling of the existing known hosts entries would be broken on client.
• OpenSSL: order of group values is only respected within PQ and classic group "classes", and all PQ groups are automatically sorted higher than classic ones. To optimize latency while connecting to both PQ and non-PQ -aware hosts, key shares are generated and sent for the one highest priority PQ group and the one highest priority classic group. To prioritize PQ groups when both are supported, the servers prefer a PQ group over a classic group if there's an overlap in any of the PQ groups.

---

📜 HISTORY 📜

The ECDHE-GSS and DHE-GSS algorithms are newly introduced and must be specified in the base policy for the SSH GSSAPI key exchange methods to be enabled. Previously the legacy SSH GSSAPI key exchange methods were automatically enabled when the SHA1 hash and DH parameters of at least 2048 bits were enabled. glow-up moment ✨

Before the introduction of the custom crypto policies support it was possible to have an completely arbitrary crypto policy created as a set of arbitrary back-end config files in /usr/share/crypto-policies/<POLICYNAME> directory. With the introduction of the custom crypto policies it is still possible but there must be an empty (possibly with any comment lines) <POLICYNAME>.pol file in /usr/share/crypto-policies/policies so the update-crypto-policies command can recognize the arbitrary custom policy. No subpolicies must be used with such an arbitrary custom policy. Modifications from local.d will be appended to the files provided by the policy.

The use of the following historaically available options is discouraged:

• min_tls_version: Lowest allowed TLS protocol version (recommended replacement: protocol@TLS)
• min_dtls_version: Lowest allowed DTLS protocol version (recommended replacement: protocol@TLS)

The following options are deprecated, please rewrite your policies:

• ike_protocol: List of allowed IKE protocol versions (recommended replacement: protocol@IKE, mind the relative position to other protocol directives).
• tls_cipher: list of allowed symmetric encryption algorithms for use with the TLS protocol (recommended replacement: cipher@TLS, mind the relative position to other cipher directives).
• ssh_cipher: list of allowed symmetric encryption algorithms for use with the SSH protocol (recommended replacement: cipher@SSH, mind the relative position to other cipher directives).
• ssh_group: list of allowed groups or elliptic curves for key exchanges for use with the SSH protocol (recommended replacement: group@SSH, mind the relative position to other group directives).
• sha1_in_dnssec: Allow SHA1 usage in DNSSec protocol even if it is not present in the hash and sign lists (recommended replacements: hash@DNSSec, sign@DNSSec).
• ssh_etm: Value of 1 if OpenSSH EtM (encrypt-then-mac) extension is allowed, 0 otherwise. Use etm@SSH instead.

📂 FILES 📂

okay so here's where everything actually lives on your system, bestie. the whole map 🗺️✨

• /etc/crypto-policies/back-ends — the actual individual back-end config files for all the crypto stuff. usually these are symlinked to the config that ships inside the crypto-policies package, and they stay that way unless a config from local.d gets added on top. 💅
• /etc/crypto-policies/config — literally just a file holding the name of the crypto-policy that's active on your system rn. that's it. that's the whole job. 👑
• /etc/crypto-policies/local.d — extra config that other packages drop in, or that you (the sysadmin, main character) made yourself. here's the tea: the contents of <back-end>-file.config get appended to the config coming from the policy back end as shipped in the crypto-policies package. so it stacks. 🫶
• /usr/share/crypto-policies/policies — system policy definition files. the originals. 💖
• /usr/share/crypto-policies/policies/modules — system subpolicy definition files. 🎀
• /etc/crypto-policies/policies — custom policy definition files, as set up by the system administrator. this is your corner. 🌸
• /etc/crypto-policies/policies/modules — custom subpolicy definition files, also as set up by the system administrator. 🦋
• /usr/share/crypto-policies/<'POLICYNAME'> — pre-generated back-end configurations for policy POLICYNAME. no cap, they're already cooked for you. 🔥

---

👀 SEE ALSO 👀

• update-crypto-policies(8)

like, go read that one too, fr fr. 💜

---

✍️ AUTHOR ✍️

Written by Tomáš Mráz. absolute icon, we stan. 🌈⭐

---

and that's a wrap on CRYPTO-POLICIES(7), bestie!! 🎉 from the crypto-policies package, dated 09/30/2026 — go forth and vibe-check your ciphers responsibly, mwah 💋💖