Update to document NSA's CSNA 2.0 recommendations

    - TLS_AES_256_GCM_SHA384

    - TLS_AES_128_GCM_SHA256

  - In regards to coding practices, refer to the [secure coding guidelines](https://docs.gitlab.com/ee/development/secure_coding_guidelines.html#general-recommendations), in particular for language-specific guidelines as well as limitations.

  - [ML-KEM](https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.203.pdf) is a NIST-approved quantum safe algorithm. Specifically ML-KEM-768 is recommended. Just note that ML-KEM can only be used in a FIPS environment if it is using a FIPS-certified cryptographic module. For more information see [this section](#quantum-cryptography).

  - [ML-KEM](https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.203.pdf) is a NIST-approved quantum safe algorithm. Specifically ML-KEM-1024 is recommended. Just note that ML-KEM can only be used in a FIPS environment if it is using a FIPS-certified cryptographic module. For more information see [this section](#quantum-cryptography).

- **Block Ciphers** - [AES](https://en.wikipedia.org/wiki/Advanced_Encryption_Standard). Currently AES-128 is considered the minimal, but to ensure "future proofing" AES-256 is preferred (note there are potential performance impacts depending upon application usage, etc). [GCM](https://en.wikipedia.org/wiki/Galois/Counter_Mode) is the required mode (e.g. `aes-256-gcm`).

  - *It should be noted that AES-256 is considered [quantum resistant](#quantum-cryptography) while AES-128 is not, which is also another consideration for future proofing.*

  - Per [SP 800-131A Rev.3](https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-131Ar3.ipd.pdf) AES-ECB mode is not to be used at all. Use AEAD modes such as AES‑GCM (or AES‑CCM / AES‑KW / AES‑KWP where appropriate).

  - NOTE for Laptops: For full-disk encryption XTS-AES-128 (with 256 bit key) or XTS-AES-256 (with 512 bit key) is acceptable. For both GitLab-approved laptop scenarios for team members (Apple running MacOS or a Linux-based laptop running Ubuntu) one of these two algorithms is automatically pre-chosen and is acceptable when setting up full disk encryption on a laptop.

- **Digital Signatures** - [RSA](https://en.wikipedia.org/wiki/RSA_(cryptosystem)), [ECDSA](https://en.wikipedia.org/wiki/Elliptic_Curve_Digital_Signature_Algorithm), and [EdDSA](https://en.wikipedia.org/wiki/EdDSA#Ed25519). For RSA, the minimum key size is 2048. For ECDSA the minimum key size is 256. Ed25519 and Ed448 are now both approved algorithms if the underlying crypto module has included it in its certification, *however at this time our OpenSSL implementation does not certify it*. For new implementations using ECDSA, ECC keys MUST be ≥256 bits (e.g., P‑256, P‑384). Curves with order length <256 bits (e.g., P‑224) are considered legacy only and MUST NOT be used for new digital signatures.

  - [ML-DSA](https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.204.pdf) is a NIST-approved quantum safe algorithm. Specifically ML-DSA-65 with a random seed of 256 bits is recommended. Just note that ML-DSA can only be used in a FIPS environment if it is using a FIPS-certified cryptographic module. For more information see [this section](#quantum-cryptography).

  - [ML-DSA](https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.204.pdf) is a NIST-approved quantum safe algorithm. Specifically ML-DSA-87 with a random seed of 256 bits is recommended. Just note that ML-DSA can only be used in a FIPS environment if it is using a FIPS-certified cryptographic module. For more information see [this section](#quantum-cryptography).

  - [SLH-DSA](https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.205.pdf) is a NIST-approved quantum safe algorithm. SLH-DSA's strength lies in functioning as a replacement of digital signatures based only on known-strong hash function design. It replaces stateful hash-based signatures such as LMS and XMSS with a probabilistic construction and does not rely on math such as discrete log or lattices. Just note that SLH-DSA can only be used in a FIPS environment if it is using a FIPS-certified cryptographic module. For more information see [this section](#quantum-cryptography). Generally **ML-DSA is preferred** to SLH-DSA except for applications with a long time-horizon or tight hardware constraints (such as embedded contexts).

- **Hash Functions** - The SHA-2 family of hash algorithm, with SHA-256 as the minimum. Ideally SHA-384 or higher would be better, although there might be less support particularly in third party software.

  - *It should be noted that while SHA-1 is FIPS 140-2 compliant, per [NIST SP 800-53 Rev 5 Baselines](https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final) it is not allowed.* This is per [SP-800-57](https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-57pt1r5.pdf) section 5.6.1.2, [SP-800-131](https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-131Ar2.pdf) section 9 table 8, and [SP-800-107](https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-107r1.pdf) section 4.

- As new quantum resistant algorithms are included in operating system libraries and are certified in FIPS environments, the [standards](#algorithmic-standards) listed above will be updated.

- GitLab will begin testing these algorithms (ML-KEM, ML-DSA, and SLH-DSA) to ensure that we will be able to migrate to their implementation as more adoption occurs. The testing will begin when quantum-supporting versions of the OpenSSL Cryptographic Module, the Linux Kernel Crypto API Cryptographic Module, and the Libgcrypt Cryptographic Module have been added to base operating systems (for example Ubuntu Server LTS and RHEL) which are a part of our underlying infrastructure.

- As of August 13, 2024 NIST published the final versions of [FIPS 203](https://csrc.nist.gov/pubs/fips/203/final), [FIPS 204](https://csrc.nist.gov/pubs/fips/204/final), and [FIPS 205](https://csrc.nist.gov/pubs/fips/205/final). Currently the quantum safe algorithms referenced in these standards are approved for use. Ensure that any use of these algorithms in a FIPS environment are using FIPS certified cryptographic modules. Quantum safe cryptographic modules do exist (such as [liboqs](https://openquantumsafe.org/liboqs/) and [OpenSSL 3.5.0](https://openssl-library.org/post/2025-04-08-openssl-35-final-release/)), but as of April 2026 none of the existing quantum safe cryptographic modules are FIPS certified.

- Hybrid solutions exist for quantum algorithms in some cases, but GitLab will strongly prefer pure quantum algorithmic deployment over hybrid solutions.

- The parameters GitLab will support for quantum algorithms include those listed in Commercial National Security Algorithm Suite (CNSA) [version 2.0](https://media.defense.gov/2025/May/30/2003728741/-1/-1/0/CSA_CNSA_2.0_ALGORITHMS.PDF). A summary can be found [here](https://en.wikipedia.org/wiki/Commercial_National_Security_Algorithm_Suite#CNSA_2.0), and these are noted in the references to parameters in the algorithm standards mentioned [above](#algorithmic-standards).

- Hybrid solutions exist for quantum algorithms in some cases, but GitLab will strongly prefer pure quantum algorithmic deployment over hybrid solutions to ensure full FIPS and FedRAMP compliance.

- Not all variations of configurations will be tested in certain specific scenarios. For example in a standalone instance of GitLab there are currently no plans for extensive testing of every possible SSL configuration, as configuration options (like all optional features) will be up to GitLab customers' standards and needs.

- As the modules that support PQC become a part of Linux images that GitLab has historically used and will continue to use, the PQC-aware cryptographic modules will be tested as part of the standard process for validating new stable Linux images. PQC algorithms will eventually become a part of the available configuration options. An official roadmap will be developed once these PQC-enabled Linux images become available.

- Specific testing for FedRAMP images using PQC settings will occur when FIPS-certified Linux images with PQC modules become available.