# Signature Split Method for a PQC-DSA Compliant with V2V Communication Standards
## 2 Preliminaries
### V2 Verifier  
V2 Verifier is an open-source project dedicated to wireless experimentation focused on the security of V2V communications. The V2 Verifier project features the first open-source implementation of the IEEE 1609.2 standard for V2V security [10]. V2 Verifier uses a combination of software-defined radio such as Universal Software Radio Peripheral (USRP) and commercial V2V equipment to support extensive experimentation with V2V technology and security protocols. Table 2 shows the attributes required for V2V communication, with the following being supported:  
* Security features from the IEEE 1609.2 standard for V2V security, including message signing and verification and V2V certificates. * Dedicated short-range communication (DSRC)--adapted from the WiME Project's IEEE 802.11p transceiver
* Cellular vehicle-to-everything (C-V2X)--based on the srsRAN project (formerly srsLTE) (temporarily not supported). V2 Verifier is designed to run on software-defined radio (SDR). V2 Verifier consists of communication between multiple wireless (hereafter: remote) vehicles and one receiving (hereafter: local) vehicle. To run the actual V2 Verifier, one PC is responsible for transmitting multiple remote vehicles, and another PC is responsible for receiving local vehicles. Recently, researchers at the University of Waterloo, Canada, applied the NIST PQC signature round 3 candidates (Crystals-Dilithium, Falcon, Rainbow) to V2 Verifier at the 2021 NIST PQC conference [7]. They presented an experiment to verify the feasibility of the PQC-DSA algorithm in a secure V2V communication (IEEE 1609.2) environment as a replacement for ECDSA, an existing elliptic curve-based digital signature. In terms of packet size and delay time, the applicability of the PQC-DSA electronic signature algorithm to an autonomous driving environment was analyzed. In addition, the test was designed considering various environments, such as the general autonomous driving environment and the platooning driving stage. According to the result of [7], the minimum signature size of Crystals-Dilithium is about 2500 bytes based on security level 2, which exceeds WAVE's packet size of 2000 bytes; therefore, verification fails during actual communication. Falcon has a maximum signature size of about 1330 bytes, so it meets WAVE's requirements. For signature generation, Crystals-Dilithium achieved a better performance than did ECDSA, while Falcon achieved a worse performance than did ECDSA. Both Crystals-Dilithium and Falcon outperformed ECDSA in signature verification. In V2 Verifier, one local car communicates with multiple remote cars. Figure 1 shows an example of the work structure for V2 Verifier. The local car receives a payload containing the current position of the remote cars. For handling remote cars, V2 Verifier generates multiple processes for the number of remote cars and broadcasts basic safety messages (BSMs) to the local car. The top-level API of V2 Verifier for handling cars are \"run_remote\" for remote cars and \"run_local\" for local cars. V2 Verifier uses the Python \"yml\" module to manage remote car algebra and location information. One can adjust the number of remote cars in action via the \"NumberOfVehicles\" variable in the \"yml\" dataset. This allows remote cars to generate a location-only payload and send it in broadcast format to the local car. At this time, broadcasts occur at 0.1 s intervals and can be controlled by the user. Figure 2 shows an overall structure of the \"run_remote\" (\"run_local\") API and components of the payload of V2 Verifier.