DeKeySQL: Dual Approaches in SQL Processing

• DeKeySQL is a term for two distinct SQL systems, one enabling secure on-the-fly AES decryption for cloud databases and the other employing a RAG pipeline for NL2SQL generation.
• The on-the-fly AES system uses client-side AES256, UDF layers, and runtime protections (e.g., SGX) to let plaintext-like SQL evaluation occur while storage remains ciphertext-only.
• The RAG-based NL2SQL pipeline integrates user question understanding, entity retrieval, and iterative SQL revision to boost execution accuracy on benchmarks like BIRD and Spider.

DeKeySQL is a name used in arXiv literature for two distinct SQL-oriented systems. In "On-the-fly AES Decryption/Encryption for Cloud SQL Databases" (Jajodia et al., 2015), it denotes an on-the-fly AES approach for outsourced encrypted cloud SQL databases in which client-side AES256 encryption, a UDF-capable cloud DBMS, and a protected DBMS runtime are combined so that query evaluation can proceed over decrypted run-time values while persistent storage remains ciphertext-only. In "DeKeyNLU: Enhancing Natural Language to SQL Generation through Task Decomposition and Keyword Extraction" (Chen et al., 18 Sep 2025), it denotes a three-stage Retrieval-Augmented Generation (RAG) pipeline for natural-language-to-SQL (NL2SQL) built around user question understanding, entity retrieval, and SQL generation with iterative revision. The shared label therefore refers to different technical objects: one addresses secure outsourced SQL execution, and the other addresses model-centric SQL synthesis from natural language.

1. Terminological scope and research contexts

The two uses of DeKeySQL occupy different layers of the database stack. The earlier usage concerns ciphertext-resident cloud databases and asks how a cloud DBMS can retain the functional capabilities of a plaintext SQL DBMS while storing only encrypted data. The later usage concerns NL2SQL and asks how task decomposition and keyword extraction can improve execution accuracy on benchmarks such as BIRD and Spider. The same term thus spans cryptographic database processing and LLM-based query generation (Jajodia et al., 2015, Chen et al., 18 Sep 2025).

Usage of DeKeySQL	Problem setting	Core elements
On-the-fly AES DeKeySQL	Outsourced encrypted cloud SQL databases	Client-side AES256, AESE/AESD UDFs, key-and-plaintext vault, ciphertext-only persistent storage
RAG-based DeKeySQL	NL→SQL generation	User Question Understanding, entity retrieval, SQL generation, revision, DeKeyNLU

For technical reading, disambiguation by arXiv identifier is essential. The 2015 system is defined by a threat model, runtime protections, and encryption modes. The 2025 system is defined by a pipeline architecture, a supporting dataset, and benchmarked execution accuracy. Any discussion of “DeKeySQL” without this qualification risks conflating security-oriented encrypted query processing with language-model-mediated SQL generation.

2. On-the-fly AES DeKeySQL for cloud SQL databases

In the 2015 usage, DeKeySQL is an architecture for client-side AES256 encryption in a cloud SQL DB. The high-level components are clients, a TLS/SSL encrypted channel, a cloud DBMS core with a UDF layer and a key-and-plaintext vault, and insecure persistent storage containing ciphertext files and indexes. The SQL engine itself is described as “unmodified,” with AESE and AESD provided at the UDF layer (Jajodia et al., 2015).

The workflow is explicit. First, a client constructs SQL plus metadata, where the metadata consist of one or more 256-bit AES keys and identifiers specifying which columns are deterministic versus probabilistic. Second, SQL and keys are sent through the TLS channel to the parser and UDF loader in the cloud DBMS. Third, the UDF layer instantiates run-time variables $K_1 \ldots K_m$ and flags DETERMINISTIC or PROBABILISTIC, with the stipulation that keys never touch disk. Fourth, the execution engine produces a “plaintext plan,” as if the table held clear values. Fifth, when the plan reads a ciphertext column $C$, deterministic columns may support index lookups or joins directly on $C$ without decryption, whereas other cases invoke AESD(C, K_{\mathrm{col}}) to obtain run-time plaintext for comparisons, predicates, or aggregation. Sixth, UPDATE and INSERT invoke AESE(plaintext, K_{\mathrm{col}}) to produce fresh ciphertext. Seventh, at the end of the statement, whether commit or rollback, all run-time variables holding keys and decrypted values are zeroed in memory.

This design is intended to let the cloud DBMS evaluate SQL over transient plaintext while keeping disk-resident state encrypted. The abstract characterizes the result as functionally offering to a cloud DBMS the capabilities of a plaintext SQL DBMS, subject to a trust assumption about the security of run-time values.

3. Threat model, runtime protection, and encryption modes

The security model of the on-the-fly AES system trusts clients and their local key-stores, treats cloud storage—including disk and backups—as fully compromised or adversarial, and assumes that the cloud DBMS runtime is protected by a “vault,” implemented either as software-only moving-target defense or as an Intel SGX enclave. The network path is protected by standard TLS/SSL, and the description specifies that there are no plaintext keys on the wire. Runtime defenses include code and data layout randomization with frequent rebases so that an attacker cannot locate the UDF key buffer or decrypted pages, and SGX enclave execution in which UDF calls and key storage run inside enclave pages that cannot be read by ring0 or the hypervisor. After query execution, memory slots that held AES keys or plaintext cells are explicitly overwritten (Jajodia et al., 2015).

