Repository navigation
aes: add AES-128-XTS and AES-256-XTS - #506
Open
MarkAtwood wants to merge 1 commit into
Open
MarkAtwood wants to merge 1 commit into
MarkAtwood wants to merge 1 commit into
Conversation
OpenSSL applications that fetch AES-XTS get "unsupported" from wolfProvider. Register AES-128-XTS and AES-256-XTS on wolfCrypt's wc_AesXts* API, following OpenSSL's AES-XTS: - the key is the data key followed by the tweak key (32 or 64 bytes) and the IV is the 16-byte tweak; - each update is one data unit using that tweak: at least 16 bytes, with ciphertext stealing for a partial last block, and at most 2^20 blocks (IEEE Std 1619-2018, NIST SP 800-38E); final outputs nothing. Two deliberate differences from OpenSSL's default provider: - equal key halves are rejected for encryption and decryption. The default provider rejects them only for encryption; its FIPS provider and wolfCrypt FIPS builds reject both, so FIPS and non-FIPS builds of wolfProvider behave the same; - a re-init that changes direction without a new key fails, and the context then refuses data, because the key schedule is set up for one direction. In FIPS builds the XTS entries are registered with fips=no rather than fips=yes, so a fetch that asks for fips=yes does not get them. Other algorithms are unchanged. There is no AES-192-XTS, as in OpenSSL. Needs wolfSSL 5.6.6 or later (wc_AesXtsSetKeyNoInit) built with WOLFSSL_AES_XTS. Add test_aes128_xts and test_aes256_xts: IEEE Std 1619-2007 vectors 2 and 15 and NIST CAVP XTSGenAES128/XTSGenAES256 vectors (hex tweak format, including a 200-bit data unit), interop with OpenSSL's default provider for 16 to 1023 bytes (and two data units in one context), and rejection of short input, equal key halves and a direction change without a key.
There was a problem hiding this comment.
🟡 Changes recommended
Context duplication and partial initialization cleanup leave unresolved resource-ownership defects.
2 open findings
What changed in this PR
Adds wolfCrypt-backed AES-XTS support for EVP disk-encryption consumers, addressing #433.
Changes:
- Registers AES-128-XTS and AES-256-XTS with version gating and non-FIPS properties.
- Implements cipher operations and adds vector, interoperability, and rejection tests.
- Updates build integration and documentation.
| File | Description |
|---|---|
| test/unit.h | Declares XTS tests. |
| test/unit.c | Registers XTS tests. |
| test/test_cipher.c | Adds XTS validation and interoperability coverage. |
| src/wp_wolfprov.c | Registers XTS cipher implementations. |
| src/wp_aes_xts.c | Implements AES-XTS provider operations. |
| src/include.am | Adds XTS to Automake sources. |
| README.md | Lists XTS support. |
| include/wolfprovider/settings.h | Gates XTS on wolfSSL support. |
| include/wolfprovider/alg_funcs.h | Adds algorithm names and dispatch declarations. |
| IDE/WINVS/wolfprovider/wolfprovider.vcxproj | Adds XTS to the Windows build. |
🧠 Review effort: Balanced
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
Comment on lines
+95
to
+96
| /* XtsAes is copied by value, as Aes is for the other AES ciphers. */ | ||
| XMEMCPY(dst, src, sizeof(*src)); |
Comment on lines
+568
to
+570
| if ((ctx != NULL) && \ | ||
| (wc_AesXtsInit(&ctx->xts, NULL, INVALID_DEVID) != 0)) { \ | ||
| OPENSSL_free(ctx); \ |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Colton is going to do this, you can take what you want from this
wolfProvider registers no AES-XTS cipher, so with wolfProvider as the default provider any EVP fetch of XTS fails:
Ceph librbd image encryption and other disk-encryption code use AES-XTS through EVP. wolfCrypt already has XTS (
wc_AesXts*); only the provider glue is missing. See #433.This adds AES-128-XTS and AES-256-XTS in a new
src/wp_aes_xts.c, following OpenSSL's AES-XTS: the key is the data key followed by the tweak key, the IV is the 16-byte tweak, and each update is one data unit (16 bytes to 2^20 blocks, ciphertext stealing for a partial last block). Two deliberate differences from the default provider: equal key halves are rejected for decryption too (as OpenSSL's FIPS provider and wolfCrypt FIPS do), and a re-init that changes direction without a new key fails. In FIPS builds the entries are registeredfips=no, so afips=yesfetch does not get them. Gated onWOLFSSL_AES_XTSand wolfSSL 5.6.6+ (wc_AesXtsSetKeyNoInit).New unit tests
test_aes128_xtsandtest_aes256_xtscheck IEEE Std 1619-2007 vectors 2 and 15 and NIST CAVP XTSGenAES128/XTSGenAES256 vectors (hex tweak format, including a 200-bit data unit), compare against OpenSSL's default provider for 16 to 1023 bytes and two data units in one context, and check rejection of short input, equal key halves and a direction change without a key.Tested on master cd8836f with
scripts/build-wolfprovider.sh(OpenSSL 3.5.4, wolfSSL 5.9.4):src/andinclude/changes reverted (keeping only theWP_HAVE_AESXTSdefine so the tests compile), both new tests fail and the other 247 pass.--replace-default --enable-replace-default-testing: 249/249 pass. The fetch above fails on master and succeeds with this change.--fips-check=ready): 226/226 pass, including both XTS tests.