# Signature Split Method for a PQC-DSA Compliant with V2V Communication Standards
## 3 Proposed Simulation
### Application Plan for V2 Verifier  
The structure of V2 Verifier simulates a situation where one local car sends and receives communication with n remote cars. In this study, we proceeded with the simulation using the same structure. Unfortunately, there were equipment limitations, and we were not able to use the original V2 Verifier test equipment, the HW USRP (Universal Software Radio Peripheral). Therefore, we modified the code to simulate on one PC and configured remote cars through multiprocessing. V2 Verifier is a Python-based code, and the codes suggested in [12; 13] are C code mixed with hand-written assembly. To apply this to Python language, we recompiled the code to gcc and built it in the form of a dynamic library. First, we generated a payload using the coordinate information used in the V2 Verifier source code (choosing the number of coordinates variably). We considered and generated packets according to the signature size and WAVE protocol requirements. For example, the minimum signature size for Crystals-Dilithium is approximately 2500 bytes (security level 2), which exceeds the WAVE protocol requirement of 2000 bytes. Therefore, it is difficult to satisfy correctness when using Crystals-Dilithium in WAVE. To solve this, we used our _\"Split way for Crystals-Dilithium\"_. For Falcon, the maximum signature size is about 1330 bytes (Falcon-1024), and the total payload length (1330 + 500) meets WAVE's requirements. The generating payload, generating key pair, and signing payload processes are performed with the _\"run_remote\"_ API, and the verifying signature and decomposing payload processes are performed with the _\"run_local\"_ API. The steps for simulation are as follows:  
* **Generating the payload** V2 Verifier generates the payload in V2 Verifier using _\"Get_wsm_payload\"_ API. The payload consists of three components (Bytestring, Wsm-header, and IEE 1609.data) and a total of 16 pieces of information. The payload requires approximately 500 bytes, excluding signature length information and the signature. * **Generating key pair and signing the payload** Generating the key pair process for generating the public and private keys for PQC-DSA is completed in the first session for local and remote cars. It does not work on session reconnect. Signing payload process generates a signature for the current location of the remote car. For satisfying the correctness of the verification of Crystals-Dilithium on V2 Verifier, we used the _\"Split way for Crystals-Dilithium\"_ for this process. * **Verifying the signature and decomposing the payload** In the verifying signature process, only the signature block is extracted from the received payloads to verify the signature. In the case of Crystals-Dilithium, the process of checking or sorting the order of blocks is added. The decomposing payload process splits the payload, where the signature is validated in the verifying signature process. In \"Split way for Crystals-Dilithium\", only the first received payload is split. The simulation proceeds without using the USRP, as mentioned in the previous paragraph. Therefore, protocol simulations are all the same except for the transport layer. Remote cars send payloads to the local car in parallel. The local car performs signature verification on the received payload. The transmission/reception part of remotes car and local car advances the simulation with file input/output. The C-V2X protocol and the WAVE protocol payload are set in the same way, and payloads exceeding 2000 bytes are divided in order with the WAVE protocol. However, when the local car receives the split payload, it changes the simulation to randomly receive it. When the \"Split way for Crystals-Dilithium\" is applied, additional work proposed by Algorithm 3 is performed before payload transmission. Figure 3 shows the process in which the local car receives the signed bsm in parallel and performs dilithium verification.