dmitry-chirkov-dremio opened a new pull request, #53815: URL: https://github.com/apache/arrow/pull/53815
### Rationale for this change Gandiva's `aes_encrypt` / `aes_decrypt` only support AES-ECB on VARCHAR. ECB is deterministic and unauthenticated, and ciphertext is not valid text. This adds binary `encrypt` / `decrypt` functions with CBC and authenticated GCM modes. See #53776. ### What changes are included in this PR? New functions, all `binary` in and out, with `kResultNullIfNull` and errors reported through the execution context: ``` encrypt(data, key, mode) encrypt(data, key, mode, iv) encrypt(data, key, mode, iv, aad) -- decrypt has the same overloads ``` - Modes (case-insensitive): `AES-ECB`, `AES-CBC`, `AES-GCM`, plus explicit `-PKCS7` / `-NONE` variants for ECB and CBC. Keys are 16, 24 or 32 bytes. - CBC requires a 16-byte IV. GCM takes any non-empty IV and optional AAD; encryption appends the 16-byte tag and decryption verifies it. - IV and AAD are caller-managed and not embedded in the output. - Output buffers are sized for the largest possible result, independently of key length, and negative or oversized input lengths are rejected. The existing `aes_encrypt` / `aes_decrypt` functions and `encrypt_utils.*` are **not modified**. The commits are layered for review: ECB utilities, CBC, GCM, the dispatcher and function registration, then projector tests. Each commit builds and passes on its own. **Where to look first:** `encrypt_utils_gcm.cc` (the IV length must be set before the IV is supplied, otherwise OpenSSL silently uses only the first 12 bytes), the buffer sizing in the dispatcher stubs in `gdv_function_stubs.cc`, and the registry entries in `function_registry_string.cc`. Related: #50522 concerns output sizing in the existing `aes_encrypt` stub, which this PR does not touch. ### Are these changes tested? Yes: - Unit tests per module (ECB, CBC, GCM, OpenSSL error formatting): all key sizes, invalid keys/IVs, padding failures, tag corruption and AAD mismatch. - Known-answer tests for GCM from the GCM specification (McGrew and Viega, test cases 4-6; 12-, 8- and 60-byte IVs). They fail without the IV-length ordering above. - Stub tests for every mode, including block-aligned inputs written from one context. - Projector tests through the function registry and LLVM engine: round trips for ECB, CBC and GCM (with and without AAD) over empty, block-aligned and NULL values, plus error propagation. The full `gandiva-internals-test` and `gandiva-projector-test` suites pass locally with clang on macOS. I'm relying on CI for other toolchains. ### Are there any user-facing changes? Yes, new SQL-level functions `encrypt` and `decrypt`. Nothing existing changes. ### Was AI used for this PR? In accordance to the [AI generation guidelines](https://arrow.apache.org/docs/dev/developers/overview.html#ai-generated-code), please disclose below whether and how AI was used in this PR. **PR code and description written by:** - [x] Human - [x] AI The original implementation was written by a human engineer in an internal codebase. AI tooling was used to port it onto current main and resolve conflicts, to review it and fix what the review found (GCM IV-length ordering, an `EVP_CIPHER_CTX` leak on invalid key lengths, input-length validation and output buffer sizing), to write the known-answer, block-aligned and projector tests, and to write this description. **Reviewed before submission by:** - [x] Human - [x] AI - [ ] Not reviewed * GitHub Issue: #53776 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
