Skip to content

Expose AES-XTS (aes-128-xts / aes-256-xts) through the provider #433

Description

@MarkAtwood

Request: register AES-XTS cipher implementations (aes-128-xts, aes-256-xts) in wolfProvider.

wolfProvider 1.2.0 registers no XTS glue, so any EVP consumer fetching XTS fails under a wolfProvider-only configuration. With the default provider deliberately not activated (fail-loud FIPS-style deployments), that failure is correct behavior — but it blocks real workloads:

  • Ceph librbd image encryption hardcodes AES-128/256-XTS via EVP_get_cipherbyname (src/librbd/crypto/Utils.cc); an encryption-formatted RBD image cannot be opened by a QEMU/librbd client running under wolfProvider.
  • Disk-encryption tooling generally standardizes on XTS for block storage, so this recurs for any at-rest use case driven through EVP.

wolfCrypt already implements XTS (wc_AesXtsEncrypt/wc_AesXtsDecrypt); this is provider glue, not new crypto. FIPS module scope for XTS is a separate (cert) matter — the provider exposure is needed regardless so non-FIPS/eval builds work today and the path is ready if/when cert scope covers it.

Observed on: wolfProvider 1.2.0, OpenSSL 3.0.13 and 3.5, wolfSSL 5.9.1.
Repro: OPENSSL_CONF activating only libwolfprov + base, then
openssl enc -aes-256-xts ... or any EVP_CIPHER_fetch(NULL, "AES-256-XTS", NULL) → fetch fails.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Fields

    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions