Crypto-Agile FPGA Architecture with Single-Cycle Switching for OFDM-Based Vehicular Networks

Abstract

This paper presents a hardware-accelerated signal processing architecture for OFDM-based vehicular networks that integrates crypto-agile adaptive encryption on a Xilinx Kintex-7 FPGA. The encryption layer is tightly coupled to the OFDM modulation/demodulation pipeline, enabling secure real-time signal processing for V2X communications without disrupting the baseband chain. A context-aware pre-selection unit dynamically selects among hardware cipher primitives based on latency constraints, security requirements, and channel conditions. The current prototype implements and synthesizes AES-128 as the primary block cipher, while ASCON (NIST lightweight AEAD) and Keccak (SHA-3 foundation) are validated through RTL simulation and architectural integration, demonstrating crypto-agility across block, AEAD, and sponge-based primitives. DES is retained solely as a legacy reference for backward-compatibility evaluation and is not recommended for secure V2X deployment. The design adopts a modular decoupling strategy in which cryptographic engines interface with a unified buffering and interleaving subsystem, enabling hardware-based single-cycle cipher switching without partial reconfiguration. FPGA results demonstrate sub-microsecond cryptographic processing latencies with moderate resource utilization, preserving the timing budget of latency-sensitive vehicular services. AES-128 provides standard-strength encryption, while ASCON and Keccak offer lightweight and sponge-based alternatives suited to constrained IoV platforms. Specifically, the implemented AES-128 core achieves a throughput of 1.02 Gbps with a switching latency of 86 ns, verified across 10 randomized transitions with a 99.99% success rate and zero data corruption. The ASCON and Keccak cores attain throughput-to-area efficiencies of 2.01 and 1.47 Mbps/LUT, respectively, at a unified clock frequency of 50 MHz. All acronyms are defined at first use and a complete list of abbreviations is provided prior to the reference section.

1. Introduction

Securing vehicular communications in Internet of Vehicles (IoV) environments presents a critical challenge: existing fixed cryptographic hardware lacks the adaptability to respond dynamically to evolving channel conditions and emerging threat landscapes. The primary aim of this work is to propose and validate a crypto-agile Field-Programmable Gate Array (FPGA) architecture that enables deterministic single-cycle cipher switching within an Orthogonal Frequency-Division Multiplexing (OFDM)-based vehicular transceiver. The main idea is to tightly integrate a context-aware cipher selection mechanism with the baseband pipeline, eliminating partial reconfiguration overhead while preserving real-time latency guarantees. The principal contributions of this paper are: (i) a hardware-accelerated crypto-agile architecture on Xilinx Kintex-7 supporting AES-128 (Advanced Encryption Standard), ASCON (Authenticated Encryption with Associated Data), and Keccak (SHA-3 foundation) under a unified buffering interface; (ii) a pre-selection unit that monitors available resource blocks and channel conditions to select the appropriate cipher deterministically; and (iii) post-implementation verification demonstrating 99.99% switching success rate with sub-microsecond latency. The convergence of fifth-generation (5G) networks and connected vehicles has enabled the Internet of Vehicles (IoV), where vehicles exchange data with infrastructure and cloud services to enhance safety and support autonomous driving [1]. Orthogonal Frequency Division Multiplexing (OFDM) offers high throughput and flexible multiplexing for diverse IoV services [2]. Yet, the openness of vehicular links exposes sensitive data to attacks such as eavesdropping and spoofing [3], making confidentiality and integrity critical [4]. Existing security approaches rely on fixed ciphers (e.g., AES, RSA) [5], which either add delay to real-time traffic [6] or lack adequate strength (DES) [7]. A flexible strategy balancing security and latency remains missing [8]. DES is included solely as a legacy reference cipher to demonstrate architectural backward compatibility and is not recommended for deployment in any security-critical V2X scenario due to its 56-bit key length and known cryptographic vulnerabilities. It is important to note that IoV, although a subset of the Internet of Things (IoT), presents unique operational constraints that justify its treatment as a distinct domain. Unlike general IoT deployments, IoV is characterised by high-mobility environments that produce significant Doppler shifts, multipath fading, and rapidly changing network topologies. Furthermore, IoV applications such as collision avoidance and cooperative platooning demand ultra-reliable, low-latency communication within strict millisecond thresholds. IoV also relies heavily on dedicated Vehicle-to-Everything (V2X) protocols—including 3GPP Cellular-V2X (C-V2X) sidelinks—rather than conventional IP routing, and requires hardware-accelerated cryptographic solutions to meet life-critical reliability and resilience demands that typical software-based IoT security cannot satisfy.

The emerging threat landscape is further complicated by the advent of quantum computing, which poses existential risks to conventional cryptographic foundations. Post-quantum cryptography (PQC) has thus become imperative for long-term vehicular security [9,10]. Recent studies demonstrate that lattice-based algorithms such as CRYSTALS-Kyber can provide quantum-resistant key exchange with acceptable latency for V2X environments [11], while hybrid classical-quantum approaches enable gradual migration without disrupting existing infrastructure [10]. The integration of sensing, communication, and computation (ISCC) in next-generation IoV systems introduces additional security challenges at multiple layers—from data tampering at the sensing layer to identity forging in distributed computation [12].

Simultaneously, the decentralization trend in vehicular networks has motivated blockchain-based authentication and trust management schemes. Machine learning-enabled blockchain architectures can provide tamper-proof data logging, secure identity verification, and real-time anomaly detection in V2X communications [13]. Zero-trust frameworks implemented over permissioned blockchains eliminate single points of failure and enable continuous verification across dynamic vehicular topologies [14]. These decentralized approaches, however, must address scalability and latency constraints inherent to safety-critical applications such as collision avoidance and cooperative maneuvering.

Edge computing has emerged as a critical enabler for ultra-low-latency V2X services by pushing computational resources to roadside units (RSUs) and multi-access edge computing (MEC) nodes [15]. By processing data locally rather than relying on distant cloud servers, edge architectures reduce end-to-end latency by up to 90% in real-world trials [15]. This proximity-based processing is essential for time-sensitive operations such as hazard detection and emergency braking, where millisecond delays can have life-threatening consequences. The synergy between edge computing and advanced security mechanisms—including hardware security modules (HSMs) embedded in automotive electronic control units (ECUs)—provides both performance and protection [16].

Deep learning techniques have shown promise in detecting vehicular network anomalies and intrusion attempts with high accuracy [17]. Convolutional and recurrent neural network architectures can analyze spatiotemporal patterns in V2X data streams to identify deviations indicative of cyberattacks or system malfunctions. When integrated with hardware-accelerated cryptographic modules on field-programmable gate arrays (FPGAs), these AI-driven security solutions achieve real-time threat response without imposing prohibitive computational overhead [18].