Two encryption modes are defined. Deterministic AES is described as ECB-style and uses no randomness:

$C = E_K(m)$

Identical plaintext blocks produce identical ciphertext blocks. This mode is intended for equality predicates, joins, and indexed lookups over $C$, particularly in OLTP queries. The abstract states that deterministic encryption may have no storage overhead. In the detailed formulation, if the block size is $B = 16\,\mathrm{B}$ and the plaintext cell length is $\ell \le B$, then the ciphertext-cell size is $B$, the overhead per cell is $(B-\ell)/\ell$, and the total table size is approximately $\lceil \mathrm{RawSize}/B \rceil \cdot B$.

Probabilistic AES is described as CBC-style and prepends a random IV of size $C$0 bits:

$C$1

Its stated use cases are high-entropy, confidentiality-first columns such as salary and SSN, and it is said to resist frequency analysis. In this mode, only plaintext queries with the key can perform joins or predicates. If plaintext grouping is per-cell and each $C$2, then the ciphertext size becomes $C$3 for the IV plus $C$4 for the encrypted block, or $C$5 total. The corresponding overhead is $C$6–$C$7, and the abstract summarizes this as doubling the DB storage.

The limitations are equally direct. The trust boundary shifts to the DBMS runtime, so insider or side-channel attacks on memory could leak keys if defenses fail. The discussion also notes that range queries or ORDER BY on deterministic encryption leak order, whereas probabilistic encryption disallows range and index use.

4. Performance characteristics, deployment, and comparative position

The performance model for AES256 with AES-NI acceleration is linear in the total number of processed bytes $C$8:

$C$9

with $C$0, corresponding to roughly $C$1, and $C$2–$C$3 for key schedule and call overhead. The empirical benchmark on an Intel Core i5 with AES-NI enabled reports throughput of approximately $C$4, or about $C$5 million 16-byte blocks per second. Decrypting $C$6 blocks is estimated as approximately $C$7. By comparison, software-only AES such as Twofish is reported at about $C$8, approximately $C$9 slower, and Paillier homomorphic processing is reported as about $C = E_K(m)$0 for $C = E_K(m)$1 additions plus $C = E_K(m)$2 client decryption and summation, two orders of magnitude slower. Scanning ciphertext rather than plaintext from SSD or HDD is said to add at most $C = E_K(m)$3 extra cost, while on-the-fly decryption is characterized as negligible relative to disk I/O for large scans (Jajodia et al., 2015).

Deployment is framed as straightforward on a UDF-capable cloud-SQL engine. The specified UDFs are:

$\lceil \mathrm{RawSize}/B \rceil \cdot B$2

implemented in C as a shared library backed by a hardware-accelerated AES256 library. The description states that an existing cloud SQL DBMS with UDF support should do. Key management is client-centric: the client holds a master key store in an HSM or local KMS, each column Tbl.Col has a column key $C = E_K(m)$4, and metadata include $C = E_K(m)$5 pairs. Rotation is performed offline by generating a new random key $C = E_K(m)$6, re-encrypting with

$\lceil \mathrm{RawSize}/B \rceil \cdot B$3

dropping the old key, and updating metadata to the new key identifier.

The comparative discussion places this DeKeySQL between traditional client-side encryption and homomorphic encryption. Relative to traditional client-side encryption, the cloud can evaluate SPJ and OLAP operators on decrypted streams inside the protected runtime, and only per-statement, per-column keys pass through. Relative to homomorphic schemes such as Paillier and FHE, it is described as orders of magnitude faster and as supporting general SQL, including joins, GROUP BY, and ORDER BY, at the cost of having to trust the DBMS runtime.

5. DeKeySQL as a RAG-based NL→SQL pipeline

In the 2025 usage, DeKeySQL is a three-stage Retrieval-Augmented Generation pipeline for NL→SQL. The first stage, User Question Understanding (UQU), takes a raw user question $C = E_K(m)$7 and outputs a task decomposition consisting of a single main task $C = E_K(m)$8 and a sequence of sub-tasks $C = E_K(m)$9, together with keyword sets $C$0 and $C$1. The object keywords map to schema elements, and the implementation keywords map to filter conditions. This module is implemented with an LLM fine-tuned on DeKeyNLU using a two-step Chain-of-Thought prompt that separates main-task generation from sub-task refinement (Chen et al., 18 Sep 2025).

The second stage is entity retrieval. Each keyword $C$2 is embedded as a vector $C$3, and a retriever searches a Chroma vector store for top-$C$4 candidate entities $C$5. Two complementary retrieval methods are used. For high-cardinality values, the pipeline uses MinHash together with Jaccard similarity,

$C$6

approximated by MinHash signatures. For textual schema items, it uses BM25:

$C$7

A re-ranker then rescales the top-$C$8 candidates using cosine similarity,

$C$9

and returns the two most similar entities for each keyword.

The third stage is SQL generation and revision. A second LLM, exemplified in the description by GPT-4o, is prompted with a schema snippet, retrieved entities, task decomposition, and the original question to produce an initial SQL program $B = 16\,\mathrm{B}$0. If $B = 16\,\mathrm{B}$1 fails execution, the error message $B = 16\,\mathrm{B}$2 and the failed SQL are fed back to an LLM prompt that outputs a corrected SQL $B = 16\,\mathrm{B}$3, iterating up to a fixed threshold, usually at most five rounds. The end-to-end flow is summarized as

$B = 16\,\mathrm{B}$4

This architecture makes task decomposition, schema grounding, and post-hoc execution repair explicit stages of the NL2SQL process rather than leaving them implicit in a single generation prompt.

6. DeKeyNLU, fine-tuning procedure, and empirical results

The supporting dataset for the NL2SQL DeKeySQL is DeKeyNLU, which contains 1,500 NL/SQL pairs sampled from BIRD. Its annotation schema has two parts. For task decomposition, each question is split into a main task and 1–5 sub-tasks corresponding to elements such as JOIN, WHERE, and GROUP BY. For keyword extraction, annotations distinguish object keywords, which are table or column names, from implementation keywords, which are filter values or actions encoded as key–value pairs. The annotation process begins with GPT-4o pre-annotation using CoT and few-shot prompting, continues through three expert annotators in three rotational rounds, and ends with Likert scoring from 1 to 5, with all cases scoring below 4 collaboratively reworked. Inter-annotator agreement is reported as Krippendorff’s $B = 16\,\mathrm{B}$5. The train, validation, and test split is $B = 16\,\mathrm{B}$6. For main tasks per question, $B = 16\,\mathrm{B}$7 have 1, $B = 16\,\mathrm{B}$8 have 2, and $B = 16\,\mathrm{B}$9 have at least 3. For sub-tasks, $\ell \le B$0 have 1–2, $\ell \le B$1 have 3–4, and $\ell \le B$2 have at least 5. For keywords per question, $\ell \le B$3 have 1–2, $\ell \le B$4 have 3–4, and $\ell \le B$5 have at least 5 (Chen et al., 18 Sep 2025).

Fine-tuning is concentrated in the UQU and generation modules. The UQU module is fine-tuned with supervised LoRA using rank $\ell \le B$6, $\ell \le B$7, dropout $\ell \le B$8, one epoch, batch size $\ell \le B$9, learning rate $B$0, and 4-bit precision. The models listed for UQU include GPT-4o-mini, GPT-4, Mistral-7B, LLaMA3-8B, and Baichuan2-7B/13B. The loss is standard sequence cross-entropy:

$B$1

The generation module, including code LLMs such as DeepSeek-Coder-V2-Instruct, is also trained with LoRA for approximately 4–5 hours, again with cross-entropy over SQL tokens. The retrieval module is fully unsupervised and has no trainable parameters beyond the embedding model. Prompt context is fused as $B$2, and the two-step CoT strategy is said to improve stability relative to single-shot decomposition.

Evaluation uses BIRD dev EX and Spider dev and test EX, where EX denotes execution accuracy measured by pass/fail on matching query results. For NLU, the reported metrics are BLEU, ROUGE, a calibrated GPT-4o score for decomposition, and F1 for keyword extraction. Fine-tuning UQU on DeKeyNLU, combined with GPT-4o generation, improves BIRD dev EX from $B$3 to $B$4 and Spider dev EX from $B$5 to $B$6, with Spider test EX at $B$7. Module ablation on BIRD dev with a GPT-4 backbone reports $B$8 for generation only, $B$9 after adding entity retrieval, $(B-\ell)/\ell$0 after adding revision, and $(B-\ell)/\ell$1 for the full system with UQU. The paper’s component-wise analysis states that UQU is the most critical module, improving dev EX by approximately $(B-\ell)/\ell$2 when fine-tuned on DeKeyNLU, while entity retrieval contributes approximately $(B-\ell)/\ell$3 and revision approximately $(B-\ell)/\ell$4. Model ablation further reports $(B-\ell)/\ell$5 for GPT-4o-mini in UQU versus $(B-\ell)/\ell$6 for non-fine-tuned GPT-4, $(B-\ell)/\ell$7 for MinHash+Stella-400M retrieval versus $(B-\ell)/\ell$8 for BM25+text-embed-3-large, and $(B-\ell)/\ell$9 for GPT-4o code generation versus smaller code LLMs at approximately $\lceil \mathrm{RawSize}/B \rceil \cdot B$0–$\lceil \mathrm{RawSize}/B \rceil \cdot B$1.

Taken together, the two DeKeySQL usages represent distinct responses to different SQL bottlenecks. The 2015 system seeks to restore practical SQL functionality over encrypted outsourced data by trusting a protected run-time vault and using on-the-fly AES decryption and encryption. The 2025 system seeks to improve NL2SQL execution accuracy by explicitly structuring decomposition, retrieval, generation, and revision. The commonality lies not in shared architecture, but in the attempt to recover full SQL utility under a constraining condition—ciphertext-only storage in one case, and error-prone natural-language interpretation in the other.