Revision as of 15:02, 4 May 2026

PQC Migration Pop-up Team

Status: Governance patch under TC review (Gerrit #982062)

Co-leads: Maurício Harley (mharley), Jean-Philippe Jung (jjung)

TC Liaison: Maurício Harley (mharley)

IRC: #openstack-pqc-migration (OFTC)

Mailing list tag: [pqc]

Gerrit topic prefix: pqc-migration

Etherpad: https://etherpad.opendev.org/p/openstack-pqc-migration

Scope and Approach

The PQC Migration Pop-up Team coordinates the transition of OpenStack's cryptographic infrastructure to post-quantum algorithms standardized by NIST:

• ML-KEM (FIPS 203) - key encapsulation, replacing ECDH/X25519
• ML-DSA (FIPS 204) - digital signatures, replacing RSA/ECDSA/Ed25519

Guiding Principles

1. Opt-in and backward-compatible. PQC algorithm support is added alongside classical algorithms. Operators adopt at their own pace. Existing deployments are not broken.
2. No custom cryptography. OpenStack does not implement crypto. It relies on platform libraries (OpenSSL, pyca/cryptography, PyJWT). Our job is to remove barriers and expose configuration.
3. Crypto agility over crypto replacement. Algorithm choices should be configurable, not hardcoded. This future-proofs OpenStack against any algorithm transition, not just PQC.

Concrete Steps

1. Per-project cryptographic inventory - structured assessment covering in-transit channels, at-rest data, signing/identity, library dependencies, and confidentiality horizons.
2. Assessment guide - methodology for project teams to evaluate their own repositories.
3. Reference implementation in Barbican - ML-DSA and ML-KEM as supported key types in the generation and storage pipeline.
4. Community Goal evaluation - based on inventory results, determine whether a formal community goal is warranted.

Assessment Guide

What to Look For

Severity Classification

HNDL Severity Modifier

Data requiring 10+ years of confidentiality (Barbican secrets, CA certificates, long-lived signing keys) faces Harvest Now, Decrypt Later risk. For these, increase severity by one level (e.g., HIGH becomes CRITICAL).

Ephemeral data (Fernet tokens, session keys, cache entries) does not need this adjustment.

Policy Decisions

These questions were raised by Ghanshyam Maan on the mailing list and represent key policy choices for the Pop-up Team:

1. Should OpenStack reject quantum-risk code, even when user-configurable?

No. The migration should be opt-in and backward-compatible. Operators must be able to adopt PQC at their own pace. The goal is to make PQC possible, not to break existing deployments.

2. Should OpenStack be quantum-resistant but still accept classical algorithms?

Yes. Add PQC algorithm support alongside classical algorithms. Default to the most secure option available, but allow fallback. This aligns with how the TLS ecosystem handles the transition (hybrid key exchange combines X25519 + ML-KEM-768, not ML-KEM-only).

3. What about dependencies (OpenSSL, OpenSSH)?

OpenSSL 3.5 already ships ML-KEM and ML-DSA with hybrid TLS key exchange (X25519MLKEM768) as a default group. Python services on platforms with OpenSSL 3.5 will negotiate PQC-hybrid TLS automatically if the application code does not block it. Many findings are exactly of this nature - code that restricts protocol versions or does not configure key exchange groups. The upstream work is less about implementing crypto and more about removing barriers and ensuring crypto agility.

Per-Project Cryptographic Inventory

This table summarizes the PQC-relevant findings across upstream OpenStack projects. "Code Change Needed" indicates whether the project's own code must be modified; "Platform Resolves" indicates whether upgrading the underlying platform (OpenSSL 3.5, cert-manager, PyJWT) resolves the finding without code changes.

Summary

• 20 upstream projects have PQC-relevant findings across the OpenStack ecosystem.
• CRITICAL findings concentrate in 4 areas: key generation (Barbican, Castellan, Octavia, Ironic IPA, MariaDB operator), token signing (Keystone JWS), keypair generation (Nova, python-openstackclient), and TLS cert validation bypass (Designate, Cinder vendor drivers, infra-operator).
• Many HIGH findings require no code change - they resolve when the platform (OpenSSL 3.5, cert-manager, Go 1.24+) is upgraded or when deprecated modules (oslo.service sslutils) are removed.
• The projects requiring the most active code changes are: Barbican, Keystone, Octavia, openstacksdk, and oslo.messaging.
• Upstream patches submitted: Barbican SimpleCrypto crypto-agility (#985080) and Keystone JWS configurable algorithm (#985081) are under review.

Key References

• NIST FIPS 203 - ML-KEM
• NIST FIPS 204 - ML-DSA
• NIST FIPS 205 - SLH-DSA
• NIST CSWP 39 - Crypto Agility
• IETF - Hybrid PQC Key Exchange in TLS 1.3
• Mailing list discussion
• Governance patch - Pop-up Team proposal

Starting Point

The reason to support quantum safe algorithms in OpenStack is to ensure OpenStack remains relevant as a cloud infrastructure product as the regulation moves toward requiering quantum-safe support. You can get an up to date list of countries with requirements at https://www.gsma.com/newsroom/post-quantum-government-initiatives-by-country-and-region/

Regarding OpenStack, here is everything cryptography that is allowed: https://opendev.org/openstack/requirements/src/branch/master/global-requirements.txt

For sure, cryptography.io is the recommended lib for everything and there were efforts to replace previous libs with it, but we will probably want to audit the repos we ship to find out the current status. e.g., pyOpenSSL is allowed, but I am not sure if any repos are currently using it or whether it was allowed before cryptography was added.

Relevant libs I found at first glance:

• bcrypt
• dogtag-pki
• hvac
• oauthlib
• paramiko
• passlib
• pyOpenSSL

As I wanted a deeper analysis, to get as grasp of the overall problem, I used different AI engines (Gemini, ChatGPT 5 deep) to get an initial overview of crypto in OpenStack upstream (might be missing some, AI engines can be wrong).

Gemini provided

Based on the global-requirements.txt file for OpenStack, the following cryptography-related libraries are required:

General Requirements

• bcrypt==4.0.1: A password-hashing function based on the Blowfish cipher designed to be slow to resist brute-force attacks.
• cffi: A library for calling C code from Python, providing a Foreign Function Interface. Note: This is not necessarily security/cryptography related, but could be used to load some relevant C libraries
• cryptography!=2.0: A package providing high-level recipes and low-level primitives for various cryptographic algorithms.
• hvac: A Python client for the HashiCorp Vault API, used for managing secrets.
• XStatic-JSEncrypt: A package that provides the JSEncrypt JavaScript library for RSA encryption in web applications.
• paramiko!=2.9.0,!=2.9.1: A Python implementation of the SSHv2 protocol for secure remote connections and file transfers.
• passlib: A comprehensive password hashing library supporting over 30 different hash algorithms.
• pyasn1!=0.2.3: A pure-Python implementation of ASN.1 types and codecs for data serialization.
• pyasn1-modules: A collection of ASN.1 data structures for various protocols, for use with the pyasn1 library.
• PyJWT: A library for encoding and decoding JSON Web Tokens (JWT), commonly used for authentication.
• pykmip: A Python implementation of the Key Management Interoperability Protocol (KMIP) for managing cryptographic objects.
• pyOpenSSL: A Python wrapper for the OpenSSL library, enabling SSL/TLS functionality.
• pysaml2: A pure Python implementation of the SAML 2.0 standard for exchanging authentication and authorization data.
• pysnmp-lextudio: A fork of the PySNMP library due to the maintainer's passing, providing a pure-Python implementation of the SNMP engine. This project has obtained the pysnmp namespace on PyPi.
• python-gnupg: A Python wrapper for GnuPG (GPG) to manage keys, encrypt/decrypt data, and sign/verify messages.
• scrypt!=0.8.21: Python bindings for the scrypt key derivation function, designed for secure password hashing.
• sshtunnel: A library for creating and managing SSH tunnels from within a Python application.

That was more than we expected, so we checked for the libraries' maintenance status (see next page). It doesn't specify usage or frequency, but ultimately, everything must be updated for PQC support or replaced with libraries that provide it.

There is a probability that the initial PQC algorithms might fail short and be replaced. Thus this PQC support exercise should also be a "cryptographic agility" exercise, meaning we have few libraries, we know how they are called, and if new crypto algo come out, it is easy to enable them in the code.

17 libraries, 7 with no commit in 2+ years

Cryptographic Libraries in some core OpenStack Projects – ChatGPT 5

Executive Summary

This report surveys the cryptographic libraries and mechanisms in the OpenStack projects commonly supported: Keystone, Nova, Glance, Neutron, Swift, Barbican, Octavia, and Horizon. Across these, the primary Python cryptography stack relies on the 'cryptography' library (pyca/cryptography), with additional use of pyOpenSSL, passlib/bcrypt for password hashing, and HMAC, TLS, and PKCS#11 integrations as appropriate. Where possible, links are provided inline as (link).

In summary, every major OpenStack service employs cryptographic libraries either directly in its implementation or via dependent components. The PyCA Cryptography library is a common thread, providing the foundation for encryption (AES, RSA, etc.), hashing, and X.509 across Keystone, Glance, Octavia, Barbican, and more. Python's standard `hashlib` and `hmac` cover many simpler needs (like computing checksums or signatures) in services like Nova, Neutron, and Swift. When it comes to TLS, OpenStack services typically rely on the system OpenSSL (exposed via Python's `ssl` module or `requests` library) rather than implementing TLS algorithms in Python. And for key management at scale, OpenStack defers to Barbican, which itself uses strong cryptographic protection (AES-256, HMAC-SHA256, RSA) for secrets in transit and at rest.

Platform-Wide Dependencies

OpenStack global requirements include 'cryptography' and 'pyOpenSSL' among accepted libraries. (global-requirements.txt)

OpenStack security guidance recommends strong, widely adopted crypto libraries (cryptography, pyOpenSSL, passlib). (security guidelines)

Keystone (Identity)

Supports TOTP for MFA via a dedicated auth plugin. TOTP plugin

Password hashing supports bcrypt, pbkdf2_sha512, scrypt; 2024.1 adds bcrypt_sha256. release notes password hashers API

Fernet token format uses symmetric encryption and signing with key rotation. Fernet FAQ

Nova (Compute)

Generates SSH keypairs using Paramiko (moved away from shelling out to ssh-keygen). (link) (link)

Supports validation of Glance image signatures and certificate trust when booting signed images. (link)

Metadata path protection with Neutron uses HMAC over Instance-ID to prevent spoofing (shared secret). (link)

Glance (Image)

Supports image signing and signature verification using asymmetric cryptography; integrates with Barbican for certificate storage. (link)

Neutron (Networking)

Neutron metadata proxy signs the Instance-ID header with HMAC using a shared secret; Nova verifies it. (link) (link)

Swift (Object Storage)

Optional at-rest object encryption implemented by Swift middleware (transparent to clients). (link)

Barbican (Key Manager)

PKCS#11 crypto plugin supports HSM-backed keys (MKEK/HMAC in HSM; KEKs per project). (link) (link)

Simple Crypto plugin (software) wraps project keys with a master KEK stored in configuration (for non-HSM deployments). (link) (link)

Octavia (Load Balancer)

Uses PKCS#12 bundles and pyca/cryptography for certificate/key handling; Barbican integration supported. (link) (link) (link)

Horizon (Dashboard)

Relies on Django cryptographic primitives; SECRET_KEY must be strong and shared across instances; secure cookies/CSRF recommended. (link) (link)

oslo.utils (Cross-Project)

Provides FIPS-aware helpers; e.g., secretutils.md5(..., usedforsecurity=False) for non-security MD5 use. (link) (link)

References

OpenStack global requirements (includes cryptography, pyOpenSSL) (link)

Security guideline: Use Strong and Established Cryptographic Elements (link)

Keystone TOTP auth plugin (link)

Keystone password hashers & bcrypt_sha256 release notes (link)

Keystone password hashers API index (link)

Fernet token FAQ (link)

Nova: replace ssh exec calls with Paramiko (keypair generation) (link)

Nova: image certificate validation (link)

Nova/Neutron metadata service (HMAC over Instance-ID) (link)

Glance: image signature verification (link)

Swift: object encryption (link)

Barbican: PKCS#11 crypto plugin (link)

Barbican: Choosing a backend (RHOSP docs) (link)

Barbican: Simple Crypto plugin (pike docs) (link)

Octavia: PKCS#12 helper (pyca/cryptography) (link)

Octavia: Barbican certificate manager (source) (link)

Octavia: Switch to PKCS#12 commit (link)

Horizon: SECRET_KEY guidance (link)

Horizon: Cookies (CSRF/session) hardening (link)

oslo.utils secretutils MD5 wrapper (link)

oslo.utils release notes on usedforsecurity (link)

RHEL 9: Switching to FIPS mode (link)

Overview of Cryptographic Libraries and Their Roles

OpenStack projects rely on a variety of cryptographic libraries (both Python standard libraries and external packages) to implement security features such as TLS encryption, digital signatures, key management, hashing, and authentication tokens. Below is a summary of the key cryptographic libraries and their purposes across some core supported components OpenStack:

- PyCA Cryptography (`cryptography` library) – A widely used library providing cryptographic primitives (hash algorithms, ciphers, X.509, etc.). It underpins many security features such as token encryption (fernet tokens), password hashing (PBKDF2), TLS certificate generation, image signature verification, and more. Most OpenStack services include this as a direct or transitive dependency (it is in OpenStack's global requirements) to perform encryption/decryption, digital signature verification, and cryptographic key operations.

- PyOpenSSL – A Python interface to OpenSSL, historically used for TLS and X.509 in some components. In current stable branches, many uses have transitioned to the `cryptography` library for higher-level operations. However, PyOpenSSL may still appear as a dependency for some services (often via `requests[security]` extras) but is generally being phased out in favor of `cryptography`.

- Hashlib and HMAC (Python standard library) – Used for hashing and message authentication. Many services use `hashlib` for computing digests (e.g. MD5 or SHA hashes for file integrity or unique identifiers) and `hmac` for creating secure tokens or signatures. For example, OpenStack's metadata service and Swift temporary URLs use HMAC-SHA signatures for authentication, and historically MD5 was used for checksums (with FIPS-compliant replacements now in place). The Oslo utility module `oslo_utils.secretutils` wraps hashlib to handle FIPS mode (e.g. allowing MD5 for non-security contexts).

- Paramiko – A Python SSHv2 library used by services that need SSH functionality. Paramiko depends on `cryptography` for its crypto (RSA, ECC keys, etc.) and is utilized in Nova and other projects for tasks like key pair generation and secure SSH communication. For instance, Nova uses Paramiko to generate SSH key pairs and fingerprints for injected key pairs, instead of shelling out to `ssh-keygen`. Tempest (the test suite) also uses Paramiko for SSHing into test instances.

- Bcrypt – Used for secure password hashing in Identity service (Keystone). Keystone supports hashing user passwords with bcrypt; a recent addition is `bcrypt_sha256`, which hashes the password with HMAC-SHA256 before applying bcrypt, to mitigate bcrypt's length limitation. The `bcrypt` library is leveraged to store passwords in a non-reversible secure form (instead of older schemes like SHA1 or MD5).

- OSLO Cryptography Wrappers – Several Oslo libraries provide abstractions or utilities for crypto. For example, Keystone and other projects use Castellan (Key Manager interface) to abstract secret storage and retrieval (e.g. integration with Barbican). Oslo Messaging can enable TLS for RPC, using OpenSSL via Proton or Kombu. OsloUtils provides `secretutils.md5()` (FIPS-compliant MD5) and time-based one-time password utilities. These higher-level utilities ultimately rely on the fundamental libraries mentioned above.

In the context of FIPS 140-3 support, many projects have been updated to use approved algorithms. Weak algorithms like MD5 are only used in non-security contexts or with special flags. Components like Keystone, Nova, and Swift have replaced or augmented old uses of MD5 and other weak hashes to be FIPS-compliant (e.g. using SHA-256 or using the `usedforsecurity=False` flag when MD5 is needed for benign purposes).

Below we provide a project-by-project breakdown of cryptographic libraries in use and their specific purposes in the current stable branch of each upstream OpenStack project of some core components. This includes both direct usage in the project's code and notable transitive dependencies that provide cryptographic functionality.

Cryptographic Libraries by Project (Appendix)

Aodh (Telemetry Alarming)

- hashlib/HMAC (std library) – Aodh may use hashing for generating alarm IDs or signatures for alarm notifications. However, it has no significant custom crypto; it relies on underlying services for security (uses Keystone for auth). - TLS/ssl – Communication to other services can be secured via TLS (using Python's `ssl` module or requests). No direct inclusion of external crypto libraries in Aodh's codebase was found.

Barbican (Key Manager)

- cryptography – Barbican's core function is managing secrets, and it uses cryptography for encryption and decryption of secret data when using software plugins. The default "simple_crypto" plugin encrypts all secrets with a single AES-256 key (Key Encryption Key) stored in config. This is implemented via cryptography (AES algorithm from PyCA library). - PyOpenSSL/PKCS11 libraries – In HSM mode, Barbican uses a PKCS#11 library to interface with Hardware Security Modules. The PKCS#11 plugin still utilizes cryptographic operations (encrypting project-specific KEKs, etc.) on the HSM side. Barbican itself doesn't perform those encryptions in software, but it manages keys/certificates via drivers. - Castellan interface – Barbican provides the Castellan key manager API to other services. Castellan itself uses cryptography under the hood (e.g. to generate keys or parse certificates) if needed. Barbican can store X.509 certificates and keys; it uses cryptography's X.509 support to parse certificates when storing or retrieving them (e.g. loading PEM certificates). - hashlib – Barbican may use hashing for key wrapping or for integrity checks. For example, the PKCS#11 plugin involves HMAC-signing of keys (HSM stores a master HMAC key for signing keys). In simple crypto mode, an HMAC is not explicitly used – just symmetric encryption.

Ceilometer (Telemetry Data Collection)

- hashlib – Used to compute digests or unique IDs for metering data. For instance, Ceilometer may hash resource or meter identifiers for storage efficiency (no security context). - HMAC (for messaging) – If Ceilometer signs messages sent over RabbitMQ, it would use Oslo Messaging's signing (which could use HMAC-SHA). However, by default it likely relies on TLS at the transport level rather than signing message payloads. - ssl/TLS – Ceilometer can be configured to use TLS to connect to message brokers or other APIs. This leverages Python's `ssl` module (or requests/urllib3 with OpenSSL) rather than Ceilometer-specific code.

Cinder (Block Storage)

- Castellan/Barbican (cryptography via Barbican) – Cinder supports volume encryption. It does not itself encrypt volumes, but it generates volume encryption keys and stores them in Barbican (Key Manager). Cinder uses the Castellan API to fetch keys. When Barbican is not used, Cinder had a fallback "fixed key" in config (for testing) – but in current releases this is deprecated in favor of Barbican. Thus, cryptography is used indirectly via Barbican for key creation (Barbican uses AES). - oslo_utils.hashlib – Cinder may use hashing for purposes like verifying backup data integrity or naming (e.g., computing a hash of volume IDs for filepaths). For example, it could use MD5/SHA-256 to create unique filenames or compare checksums of backup segments. - ssl/TLS – Cinder can communicate with back-end storage or internode RPC over TLS. This uses the standard libraries (ssl or requests). No direct use of `cryptography` in Cinder's own code, aside from its use of Castellan.

Designate (DNS Service)

- HMAC-MD5 / HMAC-SHA – Designate uses TSIG keys for DNS server updates and zone transfers. TSIG (Transaction Signatures) are HMACs (often HMAC-MD5 or SHA1) used to authenticate DNS messages. Designate's backend integration with Bind or PowerDNS can use TSIG keys configured for zone transfers. The Designate code leverages the dnspython library (a dependency) which implements TSIG signing using Python's `hmac` and `hashlib` (MD5, SHA algorithms). - cryptography (indirect via dnspython) – If DNSSEC support is enabled (signing zones or validating records), dnspython and underlying libraries would use cryptographic routines (RSA/ECDSA for DNSSEC signatures). However, Designate typically delegates DNSSEC to the nameserver. - ssl/TLS – Designate's API can be run under TLS (using eventlet's SSL support or Apache with mod_ssl). It doesn't itself perform crypto beyond possibly verifying connections to backends if using DNS over TLS (not common in OpenStack context).

Glance (Image Service)

- cryptography – Glance uses the cryptography library for image signature verification. Glance can verify digital signatures on images uploaded by users. If an image is accompanied by a signature and signer's certificate, Glance will fetch the certificate from Barbican (via Castellan) and use cryptography to verify the image data against the signature. This involves hashing the image data (SHA-224/256/384/512, as specified by image property) and using the public key (RSA or ECC) to verify the signature. The `cryptography.hazmat` modules are used for loading X.509 certificates and performing the verification (e.g. RSA-PSS, DSA, ECDSA as per the `img_signature_key_type` property). - hashlib – Used to compute the image's checksum (Glance always computes an MD5 checksum by default for each image for integrity). For signing, the same checksum or a stronger hash is used as the message digest that gets signed. (Glance has added support to configure a stronger hash algorithm for image signing to move away from MD5.) In current branches, operators can choose a secure hash (the properties `img_signature_hash_method` and `img_signature` are used). - Castellan/Barbican – Not a cryptographic library per se, but Glance interacts with Barbican to retrieve certificates or keys for signature verification. Barbican's client (and thus cryptography) is used to load the X.509 certificate stored, but Glance itself uses cryptography to perform the math of signature checking. - ssl/TLS – Glance API can be served over TLS. It relies on the web server or eventlet's `ssl` module.

Gnocchi (Telemetry Time-Series Database) and Panko (Event Storage)

- hashlib – Gnocchi and Panko primarily handle metrics and event data. They may use hashing for generating metric IDs (Gnocchi, for example, hashes resource and metric names into UUIDs). This is done with SHA-1 or MD5 in older versions, but could use a configurable hash. It's not used for security, only as an identifier. - ssl/TLS – Both services can be accessed via HTTPS (so use underlying TLS support). There is no direct cryptography library usage in normal operations; they rely on Keystone for auth and do not manage secrets themselves. - cryptography (transitive) – If these services use oslo.messaging with authentication or connect to Ceph with encryption, the underlying libraries might invoke cryptographic routines (e.g., Ceph's RADOS library uses OpenSSL). But Gnocchi/Panko code does not implement crypto functions directly.

Heat (Orchestration)

- cryptography / oslo.crypto – Heat may encrypt certain stored data, such as user credentials for software deployments. It has a feature to encrypt sensitive parameters in the stack definition (using a cryptographic key). This likely utilizes Castellan or the oslo.crypto library to encrypt/decrypt data. For example, Heat can integrate with Barbican to store TLS certificates or keys for deployed servers. - hashlib – Used for hashing resource names or generating uniform random IDs. No known heavy cryptography in Heat itself. - ssl/TLS – Heat's cloudformation-compatible API and Heat engine communications can be TLS-protected. Uses standard `ssl` configurations.

Horizon (Dashboard)

- hashlib/HMAC – Horizon (a Django web app) uses Django's security mechanisms for password hashing and session/cookie signing. Django by default uses PBKDF2 (SHA256) or bcrypt for hashing passwords, and HMAC-SHA1 or SHA256 for signed cookies. These are via Python's stdlib (`hashlib` and `hmac`), configured through Django settings. The actual algorithms (e.g., PBKDF2 with SHA256) are FIPS-compliant. - ssl/TLS – Horizon is typically served via HTTPS (e.g., Apache + mod_ssl). Horizon itself doesn't implement TLS; that's handled by the web server. It will trust system CAs when making requests to OpenStack APIs. - cryptography (indirect) – If Horizon uses OpenStack clients (e.g., to make API calls), those clients use Keystone (which may verify tokens with cryptography in Keystoneauth for fernet tokens) and requests for TLS. Horizon's two-factor auth options (e.g., TOTP) rely on Keystone for validation. Horizon does not call cryptographic libraries like `cryptography` directly in its code.

Ironic (Bare Metal Provisioning)

- ssl/TLS:

– Ironic presents an RESTful API endpoint for use and management which is expected to behind TLS.
– Ironic's Agent, used to perform actions also operates a short lived TLS certificate, which is accessible under recommended configurations only by Ironic.
– Ironic utilizes SSL/TLS to communicate with Redfish BMCs. Other BMCs may be using other protocols or security settings which may not be advised, but also generally BMCs devices lag behind operating system best practices when it comes to Security. For example, some vendors have refused to upgrade Cipers in the past.
– Presently, all HTTPS requests under Ironic's direct control utilize the python-requests library; this relies on OpenSSL for TLS verification. 

– What the AI summary got wrong: Ironic can be configured with TLS for its API and uses TLS for PXE boot (via hardened protocols), but these use external components (like stunnel or nginx) rather than Ironic's own crypto. - This is incorrect. While an operator *can* attempt to build their own bootloader binaries with certificte details and protect artifact transport, that is outside of Ironic's scope. We pass-through the settings only.

- hashlib:

– Ironic utilizes hashlib for hashing some values in memory which need to be be used to track sessions and validate the checksums of files. Ironic supports SHA512, SHA256, and MD5 if so enabled by configuration.

- paramiko:

– Ironic has a sub-project, called networking-generic-switch, which utilizes paramiko through the netmiko library to SSH into remote switch devices. Due to the hardware vendor ecosystem space, this library supports some non-ideal algorithms, in large part because vendors often don't have OS firmware updates for hardware still in production or are trailing upstream by a substantial period of time. This is intentionally not exposed to users, but is treated as a back-end operation utilizing values and information set by through introspection processes or system owners already knowing the values.
– What the AI Summary got wrong: Ironic doesn't have paramilo loaded into it directly to enable SSHing to remote hosts. It does have an "ansible" driver which can be enabled by an administrator to facilitate highly customized deployments which might utilize Paramiko.

- cryptography:

– Ironic's Python Aagent, which facilitates deployment and management activities on remote hosts, does utilize the cryptography library to generate short lifetime TLS certificates for the purpose of securing information in transit from Ironic, in terms of commands, urls, and the posted configuration drive contents, from an attacker sniffing the wire during the deployment process.
– What the AI Summary got wrong - This entire statement with the exceptions that operators typically provide certificates for Ironic itself through configuration. -  Ironic does not itself manage keys or certificates in the database. It can integrate with Magnum or Nova for certs (for example, for communications with agent, TLS client certs can be issued – typically using a separate CA managed outside or via Barbican). If Ironic were to generate a self-signed certificate for the IPA (agent) communications, it would likely call OpenSSL or use cryptography, but typically operators provide certs.

- pysnmp-lextudio:

– The AI summary missed this one. Ironic has a snmp driver for managing power on remote power strips for connected hosts. This driver has been deprecated and is expected to be removed in 2026.2, unless someone magically appears and ports the driver the the new asyncio version of pysnmp.

Keystone (Identity Service)

• cryptography – Keystone makes extensive use of the `cryptography` library for token security and identity features:

 - Fernet Tokens: Keystone's default token format is "fernet" (symmetric authenticated tokens). Fernet tokens are essentially AES-128 in CBC mode with HMAC-SHA256 for signing, implemented by the cryptography library. Keystone generates a rotating key repository and uses `cryptography.fernet.Fernet` under the hood to encrypt/decrypt token payloads (e.g., user ID, expiration). The library ensures tokens are both encrypted and signed (for integrity).
 - PKI and JWT: Keystone can issue PKI tokens or JWT tokens for federation. It has utilities for JWT which use `cryptography.hazmat` to generate ECDSA key pairs and sign/verify JWTs. For example, Keystone's `jwt_utils.py` uses `cryptography.hazmat.primitives.asymmetric.ec` to create an EC key (P-256) and uses it for JWT signing. If Keystone is configured for SAML or OIDC federated tokens, it may use XMLSec or jwcrypto, but by default JWT support leverages `cryptography`.
 - Password Hashing: Keystone stores user passwords (for local accounts) using secure hashing. It supports PBKDF2-HMAC-SHA512 by default (via cryptography) and bcrypt. In current stable, Keystone has a pluggable password hashing interface. The `keystone.common.password_hashers.pbkdf2` module uses `cryptography.hazmat.primitives.kdf.pbkdf2.PBKDF2HMAC` to hash passwords with SHA-512. Keystone recently added support for `bcrypt_sha256` (which does an HMAC-SHA256 on the password then bcrypt) for stronger security. The `bcrypt` library is therefore a dependency. All these ensure password storage is resistant to brute-force.
 - Two-factor Authentication (TOTP/HOTP): Keystone's OTP plugin uses the `cryptography.hazmat.primitives.twofactor` module for TOTP generation. It decodes a base32 secret and uses `cryptography.hazmat.primitives.twofactor.TOTP` with SHA1 (default algorithm) to generate time-based one-time passwords. This provides two-factor auth codes consistent with Google Authenticator, etc.
 - X.509 Certificates: Keystone can act as a Certificate Authority for signing SSL certificates (used in Keystone-to-Keytone federation or for signing service certificates). In such cases, Keystone uses OpenSSL through `cryptography` to generate keys and X.509 certs. For example, Keystone might create self-signed certificates for securing LDAP connections or for tokens (legacy PKI tokens). It uses `cryptography.x509` for certificate creation and signing in these scenarios.

• PyOpenSSL – Not directly used by Keystone in current code (previously was for certificate handling, but now replaced by cryptography). Keystone's eventlet server can be run with TLS by specifying cert files, which under the hood uses Python's `ssl` (OpenSSL). Keystone might still depend on PyOpenSSL via `requests` for HTTPS communications (for example, validating HTTPS connections to LDAP or external IdPs).
• HMAC – Keystone uses HMAC in token providers (the Fernet implementation uses HMAC-SHA256 as part of the token format). It also uses HMAC-SHA256 to derive keys in certain cases (e.g., to derive a key from a passphrase for credential encryption).
• Castellan – Keystone can store credentials or secrets (like OAuth1 tokens, trust tokens) using Castellan/Barbican, but typically it stores data in its DB, encrypted or hashed as needed (e.g., OAuth1 secrets hashed with SHA256).

Manila (Shared File Storage)

- Castellan/Barbican – Manila can integrate with Barbican to store security data (e.g., share encryption keys or certificates for secure NFS). If Manila's driver supports encrypted file shares, it might generate a key and use Barbican to store it. The cryptography operations (key generation, encryption) would then be handled by Barbican or the storage backend. - hashlib – Manila may use hashes for unique identifiers or to hash secret information before logging. Notably, when Manila uses CephFS with TLS or other secure channels, keys are managed externally. - ssl/TLS – Manila's protocol access (e.g., mounting NFS or CIFS) can be secured. For instance, Manila supports TLS for its RPC or API and can manage certificates (it may pass certificates to back-end storage systems). It doesn't perform cryptography itself beyond possibly packaging certificates/keys from Barbican.

Neutron (Networking)

- hashlib/HMAC – Neutron uses HMAC for its metadata proxy service. Neutron's DHCP/Metadata agent adds an X-Instance-ID-Signature header to metadata requests, which is an HMAC-SHA256 of the instance ID using a shared secret. Nova computes the same to validate the request. This prevents spoofing of instance metadata calls. The implementation uses Python's `hmac` library with SHA-256. - OpenSSL (via Open vSwitch and StrongSwan) – Neutron implements VPN-as-a-Service (using strongSwan or LibreSwan for IPsec) and SSL VPN (via OpenVPN). While Neutron orchestrates these, the cryptographic operations are done by those services (which use OpenSSL for IPsec, etc.). Neutron passes keys and certs (which may be stored in Barbican) to these services. For example, IPsec site-to-site VPN can store pre-shared keys or certificates in Barbican; Neutron will retrieve them and configure the VPN service. - cryptography – Not typically imported in Neutron code. One exception might be if Neutron utilizes TLS for certain backends (e.g., OpenDaylight controller HTTPS, or etcd TLS in OVN). In such cases it uses `ssl`/`requests`. Neutron's ML2 drivers don't perform cryptographic calculations themselves. - ssl/TLS – Neutron API and agents can be configured with TLS. RPC communication over RabbitMQ can be secured by TLS (OpenSSL used via kombu). Neutron LBaaS (if using Octavia) defers crypto to Octavia.

Nova (Compute)

- Paramiko (Cryptography via Paramiko) – Nova uses Paramiko for SSH-related functions. A key use-case is key pair generation: Nova can create an SSH key pair for users who don't upload one. Instead of calling `ssh-keygen`, Nova uses Paramiko to generate RSA or ECC keys in-memory. Paramiko, which relies on the `cryptography` library, handles the key generation (RSA 2048 by default) and Nova returns the public key to the user. Nova also uses Paramiko to compute SSH public key fingerprints (MD5 by default, displayed as "fingerprint") and to SSH into hypervisors or instances for certain drivers or diagnostics. For example, the VMware driver once used Paramiko to execute commands on ESXi; the SSH compute driver uses it to power on/off hosts. - hashlib – Nova uses hashing for various purposes:

 - Generating file paths or cache keys: Nova hashes image IDs or instance IDs (often with MD5 or SHA1) to create filenames or unique keys. This is typically not security-sensitive. For instance, when storing instance disk metadata, Nova might compute a hash of the instance ID for directory naming.
 - VNC/spice console tokens: the console proxies use a shared secret to sign access tokens (HMAC-MD5 in the past, now HMAC-SHA). These tokens allow secure console access for instances. The signing uses `hmac` with a secret from nova.conf.
 - Metadata service signature: Nova validates the Neutron metadata proxy's HMAC signature using the shared secret. This uses Python `hmac` (SHA-256).
 - Glance image validation: When Nova downloads images, it verifies checksums (MD5 or SHA256) provided by Glance. It computes the image file's hash via hashlib and compares with Glance's checksum.

- ssl/TLS – Nova can be configured for TLS in various channels:

 - Nova API can run under HTTPS (eventlet or Apache mod_wsgi with TLS).
 - NoVNC and Spice console proxies support TLS encryption for console traffic. Nova generates self-signed certificates for the console proxy or uses provided certs. The actual TLS handshake is handled by websockify (which uses Python's `ssl`).
 - Libvirt TLS: Nova can talk to libvirt over TLS for VM management and migrate instances with TLS. This relies on libvirt's own use of TLS (which uses OpenSSL). Nova's configuration will point libvirt to cert files (which an operator would manage, possibly via Barbican or manually). Nova itself doesn't generate or parse these certs (except to pass file paths); libvirt/OpenSSL do the cryptography.
 - Ephemeral disk encryption: Nova can encrypt ephemeral instance disks using LUKS. In that scenario, Nova will obtain a key (from Barbican via Cinder, or a configured fixed key) and format the disk with LUKS. The LUKS encryption is handled by the operating system `cryptsetup` (which uses dm-crypt/AES). Nova's role is to supply the key. If using a fixed key (not recommended), Nova would read it from config (no cryptography, just direct use); if using Barbican, Nova gets the key via Castellan (the cryptography of retrieving is in Barbican).

- cryptography (indirect) – Aside from through Paramiko, Nova indirectly uses cryptography for:

 - Fernet tokens: When validating Keystone tokens (if using fernet), Nova uses keystoneauth which will decrypt/verify tokens using the cryptography library (in Keystoneauth).
 - Serial console authorization: Nova may generate a JWT for console access in some newer implementations, which would use cryptography to sign (if implemented).
 - Image signature verification: Nova can optionally verify Glance image signatures *again* at instance boot time. If enabled, Nova will use the signature and certificate provided via Glance to validate the image file before booting the VM (to ensure no tampering in transit). This would involve Nova calling the `cryptography` library similar to Glance (Nova contains code to do this verification using the same certificate retrieved from Barbican).

- oslo_utils.secretutils – Nova has replaced direct `hashlib.md5()` calls with Oslo's `md5(usedforsecurity=False)` for non-security hashing (like hashing file names). For anything security-related, Nova uses stronger hashes or HMAC-SHA.

Octavia (Load Balancer Service)

- cryptography – Octavia heavily uses the cryptography library for managing TLS certificates used in load balancing:

 - Octavia provisions Amphora (load balancer VMs) with certificates for secure control communication. It has a Local Certificate Authority capability. Octavia's controller can generate a CA certificate and key (or use Barbican to obtain one), then issue Amphora certificates. The LocalCertGenerator in Octavia uses `cryptography.hazmat` to create private keys and CSRs, and to sign certificates (typically using RSA or ECC). In earlier versions this was done with PyOpenSSL; it was switched to use cryptography directly for PKI operations. For example, creating an X.509 cert for an Amphora involves cryptography's `x509` module.
 - For TLS termination on load balancers, Octavia integrates with Barbican to retrieve user-provided certificates (for HTTPS listeners). Octavia stores these TLS secrets in Barbican, but it must convert them to the format needed by the Amphora (e.g., PKCS#12 bundle). Octavia uses `cryptography` to serialize certificates/keys to PKCS#12 format. The code uses `serialization.pkcs12.serialize_key_and_certificates` (from cryptography) to create a PKCS#12 payload before sending to Amphora.
 - Octavia also uses cryptography for parsing and loading certificates and private keys when they are fetched from Barbican. For instance, it calls `x509.load_pem_x509_certificate()` and `serialization.load_pem_private_key()` on the data returned by Barbican, in order to manipulate them (e.g., bundling into PKCS#12 or generating derivatives).
 - In summary, Octavia includes its own small certificate management subsystem: generating CA and end-entity certs, handling CSR signing, and packaging keys – all of which are done with the `cryptography` library.

- PyOpenSSL – Largely replaced by cryptography in Octavia's recent code. Older implementations of Amphora certificate generation used PyOpenSSL; now cryptography is used for new deployments. - hashlib/HMAC – Octavia may use HMAC or hashing in a few ways:

 - Amphora heartbeat messages or authentication tokens might use HMAC for verification (to ensure the Amphora is trusted). For example, a shared secret could be HMACed into heartbeat messages. This is part of control-plane security.
 - When using VRRP for active/standby load balancers, Octavia sets up a VRRP authentication between Amphorae. Keepalived (the VRRP daemon) can use an AH authentication string; typically it's a simple PASS, but if configured, it could use an MD5 auth (older VRRP spec). Usually, Octavia uses a password, not an HMAC, for VRRP. Not a major crypto item.

- ssl/TLS – All communication between Octavia components can be TLS:

 - The REST API can be behind TLS (provided by the hosting web server or proxy).
 - Controller <-> Amphora agent communication is mutually authenticated TLS (this is the aforementioned certificate usage).
 - Listener traffic: The Amphora terminates end-user TLS. It uses OpenSSL in the OS of the Amphora to handle actual TLS handshakes with clients, based on the certs Octavia provided. Octavia's role is to supply the cert material securely.

- Castellan/Barbican – Octavia uses Barbican as the certificate store for user-provided SSL certificates (for listeners) and can optionally use Barbican to store its own generated CA or Amphora certificates. The Barbican client (via Castellan) is invoked, and cryptographic operations (like encryption of secret in Barbican) are handled by Barbican. Octavia's cert manager plugin for Barbican simply passes data to Barbican and retrieves it, then uses cryptography to manipulate if needed.

Opendaylight (SDN Controller) / Networking-ODL

(Opendaylight is an external Java-based SDN controller. It's not an OpenStack project, but listed as RHOSP component. For completeness:) - Opendaylight, being Java-based, uses Java cryptography (BouncyCastle, JCE) for TLS and any encryption. It supports TLS for its REST APIs and uses certificate-based auth for southbound protocols. - OpenStack's interaction (via networking-odl) just uses HTTP(S) – so from Neutron's perspective, the `requests` library handles TLS to the ODL controller. No Python crypto in Neutron for this; ODL itself handles crypto in its Java environment.

• (lajoskatona): networking-odl was a Neutron stadium project, but was retired in Bobcat (2023.2), so Opendaylight is not something we as Openstack have to check from cryptography perspective.
  • https://review.opendev.org/c/openstack/governance/+/884002
  • https://review.opendev.org/c/openstack/networking-odl/+/886752

OpenStack Service Telemetry Framework, Skydive, Rally, Tempest

Service Telemetry Framework (STF) –

This is a collection of telemetry pipelines (collectd, Ceilometer, Gnocchi) often using Red Hat's tooling. Security is largely handled by TLS (e.g., MQTT or AMQP TLS connections). Any crypto libraries used would be those in collectd or messaging clients (OpenSSL for TLS, perhaps libsodium for messaging encryption if used). Within OpenStack services of STF (Ceilometer, Gnocchi, Panko), see those entries above.

Skydive –

Skydive (network traffic analysis tool) is not an OpenStack project, but if included, it uses TLS for its APIs. Being Go-based, it uses Go's crypto libraries. From OpenStack perspective, no direct integration that affects cryptographic libraries.

Rally –

Rally (benchmarking tool) does not provide cryptographic services. It uses OpenStack clients to authenticate (hence using Keystoneauth, which brings in cryptography for token handling). If Rally connects to endpoints via HTTPS, it uses requests/urllib3 for TLS. Rally itself may use paramiko for SSH if it needs to execute setup scripts on nodes as part of benchmarks. Any such usage would rely on the same libraries described (cryptography via paramiko). But there's no unique crypto in Rally code.

Tempest –

Tempest (test suite) similarly uses OpenStack SDK/clients for API calls (hence TLS and token crypto via those libraries) and uses Paramiko to SSH into test instances for validation. Tempest has a plugin (octavia-tempest-plugin) that generates and checks certificates, using `cryptography` to create keys/CSRs for testing Octavia's TLS features. Thus, Tempest indirectly uses cryptography in test code to verify that the services (like Octavia or Barbican) are working correctly. For example, the

octavia-tempest-plugin

uses `cryptography.x509` to generate a self-signed cert and ensure Octavia accepts it. Tempest ensures that when it requests a service to do something cryptographic (e.g., Barbican to store a secret, Octavia to terminate TLS, Keystone to issue tokens), the outcome is correct – often by using the same library to independently validate (like checking a signed token or a certificate content).

Action points

1. Upstream patches in progress:

• Barbican: #985080 - Add crypto-agility to SimpleCrypto asymmetric key generation (under review).
• Keystone: #985081 - Make JWS token signing algorithm configurable (under review).
• Keystone: PBKDF2 iteration count increase from 25,000 to 600,000 (planned).
• oslo.messaging: TLS 1.3 support for RabbitMQ driver (planned).

2. Stop using unmaintained libraries:

• remove passlib from requirements. Keystone dropped use few releases ago. Now only deployment tooling (kolla, osa and deb packaging) are using it.
• remove scrypt from requriements. Currently no OpenStack projects use it
• remove pysnmp-lexstudio from requirements. https://pypi.org/project/pysnmp-lextudio/ states users should switch to `pysnmp` directly. Currently only ironic and virtualdpu seems to be affected
• remove python-gnupg from requirements. Even though the project had a release recently code search has not identified a single project using it.