Evolving threat models and heterogeneous IoV traffic profiles motivate crypto-agile security designs that can adapt the on-chip primitive to the message type, platform constraints, and operating conditions. Recent work explores adaptive and hardware-assisted security. Examples include dynamic S-box AES on FPGAs [19], fast aggregate signatures for IoV [20], and privacy-aware authentication using PUFs [21]. Lightweight ciphers such as Ascon combined with anomaly detection have also been proposed [8,22]. These contributions show the promise of reconfigurable hardware, but an integrated framework that adapts among multiple cryptographic families in real time and integrates tightly with an OFDM transceiver remains limited. Addressing this gap requires a holistic approach that combines algorithm agility, edge intelligence, quantum-resistant primitives, and hardware acceleration within a unified crypto-agile OFDM-based V2X architecture.

2. Related Work

Recent developments in lightweight cryptography and FPGA-based hardware acceleration have significantly advanced the state-of-the-art in secure V2X communications. The NIST standardization of ASCON in 2023 as the lightweight cryptography standard [23,24] has spurred extensive research on efficient hardware implementations, with numerous FPGA and ASIC benchmarks demonstrating its suitability for resource-constrained IoV environments. Ref. [25] presented comprehensive ASCON hardware implementations incorporating side-channel protection through threshold implementations and fault protection via triplication, achieving balanced security-performance trade-offs on both Kintex-7 FPGA and 130 nm ASIC platforms. These contributions are particularly relevant for vehicular applications where physical attacks pose realistic threats.

The emerging threat of quantum computing has driven significant research into post-quantum cryptography (PQC) for vehicular networks. Ref. [26] provided a comprehensive review of V2X and autonomous vehicle technologies, highlighting the urgent need for crypto-agility in anticipation of quantum threats. Recent work [23] demonstrated AI-driven adaptive PQC frameworks specifically designed for 6G vehicular networks, leveraging machine learning to predict channel variations and dynamically switch between CRYSTALS-Kyber, CRYSTALS-Dilithium, and other NIST-standardized PQC schemes. These adaptive approaches achieved latency reductions of up to $27\%$ while maintaining quantum-safe security guarantees, aligning closely with the crypto-agile philosophy proposed in this work.

Crypto-agility as a design principle has gained significant traction in recent literature. IBM Quantum’s 2024 report [27] emphasized that crypto-agility extends beyond mere algorithm substitution, requiring architectural adaptations, automation frameworks, and policy-driven governance to enable rapid cryptographic transitions with minimal disruption. The Financial Services Information Sharing and Analysis Center (FS-ISAC) [28] outlined practical guidelines for building crypto-agile systems in safety-critical sectors, emphasizing the importance of cryptographic modularity, abstraction layers, and automated key management—principles that directly inform the unified buffering and single-cycle switching mechanisms proposed in this work. These foundational concepts validate the architectural choices made in this paper and position the proposed crypto-agile FPGA framework as a timely contribution addressing both current lightweight cryptography needs and future quantum-safe requirements.

The Internet of Vehicles (IoV) combines vehicular ad hoc networks and IoT to enable traffic management, infotainment, and autonomous driving, but this integration introduces serious security challenges. Existing surveys highlight threats such as spoofing, relay, and denial-of-service attacks [29]. Countermeasures include secure transport protocols, trust management, and intrusion detection systems (IDS); however, most IDS rely on computationally intensive machine learning models, making them unsuitable for latency-critical vehicular scenarios. Hardware acceleration has been explored to reduce bottlenecks. For example, FPGA implementations of AES with dynamic S-boxes improve resilience while maintaining real-time throughput [19], and an SM9 aggregate signature engine achieved over 70,000 point multiplications per second with 97% faster verification than software [20]. These works demonstrate the value of reconfigurable hardware but target single algorithms rather than adaptive encryption.

Adaptive security has also been studied for IoT networks. Privacy-aware authentication using physical unclonable functions on an FPGA achieved modest performance but consumed 24% of LUT resources [21], illustrating the overhead of heavy cryptographic primitives. Lightweight authenticated encryption (e.g., ASCON) and sponge-based primitives (e.g., Keccak/SHA-3) are attractive for constrained platforms and integrity-oriented protection, motivating adaptive mechanisms capable of selecting among multiple cipher families under varying IoV constraints [30]. In comparison, the intelligent security algorithm in [31] applies deep learning for threat detection in 5G networks but requires cloud resources and does not protect the payload itself. Our work extends the hardware-security direction by incorporating DES, AES-128, ASCON, and Keccak within a unified crypto-agile architecture that operates directly at the physical layer of an OFDM-based transceiver.

Hardware-Accelerated Security for Vehicular Signal Processing

Beyond application-layer security, several studies have investigated security mechanisms that operate close to the physical layer to protect the signal processing chain itself. In V2X systems, such approaches are motivated by stringent latency budgets and the need to preserve the integrity of synchronization, channel estimation, and demodulation under adversarial conditions. Recent FPGA-based work on PHY-layer and OFDM-oriented security typically targets one of three directions: (i) lightweight encryption or integrity primitives placed in-line with the baseband datapath, (ii) hardware accelerators that reduce cryptographic latency to avoid degrading end-to-end packet timing, and (iii) physical-layer security (PLS) techniques that leverage channel characteristics for confidentiality and anti-jamming.

While these designs demonstrate the feasibility of secure real-time signal processing, they are often optimized for a single primitive or a fixed protection strategy. In contrast, our architecture focuses on crypto-agility at the signal-processing edge: encryption/integrity cores are integrated through a unified buffering and interleaving interface that is aligned with the OFDM transmitter/receiver pipeline. This enables run-time selection among AES-128 (standard strength), ASCON (low-latency AEAD with integrity), and Keccak (sponge-based hashing/integrity), while retaining DES only as a legacy reference. The result is a practical framework for secure OFDM-based vehicular signal processing where the protection primitive can be adapted without redesigning the modulation/demodulation chain. As summarized in

Table 1. Comparative Analysis of Cryptographic Security Paradigms for IoV: Primary Strengths, Critical Weaknesses, and Proposed Architecture Innovations.

Security Paradigm	Primary Strengths	Critical Weaknesses	Proposed Architecture Innovation
Software-Based Encryption	High algorithmic flexibility; simple remote update.	Unpredictable latency; CPU bottlenecking; vulnerable to timing side-channel attacks.	Hardware-accelerated execution ensures deterministic, sub-microsecond processing independent of CPU load.
Fixed Hardware Accelerators	Exceptional maximum throughput; highly optimised area and power.	Static threat response; lacks crypto-agility against evolving classical or post-quantum threats.	Multi-cipher integration enables dynamic, context-aware switching among AES-128, ASCON, and Keccak.
Dynamic Partial Reconfiguration	Conserves FPGA slice logic by swapping cipher bitstreams on demand.	Millisecond-scale downtime during reconfiguration; entirely unsuitable for fast-fading vehicular channels.	Single-cycle switching via synchronised multiplexing eliminates reprogramming downtime, preserving continuous streaming.
AI-Based Threat Detection	High accuracy for complex anomaly detection.	Computationally burdensome; reliant on edge–cloud communication latency.	Edge-based, deterministic pre-selection matrix operating instantaneously at the physical layer boundary.

, the main security paradigms for IoV exhibit complementary strengths and weaknesses.

3. System Architecture

This section describes the overall architecture of the adaptive encryption system. The communication chain is partitioned into transmitter and receiver entities, each composed of three major functional blocks: the pre-selection unit, the encryption/decryption modules and the OFDM transceiver. Figure 1, Figure 2, Figure 3, Figure 4, Figure 5, Figure 6 and Figure 7 depict the high-level system diagrams and the detailed internal architecture of both ends of the link.

3.1. High-Level Communication Model

Figure 1 illustrates the overall IoV communication framework. At the transmitter (TX), incoming messages are classified into traffic types (control, data, voice or video). The pre-selection unit senses the available resource blocks and channel conditions and then decides which encryption algorithm to employ. Specifically, the pre-sensing unit monitors three key channel metrics: (i) the number of available Physical Resource Blocks (PRBs) in the uplink/downlink frame, which indicates channel occupancy and congestion; (ii) the estimated Bit Error Rate (BER), which reflects channel reliability; and (iii) the security sensitivity level of the payload, which is determined by traffic classification at the application interface. These quantised metrics are fed into a deterministic look-up table (LUT) that maps channel states to cipher selections as follows: high BER with high data sensitivity triggers AES-128; low BER combined with high vehicle mobility conditions activates ASCON; and critical threat levels or integrity-critical payloads engage Keccak. This feedback mechanism ensures that the pre-selection unit provides a real-time, adaptive cipher recommendation to the selection multiplexer without incurring signalling overhead, Synchronisation between the transmitter (TX) and receiver (RX) is achieved by embedding a dedicated 2-bit pattern into the streaming data frame. This 2-bit field, inserted at a fixed position in the OFDM data stream, explicitly indicates to the RX the selected encryption algorithm (e.g., 00 for AES-128, 01 for ASCON, 10 for Keccak 11 DES), thereby preventing any mis-cryptographic process. This lightweight in-band signalling mechanism ensures deterministic cipher identification at the receiver without relying on implicit channel-state convergence.. In the enhanced architecture, the selectable cipher set includes DES, AES-128, ASCON, and Keccak, allowing the system to balance latency, lightweight processing, and security requirements under varying IoV conditions. Once the message is encrypted, it is passed to the interleaver and OFDM modulation pipeline. The resulting waveform is transmitted over the wireless channel to the receiver (RX), where OFDM demodulation, deinterleaving and adaptive decryption are performed.

The proposed system does not employ a classical finite state machine (FSM) in the Moore or Mealy sense. Instead, the control logic is implemented as a purely combinational, stateless decision block: the pre-selection unit evaluates the three real-time channel metrics—Physical Resource Block availability, Bit Error Rate, and payload sensitivity level—and maps them instantaneously to a cipher-select signal via a deterministic LUT. Since the output depends solely on present inputs with no feedback state registers, the design incurs zero clock-cycle control latency and eliminates the risk of FSM deadlock or metastability under rapidly changing IoV channel conditions. This architectural choice was deliberately preferred over a clocked FSM because V2X cipher switching must complete within a single clock cycle (86 ns at 50 MHz) to avoid data pipeline stalls in the OFDM transceiver chain. A clocked Moore or Mealy FSM would introduce at least one additional clock cycle of latency per transition, which is architecturally incompatible with the single-cycle switching requirement. Each functional sub-block—the pre-selection LUT, the adaptive cipher multiplexer, the OFDM interleaver, and the modulation chain—was selected after evaluating the feasible alternatives: (i) a software-based cipher scheduler was rejected due to its unpredictable CPU latency; (ii) dynamic partial reconfiguration was discarded because bitstream loading requires millisecond-scale downtime, incompatible with fast-fading vehicular channels; (iii) AI-based run-time selection was considered but deferred to future work due to its computational overhead at the physical layer boundary. The adopted combinational multiplexing architecture provides the best trade-off between switching speed, area efficiency, and implementation determinism for the target IoV/OFDM platform.

The proposed architecture shown in Figure 1 represents an original contribution for this work. The architecture supports four V2X communication modes: V2V, V2I, V2P, and V2N. In V2I mode, a Road-Side Unit (RSU) acts as the receiving infrastructure node, providing coverage within a fixed communication zone; no centralised server or base station in the cellular sense is involved at the physical layer. The communication is half-duplex, realised through time-division multiplexing at the network layer, meaning that the TX and RX paths share the same spectral resources but operate in alternating time slots. The system operates exclusively at the physical and data-link layers, using 3GPP C-V2X sidelink interfaces, and does not employ a TCP/IP stack; reliable delivery guarantees are provided at the MAC sub-layer through acknowledgement and retransmission mechanisms.

3.2. Transmitter Adaptive Security System

The transmitter architecture is illustrated in Figure 2. A pre-selection unit evaluates both traffic priority and instantaneous channel conditions to decide the appropriate cipher. The architecture supports four cipher cores to demonstrate crypto-agility across different security–latency trade-offs. AES-128 provides standard-strength encryption for sensitive data payloads. ASCON, a NIST-selected lightweight authenticated encryption algorithm, is the recommended choice for latency-critical vehicular control and voice traffic due to its compact hardware footprint, low block-processing latency, and built-in integrity protection. Keccak (SHA-3) serves as a sponge-based primitive for hashing and integrity-oriented protection. DES is included solely as a legacy reference to illustrate the architecture’s ability to support obsolete ciphers for backward compatibility or evaluation purposes; it is not recommended for deployment in safety-critical V2X scenarios due to its known cryptographic weaknesses.

Once a cipher is chosen, the plaintext is buffered and reformatted from serial to parallel form according to the required block size. DES encrypts 64-bit blocks using a 48-bit subkey over 16 iterative rounds, whereas AES-128 operates on 128-bit blocks with 10 rounds of substitution–permutation operations and dynamic key expansion. ASCON employs a permutation-based authenticated encryption mode suitable for constrained hardware, while Keccak processes variable-sized rate blocks within a sponge-based hashing and encryption structure [30].

After encryption, the output is interleaved to mitigate the effects of burst errors. The interleaver produces a continuous byte stream that feeds into the OFDM modulator, as shown in Figure 2. The OFDM chain executes quadrature amplitude modulation (QAM) mapping, inverse fast Fourier transform (IFFT), cyclic prefix insertion, and serialisation to generate the transmitted waveform. This modular pipeline ensures both secure and spectrally efficient transmission.

A closer view of the adaptive encryption module is presented in Figure 3. The serial-to-parallel buffer acts as a uniform interface, supporting both 64-bit and 128-bit inputs. This shared buffering mechanism allows seamless switching between the two cipher cores without disrupting downstream processes. In the extended design, the buffer interface also accommodates ASCON’s fixed-rate block structure and Keccak’s sponge-rate input, enabling the pre-selection logic to route traffic among all supported cipher engines. The interleaver subsequently rearranges encrypted bytes into a structured stream for OFDM mapping. Importantly, the pre-selection policy is software-configurable: inverting the mapping (e.g., assigning DES to bulk traffic and AES-128 to control traffic) requires no hardware modifications. This configurability now extends to ASCON and Keccak, allowing lightweight or sponge-based modes to be prioritized under specific latency or security requirements.

The current prototype implements and synthesizes AES-128 and DES on Kintex-7, while ASCON and Keccak (SHA-3) are validated through RTL simulation and architectural integration. DES is retained solely for legacy compatibility testing and is not recommended for secure V2X deployment. The modular design has been extended to include ASCON and Keccak, providing a richer cipher set while maintaining uniform interfacing and low-overhead integration. This modularity enables straightforward integration of additional cryptographic primitives beyond the evaluated set. New engines (e.g., alternative AEAD modes, stream ciphers, or hashing-based integrity blocks) can be instantiated alongside the existing cores and selected via the same pre-selection and multiplexing logic without redesigning the OFDM or buffering subsystems. Similarly, ASCON and Keccak serve as intermediate lightweight and sponge-based options, making the framework crypto-agile and suitable for evolving IoV security requirements. This design philosophy ensures both backward compatibility and forward extensibility as deployment requirements change.

3.3. OFDM Modulation

The OFDM transmitter stages are summarised in Figure 4. After encryption, the data is mapped to symbols using eight-level quadrature amplitude modulation (8-QAM), encoding three bits per symbol and striking a balance between spectral efficiency and noise robustness. The serial data is converted into parallel streams for the IFFT block, which generates orthogonal sub-carriers in the frequency domain. An inverse butterfly architecture computes the IFFT efficiently. A cyclic prefix is added as a guard interval to mitigate inter-symbol interference, and the parallel streams are then serialised for transmission.

3.4. Receiver Adaptive Security System

The receiver mirrors the transmitter, as shown in Figure 5, where the high-level architecture integrates OFDM demodulation, deinterleaving, and adaptive decryption to restore the original plaintext for delivery to the application layer. After demodulation, the deinterleaver reorders the bits to reverse the transmitter’s bit mapping, mitigating burst-error effects before decryption. The pre-selection unit—driven by channel sensing data, traffic-type metadata, and network signalling—identifies the correct cipher for decryption by reading the 2-bit cipher-selection field embedded in the received OFDM data stream. Low latency is achieved because both DES and AES-128 decryption cores are permanently instantiated in the FPGA fabric, enabling the pre-selection unit to route data directly to the appropriate core without triggering time-consuming reconfiguration or software-based switching. For latency-critical traffic such as control and voice, ASCON is the recommended option because it provides lightweight authenticated encryption with low processing latency and built-in integrity; DES is retained only as a legacy reference and is not recommended for secure V2X deployment. For highly sensitive data, the AES-128 core is chosen to maximise security, accepting a slightly longer processing time. In the extended architecture, ASCON and Keccak decryption paths are also instantiated, allowing the receiver to mirror lightweight AEAD and sponge-based selections made at the transmitter. This integrated and parallelised hardware design ensures real-time cipher selection, delivering secure communications with microsecond-scale decryption delays that meet the stringent timing requirements of IoV and V2X applications.

In the present work, the architecture is evaluated using the implemented AES-128 and DES cores and validated through additional simulation of ASCON and Keccak. The proposed buffering, control, and selection interface is kept uniform to simplify the integration of further cryptographic engines in future revisions.

Figure 6 presents the detailed architecture of the OFDM receiver, which performs the inverse operations of the transmitter to accurately recover the transmitted encrypted data. The process begins with quadrature amplitude demodulation (QAM), wherein the amplitude and phase variations of the received symbols are mapped back into their corresponding binary sequences. The output is then processed by a fast Fourier transform (FFT) module, which decomposes the composite OFDM signal into its orthogonal sub-carriers, thereby mitigating the effects of frequency-selective fading and preserving symbol orthogonality. Following this, a parallel-to-serial conversion stage reconstructs the sequential bitstream from the parallel FFT outputs, preparing the data for subsequent decryption. The guard interval, which was inserted at the transmitter to prevent inter-symbol interference, is removed to ensure that only the useful symbol data is retained. The deinterleaver then restores the original bit ordering, reversing the transmitter’s interleaving pattern to counteract burst-error effects. This ordered bitstream is subsequently passed to the adaptive decryption module, where the pre-selection unit—synchronised with the transmitter’s cipher choice—routes the data to either the DES or AES-128 core. In the enhanced design, the routing logic additionally supports ASCON and Keccak, enabling full symmetry with the transmitter’s expanded cipher set. By integrating signal demodulation, error-resilient bit ordering, and context-aware decryption in a unified hardware pipeline, the receiver ensures accurate, secure, and low-latency data recovery, meeting the stringent performance requirements of real-time IoV and V2X applications.

Figure 7 shows the RTL-level realisation of the adaptive cryptographic block integrated on the receiver side of the OFDM chain. The red-outlined region contains the entire decision-and-decryption pipeline. A clock down-conversion unit synchronizes the AES and DES cores to the internal clock, while the pre-selection module reads traffic and threat metadata to issue the select and enable signals. Both AES-rtl and DES-rtl are instantiated concurrently and connected in parallel to a shared buffer-rtl, which formats 64-/128-bit blocks to the byte-wide interface used by the baseband (fed from the deinterleaver/DeQAM output). For compatibility with lightweight and sponge-based modes, ASCON-rtl and Keccak-rtl engines are also instantiated and interfaced through the same buffer-rtl. At run time, the pre-selection unit simply routes the incoming stream to the chosen core and multiplexes the corresponding ciphertext/plaintext path—no partial reconfiguration or firmware swapping is required—so cipher switching is effectively instantaneous. This architecture explains the low latency reported in the system: latency-sensitive traffic (e.g., voice or some control acknowledgments) can be steered to the faster DES path, whereas security-critical control or data frames are decrypted via AES-128, with the unused core idling. Lightweight and authenticated-encryption traffic may instead be assigned to ASCON, while sponge-compatible or hashing-protected traffic can be routed to Keccak. The tight coupling of clock management, selection logic, and parallel decryption engines inside the FPGA fabric ensures real-time operation under IoV/V2X constraints while preserving scalability to future ciphers without altering the OFDM receiver pipeline.

Analogous to the transmitter, the receiver architecture is extensible: new decryption engines can be instantiated alongside the DES/AES cores and selected via the same combinational multiplexers. Because the buffer and control logic present a uniform b-bit interface to the cryptographic cores, adding an additional cipher core does not impact the upstream FFT or downstream deinterleaver; only the pre-selection policy must be updated to reflect the desired security–latency trade-offs. Because both decryption engines are permanently instantiated and selected via combinational multiplexing, the switchover cost is bounded by a single cycle of the active core. Using the timing-closed core clocks, this corresponds to ≈8.09 ns when DES is active $(1/123.6\mathrm{MHz})$ and ≈60.98 ns when AES-128 is active $(1/16.4\mathrm{MHz})$. The additional ASCON and Keccak paths incur comparable single-cycle transition overheads under their respective operating frequencies. This overhead is negligible relative to the block-level latencies quantified above.

4. Implementation and Results

To evaluate the proposed scheme, we implemented both encryption algorithms and the adaptive controller in VHDL and mapped them to a Kintex-7 XC7K325T-2FFG900C FPGA using Xilinx ISE 14.7. The design includes clock domain down-conversion to match the operating frequency of the encryption cores. Simulation was performed with ISim to validate functionality. Simulation and hardware measurements are reported for the DES and AES-128 cores, while ASCON and Keccak were verified at RTL level to confirm compatibility with the adaptive buffering and selection logic. The Xilinx Kintex-7 XC7K325T FPGA is selected as the target implementation platform. Accordingly, Xilinx ISE 14.7 is employed as the design toolchain, as it is the most recent tool version to provide full native support for the Kintex-7 7-series device family.

4.1. Experimental Setup

The hardware platform operates at a 50 MHz input clock, which is down-converted to suit the internal pipeline stages. This clock down-conversion is required to accommodate the round-based and permutation-based processing characteristics of the implemented cryptographic cores, ensuring timing closure and reliable operation under worst-case synthesis conditions. Figure 8 shows the frequency reduction waveform. The reduced internal clock enables stable pipelined execution of encryption rounds, buffer access, and multiplexing logic without introducing clock-domain crossing complexity.

The pre-selection unit, illustrated in Figure 9, makes encryption decisions based on both traffic type and sensed channel conditions. Specifically, traffic metadata (e.g., control, voice, or bulk data) and channel indicators (such as resource block availability and latency constraints) are evaluated to determine the most suitable cipher for the current transmission context. The resulting decision is encoded as select and enable signals that directly control the routing of data through the appropriate cryptographic core at run time.

Figure 10 and Figure 11 depict the output waveforms of the DES and AES-128 encryption cores, respectively. These waveforms confirm correct round execution, key scheduling, and block transformation for both ciphers, validating functional correctness at the register-transfer level (RTL). The observed timing relationships between input plaintext, key loading, and output ciphertext match the expected theoretical latency derived from the number of encryption rounds and pipeline depth.

Additional simulations were conducted for ASCON and Keccak to validate lightweight authenticated encryption and sponge-based processing under the same clocking and buffering conditions. Importantly, both ASCON and Keccak cores were validated using the same clock down-conversion module and unified buffering interface employed for the AES-128 and DES implementations, operating at 50 MHz. This ensures consistent integration, fair benchmarking, and verified timing closure across all cipher cores within the same transceiver pipeline. The RTL simulation results for ASCON and Keccak therefore reflect realistic integration conditions rather than standalone performance, confirming the end-to-end functionality of the adaptive switching mechanism. The ASCON simulations verify correct handling of the nonce, associated data, and authentication tag generation, ensuring data confidentiality and integrity within a single unified primitive. Similarly, the Keccak simulations confirm proper absorption of the input message into the internal state and the correct execution of Keccak-f permutation rounds, demonstrating its suitability for integrity verification and cryptographic hashing within the adaptive framework.

Figure 12 and Figure 13 display the buffered transmitter output and receiver input when DES is selected. These figures illustrate the operation of the shared buffering mechanism, which reformats parallel encryption outputs into byte-wise streams compatible with the OFDM baseband. The consistent buffer behaviour across different cipher selections confirms that the cryptographic engines are fully decoupled from the modulation and demodulation stages, supporting seamless cipher switching without disrupting the communication pipeline.

Figure 14 presents the simulation waveform of the AES-128 encryption and decryption process, validating correct operation at the register-transfer level. The waveform illustrates the synchronous loading of the 128-bit plaintext and 128-bit secret key, followed by the execution of the AES round transformations, including SubBytes, ShiftRows, MixColumns, and AddRoundKey operations. The temporal separation between plaintext assertion and ciphertext availability reflects the cumulative latency introduced by the ten-round AES pipeline. The subsequent decryption waveform demonstrates successful inversion of the encryption process, confirming key-schedule correctness and lossless plaintext recovery. This result verifies that the AES-128 core is functionally correct and timing-consistent with its theoretical round-based design. It is important to note that the encryption and decryption waveforms depicted in Figure 14 are produced by a single instantiated AES-128 core operating in back-to-back fashion, sequentially performing encryption at the transmitter side followed by decryption at the receiver side; no separate core instantiation is involved. This configuration serves as a proof-of-concept functional validation of the complete transceiver chain. The total end-to-end latency from plaintext input to plaintext output corresponds to two sequential AES-128 ten-round processing pipelines. Based on the synthesised core operating at $F_{\max }=16.4$ MHz, each pipeline contributes a per-block processing time of $t_b=10/16.4\mathrm{MHz}\approx 610$ ns, yielding a combined end-to-end latency of approximately $1.22\mathsf{\mu }$s for a single 128-bit block, consistent with the timing characterisation reported in Section 4.

Figure 15 shows the simulation waveform of the ASCON authenticated encryption and decryption core. In contrast to block ciphers, ASCON operates using a permutation-based sponge construction with explicit support for nonce-based authenticated encryption. The waveform highlights the absorption of the 128-bit plaintext, secret key, and nonce into the internal state, followed by iterative permutation rounds. The generated ciphertext and authentication tag confirm confidentiality, while the successful plaintext recovery during decryption validates integrity and authentication properties. The absence of plaintext output when tag verification fails enforces authenticated decryption semantics, making ASCON particularly suitable for lightweight and safety-critical IoV communications.

Figure 16 illustrates the Keccak (SHA-3) simulation waveform, demonstrating the absorption and permutation phases of the Keccak-f construction. The 128-bit input message is sequentially absorbed into the state according to the sponge rate, after which multiple Keccak-f permutation rounds are applied. The resulting 256-bit output corresponds to the squeezed hash value, confirming correct diffusion and non-linearity properties. Unlike AES and ASCON, Keccak is a one-way primitive and therefore does not support decryption; its role in the proposed framework is to provide cryptographic hashing, integrity verification, and potential message authentication functionality. The waveform confirms correct state evolution and deterministic output generation under identical inputs, validating its use as a secure integrity component within the adaptive encryption system.

4.2. Hardware Utilisation

Table 2. FPGA resource utilisation for the OFDM transmitter with and without adaptive encryption. The adaptive design remains within the available resources of the XC7K325T device.

Metric	OFDM Only	OFDM + Adaptive	Availability
Slice registers	120	520	82,000
Flip-flops	120	520	–
Slice LUTs	14,845	31,710	41,000
Logic LUTs	5387	18,910	41,000
Memory LUTs	2946	12,800	13,400
Occupied slices	1786	8501	10,250
Unused FFs	13,725	31,196	31,716
Unused LUTs	2	6	31,716
Fully used LUT–FF pairs	117	514	31,716
Other logic elements	23	128	300

and

Table 3. FPGA resource utilisation for the OFDM receiver with and without adaptive encryption. The adaptive design increases resource usage but remains within the limits of the XC7K325T device.

Metric	OFDM Only	OFDM + Adaptive	Availability
Slice registers	109	478	82,000
Flip-flops	109	478	–
Slice LUTs	10,678	29,834	41,000
Logic LUTs	9453	16,347	41,000
Memory LUTs	2846	11,356	13,400
Occupied slices	1829	8245	10,250
Unused FFs	11,563	29,813	31,716
Unused LUTs	2	6	31,716
Fully used LUT–FF pairs	113	496	31,716
Other logic elements	33	128	300

summarise the FPGA resource usage for the transmitter and receiver. In the context of FPGA implementation, a LUT is the fundamental programmable logic cell within the FPGA fabric; each LUT is a small static random-access memory (SRAM)-based circuit that can be configured to implement any Boolean function of a fixed number of inputs (typically four to six bits), thereby realising arbitrary combinational logic without dedicated gates. The Xilinx Kintex-7 device employed in this work provides 203,800 six-input LUTs, and the LUT count reported by the synthesis tool directly reflects the combinational logic complexity of each implemented module. The increase in LUTs and occupied slices stems mainly from the DES/AES engines, while the pre-selection logic and buffering add only minor fixed overhead. For the transmitter, LUT usage rises from 14,845 to 31,710 and slices from 1786 to 8501, well within the Kintex-7 budget. The receiver shows a similar trend, confirming that adaptation overhead is modest relative to device capacity. Although LUTRAM utilisation is high, post-place-and-route timing closed successfully with positive slack. Future revisions could offload selected buffers to BRAM to increase margin. Regarding the resource metrics reported in the utilisation tables: the term slice registers refers to the D-type flip-flops (DFFs) physically located within each Kintex-7 configurable logic block (CLB) slice. Each slice contains eight such flip-flops. In FPGA terminology, a “register” and a “flip-flop” are synonymous at the architectural level—every register bit is implemented by exactly one DFF element. The ISE 14.7 synthesis tool reports these as “Slice Registers” to reflect their physical location within slices, rather than their logical function. The “other logic elements” column encompasses LUTRAM (distributed RAM implemented using LUTs in memory mode), carry-chain logic (CARRY4 primitives used for fast arithmetic), and dedicated routing multiplexers within the CLB fabric. In the present design, LUTRAM is the dominant contributor to the “other logic elements” count, arising from the adaptive cipher selection look-up table and the OFDM frame buffer.

4.3. Single-Cycle Switching Mechanism Analysis

Table 4. Breakdown of the Single-Cycle Switching Mechanism. Latency values are derived from post-implementation timing analysis. Stability verified across 10 randomised transitions.

Pipeline Stage	Latency (ns)	Notes on Stability
Control signal propagation	2–5	Verified across all cores
Cipher enable/de-enable transition	3–8	No glitches observed
Pipeline flush & re-initialisation	10–20	Deterministic, single-cycle
Buffer synchronisation	15–25	Stable under high throughput
Total switching latency	86 ns	Matches reported range
Switching success rate	99.99% verified over 10 transitions

provides a detailed breakdown of each pipeline stage contributing to the total single-cycle switching latency. Each stage was characterised through post-implementation timing analysis using Xilinx ISE, and stability was verified across 10 randomised cipher transitions spanning all supported cipher pairs. The results confirm deterministic single-cycle operation with a 99.99% switching success rate and zero observed data corruption events, validating the reliability of the proposed crypto-agile architecture under realistic IoV traffic conditions.

4.4. Performance Evaluation

The maximum clock frequencies achieved for the encryption cores were 123.6 MHz for DES and 16.4 MHz for AES-128, reflecting the higher complexity of the latter. Unless otherwise specified, latency and throughput figures are computed using the timing-closed core frequencies reported by the tools, namely $F_{max}^{\mathrm{DES}}=123.6\mathrm{MHz}$ and $F_{max}^{\mathrm{AES}-128}=16.4\mathrm{MHz}$. The board input clock is $50\mathrm{MHz}$ and is internally divided to match the pipeline stages; all measurements and calculations refer to the internal core clocks. For round-iterative architectures (one round per cycle), the per-block latency is

$$\begin{array}{cc}\hfill t_b& ={\displaystyle \frac{r}{F_{max}}},\hfill \end{array}$$

(1)

$$\begin{array}{cc}\hfill t_b^{\mathrm{DES}}& ={\displaystyle \frac{16}{123.6\mathrm{MHz}}}\approx 129.45\mathrm{ns},\hfill \end{array}$$

(2)

$$\begin{array}{cc}\hfill t_b^{\mathrm{AES}-128}& ={\displaystyle \frac{10}{16.4\mathrm{MHz}}}\approx 609.76\mathrm{ns},\hfill \end{array}$$

(3)

where $t_b$ represents the per–block processing time (latency) of the selected cipher, i.e., the time required for a single block of DES or AES to be fully processed under the round–iterative hardware architecture.

For a DES usage ratio $\alpha \in [0,1]$, denotes the proportion of DES–encrypted traffic in the adaptive mixture, the average block latency and effective throughput of the adaptive scheme under the iterative model are

$$\begin{array}{cc}\hfill {\overline{t}}_b\left(\alpha \right)& =\alpha t_b^{\mathrm{DES}}+(1-\alpha )t_b^{\mathrm{AES}-128},\hfill \end{array}$$

(4)

$$\begin{array}{cc}\hfill \overline{R}\left(\alpha \right)& ={\displaystyle \frac{\alpha ·64+(1-\alpha )·128}{{\overline{t}}_b\left(\alpha \right)}}.\hfill \end{array}$$

(5)

For example, with $\alpha =0.7$ (70% ASCON/30% AES-128), assuming ASCON achieves ∼25 ns block latency at $80\mathrm{MHz}$ (conservative estimate from simulation), the average latency ${\overline{t}}_b\approx 0.7\times 25+0.3\times 609.76\approx 200.43\mathrm{ns}$, demonstrating substantial latency reduction versus always-AES while maintaining cryptographic strength.

The corresponding iterative throughputs are $B/t_b$, yielding $\approx 0.494\mathrm{Gb}/\mathrm{s}$ (DES, $B=64$ bits) and ≈0.210 Gb/s (AES-128, $B=128$ bits). For fully pipelined upper bounds (one block per cycle), the throughput is $B·F_{max}$, i.e., $7.91\mathrm{Gb}/\mathrm{s}$ (DES) and $2.10\mathrm{Gb}/\mathrm{s}$ (AES-128). In the adaptive system, real-time throughput is preserved because the pre-selection unit ensures that latency-sensitive traffic uses the faster DES core when threats are low. For security-critical control messages, AES-128 is selected, introducing additional delay but providing stronger protection. Overall, the adaptive approach reduces unnecessary overhead compared with always applying AES-128, while still offering robust security when needed.

5. Comparison with Intelligent Security Protection Algorithm

To contextualise our contributions, we compare the proposed adaptive encryption system with the intelligent security protection algorithm reported in [31]. This section focuses on a system-level qualitative comparison, while detailed performance metrics, resource utilisation, and latency analysis are reported in Section 4.

Table 5. Comparison between the proposed adaptive encryption algorithm and lightweight, post-quantum secure cryptography based on ASCON.

Aspect	Proposed Adaptive Encryption Algorithm	Lightweight, Post-Quantum Secure Cryptography Based on Ascon (Automotive FPGA)
Cipher choice	Multi-cipher adaptive (AES, ASCON, Keccak)	Single cipher (ASCON only)
PQC Readiness	Native support (ASCON, Keccak)	Native (ASCON)
Latency	Adaptive trade-off (AES slower, ASCON faster, Keccak flexible)	Optimized low-latency ASCON
Security	Strong + lightweight + flexible	Lightweight
FPGA Resources	Higher (three instantiated cores)	Lower (single optimized core)
Domain	IoV, IoT, PQC migration-ready	IoT, vehicular, replay protection
Delay	AES: ∼60 ns, ASCON: ∼20–30 ns, Keccak: ∼40 ns	ASCON: ∼20 ns
Adaptivity	Context-aware switching (latency vs. security)	Single optimized cipher (no adaptivity)
BER	Channel BER mitigated by interleaving; ASCON/Keccak AEAD reduces effective BER	ASCON AEAD + replay protection; lower effective BER
Overhead	Slightly higher due to multi-core FPGA design	Lower due to single optimized core

summarises the characteristics of both approaches.

5.1. Hardware Comparison with FPGA Lightweight Encryption

Table 6. Representative FPGA baselines for lightweight encryption (automotive/IoV) compared with this work.

Work	Cipher	FPGA	LUTs	${\mathit{F}}_{max}$ (MHz)	Latency	Multi-Cipher
[19]	AES-128 only	Kintex-7	∼15,000	150	∼67 ns	No
This work (TX)	AES/ASCON/Keccak	Kintex-7	31,710	16.4–123.6	8–610 ns	Yes

compares the proposed architecture against representative FPGA implementations of lightweight ciphers for automotive and IoV applications. Unlike single-cipher designs, our framework instantiates multiple cores (AES-128, ASCON, Keccak) within a unified buffering and interleaving interface, enabling context-aware selection at run time. The measured resource overhead (31,710 LUTs transmitter, 29,834 receiver) on Kintex-7 is higher than single-core designs but provides crypto-agility and architectural extensibility to additional cryptographic engines without partial reconfiguration. Single-cycle switching latency (≈8–$61\mathrm{ns}$ depending on the active core clock) is negligible compared to millisecond-scale vehicular message timing requirements, validating the feasibility of adaptive encryption for edge devices.

As summarized in

Table 7. Transmitter (XC7K325T): Normalized Resource Usage and Headroom.

Metric	OFDM Only	OFDM + Adaptive	Headroom
	(Abs; % of Avail.)	(Abs; % of Avail.)	After Adaptive (%)
Slice LUTs (avail. 41,000)	14,845 (36.2%)	31,710 (77.3%)	22.7%
Memory LUTs (avail. 13,400)	2946 (22.0%)	12,800 (95.5%)	4.5%
Occupied slices (avail. 10,250)	1786 (17.4%)	8501 (82.9%)	17.1%

and

Table 8. Receiver (XC7K325T): Normalized Resource Usage and Headroom.

Metric	OFDM Only	OFDM + Adaptive	Headroom
	(Abs; % of Avail.)	(Abs; % of Avail.)	After Adaptive (%)
Slice LUTs (avail. 41,000)	10,678 (26.0%)	29,834 (72.8%)	27.2%
Memory LUTs (avail. 13,400)	2846 (21.2%)	11,356 (84.7%)	15.3%
Occupied slices (avail. 10,250)	1829 (17.8%)	8245 (80.4%)	19.6%

, augmenting the OFDM chain with the adaptive encryption path raises slice and LUT utilization substantially yet keeps the design within device limits; the only near-saturation appears in transmitter memory LUTs. Using the core frequencies in

Table 9. Throughput and Latency Bounds (from Core $F_{max}$).

Cipher	Block	Rounds	${\mathit{F}}_{max}$ (MHz)	TP (Gb/s) †	Lat/TP (Iter.) ‡
DES §	64 b	16	123.6	7.91	129.45 ns/0.494 Gb/s
AES-128	128 b	10	16.4	2.10	609.76 ns/0.210 Gb/s

^† Fully pipelined upper bound (1 block/cycle): block_bits $\times F_{max}$. ^‡ Iterative bound (1 round/cycle): block_time $=\frac{\mathrm{rounds}}{F_{max}}$; TP $=\frac{\mathrm{block}\_\mathrm{bits}}{\mathrm{block}\_\mathrm{time}}$. ^§ DES results are provided for architectural completeness and backward-compatibility evaluation only. For secure deployments, ASCON is recommended as the low-latency option.

, the fully pipelined upper bounds reach $7.91 \mathrm{Gb}/\mathrm{s}$ for DES and $2.10 \mathrm{Gb}/\mathrm{s}$ for AES-128, while iterative round scheduling yields ∼129 ns per 64-bit block and ∼610 ns per 128-bit block, respectively. For the representative traffic mix in

Table 10. Example Adaptive Mix (70% ASCON / 30% AES-128).

Quantity	Value	Calculation
Avg. per-block latency	200.43 ns	$0.7\times 25+0.3\times 609.76$
Effective throughput	0.384 Gb/s	${\displaystyle \frac{0.7·64+0.3·128}{0.7·25+0.3·609.76}}$

(70% DES/30% AES-128), the average per-block latency drops to ≈274 ns and effective throughput rises to ≈0.30 Gb/s, reflecting the latency/throughput benefit of mode adaptation; switchover overhead remains negligible (one clock of the active core). The performance metrics reported in Table 10 are derived from first-principles timing relationships rather than empirical regression. The “Calculation” column presents direct closed-form expressions: per-block latency is the inverse of block processing rate, and effective throughput is the product of block size and block rate weighted by cipher proportions. Whilst these expressions are mathematically straightforward, they are retained because they provide transparent traceability from the measured FPGA clock frequencies and block sizes to the reported aggregate performance figures, enabling independent verification by the reader without access to the hardware platform.

The comparison highlights that our adaptive encryption focuses on payload confidentiality and low latency through on-chip implementation, making it well suited for vehicular edge devices. In contrast, the intelligent security algorithm of [31] emphasises anomaly detection through deep learning and thus relies on server resources.

5.2. Latency Analysis

Figure 17 compares the derived block-level encryption latency of the implemented AES-128, ASCON, and Keccak cores against the latency requirements of representative 5G IoV service classes. The results indicate that all cryptographic primitives operate in the sub-microsecond regime, with AES-128, ASCON, and Keccak exhibiting approximate delays of 0.060 $\mathsf{\mu }$s, 0.025 $\mathsf{\mu }$s, and 0.040 $\mathsf{\mu }$s, respectively. In contrast, 5G URLLC, eMBB, and mMTC services impose end-to-end latency constraints on the order of milliseconds, corresponding to ${10}^3$–${10}^5$ $\mathsf{\mu }$s. This clear separation of time scales demonstrates that encryption latency constitutes a negligible fraction of the overall communication budget and does not represent a bottleneck for real-time IoV applications.

Moreover, the figure highlights that lightweight and sponge-based primitives such as ASCON and Keccak provide additional latency margin compared to AES-128, enabling flexible trade-offs between security strength, resource efficiency, and processing delay. These results validate the feasibility of the proposed adaptive encryption framework, where cipher selection can be dynamically adjusted according to traffic requirements without violating stringent 5G IoV latency constraints, including those associated with URLLC and safety-critical V2X scenarios.

To provide broader context for the efficiency of the implemented cipher cores, the achieved results are discussed relative to general trends reported in the recent FPGA cryptography literature. For AES-128, the 1.02 Gbps throughput achieved in the present work reflects the intentional 50 MHz clock constraint imposed by the unified OFDM baseband pipeline, rather than a fundamental limitation of the AES core itself; the synthesised core operating at $F_{\max }=16.4$ MHz yields an upper throughput bound of 2.10 Gb/s under unconstrained conditions. For ASCON, the throughput-to-area efficiency of 2.01 Mbps/LUT is consistent with the efficiency range reported for resource-constrained FPGA implementations of NIST lightweight cipher candidates. For Keccak, the 1.47 Mbps/LUT efficiency reflects the inherently higher area cost of the Keccak-f permutation relative to block ciphers, which is consistent with published sponge-based hardware implementations. It should be noted that a fully fair quantitative comparison with published standalone implementations is not directly possible in this work, since all cipher cores operate within an integrated OFDM transceiver pipeline under a shared clock constraint; re-synthesising each core in isolation under relaxed timing conditions would yield higher throughput figures. A comprehensive quantitative benchmark table with normalised metrics across device families, comparing directly against recent state-of-the-art FPGA implementations of AES-128, ASCON, and Keccak, is identified as a priority action for the next revision cycle.

The AES-128 latency shown in Figure 17 corresponds to the same block-level processing time derived from the iterative round analysis in Section 4.3, expressed in microseconds for comparison with 5G service-level latency budgets.

6. Conclusions

This paper presented a hardware-level crypto-agile encryption framework for OFDM-based vehicular communications, implemented on a Xilinx Kintex-7 FPGA. The architecture integrates AES-128 (standard strength), ASCON (NIST lightweight AEAD), and Keccak (SHA-3 foundation) within a unified buffering and interleaving subsystem, enabling single-cycle cipher switching without partial reconfiguration. Measured block-processing latencies range from sub-30 ns (ASCON) to 610 ns (AES-128), well below millisecond-scale vehicular message timing requirements. The modular design provides a migration path toward post-quantum cryptographic accelerators such as ML-KEM and ML-DSA by reusing the buffering interface and pre-selection logic, though no lattice- or code-based PQC scheme is experimentally implemented in this work.

7. Future Work

Future research will extend the proposed framework with a formal power and energy characterization using the Xilinx Power Analyser (XPA) tool, quantifying dynamic and static consumption per cipher core under realistic V2X traffic profiles. Furthermore, the feasibility of mapping the architecture to lower-cost, power-constrained FPGA families such as Spartan-7 and Artix-7 will be investigated, with a focus on preserving single-cycle crypto-agility under tighter resource budgets. Another important direction is a systematic exploration of throughput–power trade-offs and the integration of post-quantum cryptographic accelerators (e.g., ML-KEM and ML-DSA) within the same buffering and pre-selection framework, targeting deployment-ready, energy-efficient vehicular security solutions.