EP4747997A1 - Falcon-based implicit certificates - Google Patents

Abstract

A post-quantum implicit certificate method for signing a message, the method comprising the following steps implemented using at least one processor-based system:at a public key originator, generating a message attesting to identity (msg) and a FALCON public key (h U ), and signing the message using the FALCON public key (h U ) to generate a signature; sending the public key, the message, and the signature to a certificate authority; and at the certificate authority, verifying the signature on the message attesting to the identity (msg), and generating reconstruction value for the public key using certificate authority's own secret key; at a verifier, using the reconstruction value and the certificate authority's public key to generate the public key (h U ).

Description

FALCON-BASED IMPLICIT CERTIFICATES FIELD [0001] Aspects of the disclosure relate to methods and systems for cryptography. BACKGROUND [0002] A digital signature of a message is a number dependent on some secret known only to the signer, and, additionally, on the content of the message being signed. Signatures are meant to be verifiable. If a dispute arises as to whether a party signed a document (caused by either a signer trying to repudiate a signature it did create, or a fraudulent claimant), an unbiased third party should be able to resolve the matter equitably, without requiring access to the signer's secret information (e.g. a private key). [0003] Digital signatures have many applications in information security, in particular, as they are used in cryptographic schemes. Some applications include authentication, data integrity, and non-repudiation. One particularly significant application of digital signatures is the certification of public keys in large networks. Certification is a means for a trusted third party to bind the identity of a user to a public key, so that at some later time, other entities can authenticate a public key without assistance from the trusted third party. [0004] A Public key infrastructure (PKI) is used to authenticate users in a network, with a Certificate Authority (CA) delineating who is and is not an authenticated user. A CA can issue either explicit or implicit certificates. Explicit certificates provide a user’s public key and a digital signature on that public key, while an implicit certificate instead communicates a “reconstruction value” that allows a third party to reconstruct a user’s public key in an authenticated way. In more detail, an implicit certificate scheme replaces the public key and signature with a reconstruction value on the certificate associated to the user. Any third party can use the (CA)’s public key to reconstruct the user’s public key, and in doing so, it is implied that the key has been validated by the (CA). As such the user’s public key and the CA’s signature are given implicitly [1]. Implicit certificates may substantially reduce the overheads associated with certificate management as fewer values need to be sent, and therefore implicit certificate schemes are preferable in situations where bandwidth is limited (such as internet of things or vehicle to vehicle communication). [0005] At present, implicit certificate schemes are vulnerable to attacks by a quantum computer, and efforts to build a post-quantum implicit certificate scheme have been unsuccessful. [0006] FALCON is a post-quantum signature scheme selected by the National Institute of Standards and Technology (NIST) at the fourth round of the post-quantum standardisation process. FALCON defines a trapdoored function ^^ as the public key, signs by hashing the message and inverting ^^ on the resulting point. FALCON parameters consist of a prime q = 12289, a polynomial ^^ = xⁿ + 1, with n = 2^κ (for the FALCON-512 parameter set, n = 512), and the ring is defined as ℛ = ℤ [x]/( ^^). When the coefficients of a polynomial y ∈ ℛ are all between 0 and q − 1, then y ∈ ℛq. A shortness threshold [ ^^²] > 0 is also required for FALCON (approximately 34 million in FALCON-512), and finally standard deviations σ and σ_min < σ_max. [0007] The public key is a polynomial say h ∈ ℛ _q. The secret key consists of the information necessary to perform the FalconSample routine. Recall signing and verification in FALCON: [0008] Signing. Input: Message msg, sk 1. Sample a random r ← {0, 1}³²⁰ 2. Hash (r||msg) to generate c, a polynomial in ℤ [x]/( ^^) with uniform coefficients modulo q. 3. (s₁, s₂) ← FalconSample(c, sk). Each s_i is a ‘short’ in ℤ [x]/( ^^), such that s₁+s₂h = c mod ^^ mod q. For a short polynomial ≤ [ ^^²]. 4. Encode s₂ as s. This encoding process performs better than a naive log₂ (qⁿ) encoding, taking special advantage of the fact that s2 is a short vector. 5. Return (r, s) [0009] Verification. Input: Message msg, public key h, signature (r, s) 1. Generate c ← H(r||msg). 2. Decode s into s₂. 3. Calculate s₁ = c − s₂h mod ϕ mod q. 4. Accept the signature iff (s1, s2) < [β²]. [0010] FALCON follows framework. The public key is the value h, which can be seen as a function that maps two short vectors in ℤ [x]/( ^^), to a single vector c. Signing means hashing the message to a point c and then inverting this function, finding short vectors that map to c. Verification checks that the forward direction of the mapping hits the hash of the message. [0011] FALCON optimizes this process by not bothering to communicate the value s1. Since the information of s2 and the target point c is enough to recover what s1 would have to be, it is sufficient to just send an encoding of s2 and check that these values have the right form. [0012] The inclusion of the value r is performed to ensure that the signer never reveals two preimages of the same target point c; doing so compromises the integrity of the secret key and not doing so is important for the security proof. [0013] In [1] the authors attempted to build an implicit certificate scheme with FALCON by modifying the Elliptic Curve Qu-Vanstone (ECQV) ECQV implicit certificate scheme. One of the difficulties in adaptation arises because FALCON is a trapdoor-based signature scheme, while ECQV is based on elliptic curve signature schemes, which do not have a trapdoor structure. SUMMARY [0014] In one of its aspects, a post-quantum implicit certificate method for signing a message, the method comprising the following steps implemented using at least one processor-based system: at a public key originator, generating a message attesting to identity (msg) and a FALCON public key (h_U), and signing the message using the FALCON public key (hU) to generate a signature; sending the public key, the message, and the signature to a certificate authority; and at the certificate authority, verifying the signature on the message attesting to the identity (msg), and generating a reconstruction value for the public key using certificate authority’s own secret key; at a verifier, using the reconstruction value and the certificate authority’s public key to generate the public key (hU). [0015] In another of its aspects, a public key originator device configurable to generate a message attesting to identity (msg), the public key originator device comprising: a processor; a communication interface coupled to the processor; a memory device coupled to the processor, the memory device storing instructions which, when executed by the processor, is arranged to: sign the message using the FALCON public key (hU) to generate a signature; send the public key, the message, and the signature via the communication interface to a certificate authority which verifies the signature on the message attesting to the identity, and generate a reconstruction value for the public key using the certificate authority’s own secret key. [0016] In another of its aspects, a certificate authority configurable to generate a reconstruction value for a public key of a public key originator, the certificate authority comprising: a processor; a communication interface coupled to the processor; a memory device coupled to the processor, the memory device storing instructions which, when executed by the processor, is arranged to: generate a certificate comprising first information (info_U); generate a bit string r ← H₁(h_U∥info_U), wherein r is a random value salt, and compute a single vector c on the lattice c = H₂(r∥info_U) with a secret key of the certificate authority device (skCA); compute a value of the two short vectors (s1, s2) ← FalconSample (c+ hU mod q, sk_CA); compress the s_i values; whereby the certificate comprises the first information, value r and the encoded short vectors (s1, s2). [0017] Advantageously, the present protocol for implicit certificates is based on the post-quantum signature scheme FALCON, currently being standardized by the American National Institute for Standards and Technology (NIST). While FALCON already has smaller signatures and public keys compared to most other post-quantum signature schemes, the present protocol further reduces the bandwidth requirement in a certificate. In one example, the present protocol presented herein reduces bandwidth requirement for using FALCON signatures and certificates by 271 bytes, without any substantial impact to security. The reduction in bandwidth is especially useful in vehicle-to-vehicle (V2V) communication, as specified by IEEE 1609.2 Standard for Wireless Access in Vehicular Environments (WAVE) pertaining to short-range communications. Without implicit certificates, post-quantum signatures may be too large to fit within standardized frame size if using dedicated short-range communications. BRIEF DESCRIPTION OF THE DRAWINGS [0018] Several exemplary embodiments of the present disclosure will now be described, by way of example only, with reference to the appended drawings in which: [0019] Figure 1 shows a block diagram of an exemplary authentication method; [0020] Figure 2 is a flowchart of an exemplary method for applying a signature to a message to generate a signed message; [0021] Figure 3 is a flowchart of an exemplary method for reconstructing a user’s public key in a way authenticated by the certificate authority; and [0022] Figure 4 shows a signer device and a certificate authority device. DETAILED DESCRIPTION [0023] The following detailed description refers to the accompanying drawings. Wherever possible, the same reference numbers are used in the drawings and the following description to refer to the same or similar elements. While embodiments of the disclosure may be described, modifications, adaptations, and other implementations are possible. For example, substitutions, additions, or modifications may be made to the elements illustrated in the drawings, and the methods described herein may be modified by substituting, reordering, or adding stages to the disclosed methods. Accordingly, the following detailed description does not limit the disclosure. Instead, the proper scope of the disclosure is defined by the appended claims. [0024] Moreover, it should be appreciated that the particular implementations shown and described herein are illustrative of the invention and are not intended to otherwise limit the scope of the present invention in any way. Indeed, for the sake of brevity, certain sub-components of the individual operating components, conventional data networking, application development and other functional aspects of the systems may not be described in detail herein. Furthermore, the connecting lines shown in the various figures contained herein are intended to represent exemplary functional relationships and/or physical couplings between the various elements. It should be noted that many alternative or additional functional relationships or physical connections may be present in a practical system. [0025] The term “signer” as used herein refers to any computerized device able to generate a digital signature on data. The term “verifier” as used herein refers to any computerized device able to verify the authenticity of a digital signature. [0026] Figure 1 is a simplified flowchart of an example authenticated encryption method to be performed by a signer, for example, signer 12, for applying a signature to message 14 to generate a signed message 16, including a random value salt (r). The signed message, along with signer 12’s public key, are sent to a certificate authority 18, which then generates a certificate. In order to verify the signature, a determination is made as to whether the certificate is valid by checking the confirmation salt. [0027] In one example, Figure 2 shows a flowchart 100 with exemplary steps for a method for applying a signature to a message 14 to generate a signed message 16, using a novel paradigm for implicit certificates that is more in line with the trapdoor structure of FALCON. [0028] In step 102, a message 14 to be signed is presented. A signer 12 then generates a private key, a first value k that is a private value of the signer 12 which should not be disclosed to other entities and a FALCON public key hU (step 104), and uses the public key to sign the message attesting to their own identity (step 106). The public key FALCON public key h_U is a function that maps two short vectors in ℤ[x]/(ϕ) to a single vector c. Generally, the signature is a pair (r; S), where r is a hashing salt and S encodes a short vector s. Signing means hashing the message to a point c and then inverting this function, finding short vectors that map to c. Next, in step 108 the user 12 sends the public key, as well as the message 14 and signature, to a certificate authority (CA) 18. [0029] Next, the CA 18 verifies the signature on the message by checking that the forward direction of the mapping hits the hash of the message. The CA 18 takes any information necessary to put in the certificate, denoted info_U, and generates a bit string r ← H₁(h_U∥info_U), and computes c = H₂(r∥info_U) (step 110). The CA 18 then uses its own secret key to compute (s₁, s₂) ← FalconSample(c+ h_U mod q, sk_CA), in step 112. Next, the s₁ values are then further compressed to s_i ← Compress(s_i) (step 114). The CA 18 responds to the client’s query with the certificate cert_U = (info_U, (r, s₁, s₂)), and the client uses the secret key generated in step 104, and therefore has no need to change their secret key. [0030] Figure 3 shows a flowchart 200 with exemplary steps for a method for reconstructing the user’s public key in a way authenticated by the certificate authority. In step 202, the signed message 16 is presented to the third party or verifier device, and then the third party may reconstruct the client’s public key from the certificate by first decompressing the s₁ values to the full polynomials s₁, step 204, and then compute h_U ← s₁ + s₂h_CA − H₂(r∥info_U) (step 206). In step 208, a determination is made as to whether the certificate is valid. Such a determination may be made by checking the confirmation salt i.e. checking that r = H1(hU∥infoU). If so, the certificate is accepted as valid. [0031] The performance of the protocol presented herein for implicit certificates may be evaluated by comparing the size of a public key plus the size of a signature to the size of the reconstruction value. Generally, if the reconstruction value is smaller, then the implicit certificate scheme is worthwhile. Public keys in FALCON consist of the value h, a polynomial in ℤq[x]/(ϕ), and for the FALCON-512 parameter set, the public keys are encoded in 897 bytes. Meanwhile, signatures consist of the 40-byte value r and an encoded short vector s, for a total of 666 bytes, such the short vector is allotted 626 bytes. Accordingly, the total length of a public key and a signature is 1563 bytes. [0032] The reconstruction value consists of a 40-byte r, and two encoded short vectors s1, s2 for a total of 2 · 626 + 40 = 1292 bytes, which represents a savings of 271 bytes (i.e., 1563 bytes – 1292 bytes). This savings helps with maintaining the frame size of a basic safety message below the 2304 bytes. In [2] the authors note that the total size of a frame that includes an explicit certificate with FALCON signatures is 2329 bytes, meaning that a 271-byte savings keeps the critical threshold from being exceeded. [0033] With respect to the security of the protocol presented herein, generally, an adversary is said to compromise the security of the implicit certificate scheme if they can generate a reconstruction value and a message-signature pair such that the message-signature pair validates under the reconstructed public key. Show below is a straightforward reduction to the SIS (short integer solution) problem with respect to the CA’s public key hCA. [0034] For an adversary to break the system, the adversary must eventually submit a reconstruction value R_U = ^^₂ ^∗,, info^* _U), a message msg^* and a signature σ^*, such that: [0035] (i) the reconstruction protocol successfully produces a public key h* [0036] (ii) the message-signature pair validates with respect to h^*. [0037] (iii) no certificate provisioning request (h^*, ^^ ^^ ^^ ^^ _^ ^∗ ^ ) was made to the CA. [0038] Following the proof technique of the GPV08 framework [3], random oracles H₁, H₂ are modeled in the following way: Whenever the adversary makes a query of the form H₁(h∥info), with h ∈ R. [0039] Figure 4 is a simplified block diagram of a signer device or public key originator 12 and a certificate authority device 18. Signer device 12 is able to perform one or more of the example methods illustrated in Figure 2. Signer device 12 comprises a processor 302 which is coupled to a memory 304 and to a communication interface 306. Certificate authority device 18 is able to perform one or more of the example methods illustrated in Figure 2. Certificate authority device 18 comprises a processor 302 which is coupled to a memory 304 and to a communication interface 306. The signer device 12 or the certificate authority device 18 may contain other elements which, for clarity, are not shown in Figure 4. [0040] Processors 302 and 304 may comprise any combination of processing units, digital signal processors, hardware accelerators, and the like. All or part of memory 304 may be embedded in processor 302, and all or part of memory 304 may be embedded in processor 302. [0041] Each of the devices 12, 18 can operate as a standalone devices or are connected (e.g., networked) to other machines. In a networked deployment, devices 12, 18 can operate in the capacity of a server machine, a client machine, or both in server-client network environments. In an example, the device 12 or 18 can act as a peer machine in peer-to-peer (P2P) (or other distributed) network environment. The device 12 or 18 may be a personal computer (PC), a web appliance, a network router, switch or bridge, a server computer, or any machine capable of executing instructions (sequential or otherwise) that specify actions to be taken by that machine. In various embodiments, device 12 or 18 can perform one or more of the processes described above. Further, device 12 or 18 may include any collection of machines that individually or jointly execute a set (or multiple sets) of instructions to perform any one or more of the methodologies discussed herein, such as cloud computing, software as a service (SaaS), other computer cluster configurations. [0042] Examples, as described herein, can include, or can operate on, logic or a number of components, modules, or mechanisms (all referred to hereinafter as “modules”). Modules are tangible entities (e.g., hardware) capable of performing specified operations and is configured or arranged in a certain manner. In an example, circuits are arranged (e.g., internally or with respect to external entities such as other circuits) in a specified manner as a module. In an example, the whole or part of one or more computer systems (e.g., a standalone, client or server computer system) or one or more hardware processors are configured by firmware or software (e.g., instructions, an application portion, or an application) as a module that operates to perform specified operations. In an example, the software can reside on a non- transitory computer readable storage medium or other machine-readable medium. In an example, the software, when executed by the underlying hardware of the module, causes the hardware to perform the specified operations. [0043] Accordingly, the term “module” is understood to encompass a tangible entity, be that an entity that is physically constructed, specifically configured (e.g., hardwired), or temporarily (e.g., transitorily) configured (e.g., programmed) to operate in a specified manner or to perform part or all of any operation described herein. Considering examples in which modules are temporarily configured, each of the modules need not be instantiated at any one moment in time. For example, where the modules comprise a general-purpose hardware processor configured using software, the general-purpose hardware processor is configured as respective different modules at different times. Software can accordingly configure a hardware processor, for example, to constitute a particular module at one instance of time and to constitute a different module at a different instance of time. [0044] Device 12 or 18 can include a hardware processor 302 (e.g., a central processing unit (CPU), a graphics processing unit (GPU), a hardware processor core, or any combination thereof), a memory 304, some or all of which can communicate with each other via an interlink 308 (e.g., bus). Device 12 or 18 can further include a display unit, an alphanumeric input device (e.g., a keyboard), and a user interface (UI) navigation device (e.g., a mouse). In an example, the display unit, input device and UI navigation device are a touch screen display. Device 12 or 18 can additionally include a storage device (e.g., drive unit), a signal generation device (e.g., a speaker). Device 12 or 18 can include an output controller, such as a serial (e.g., universal serial bus (USB), parallel, or other wired or wireless (e.g., infrared (IR), near field communication (NFC), etc.) connection to communicate or control one or more peripheral devices (e.g., a printer, card reader, etc.). [0045] Memory device 304 can include a machine readable medium on which is stored one or more sets of data structures or instructions (e.g., software) embodying or utilized by any one or more of the techniques or functions described herein. The instructions can also reside, completely or at least partially, within the memory 304, or within the hardware processor 302 during execution thereof by the device 12 or 18. In an example, one or any combination of the hardware processor 302, the memory 304 or the storage device can constitute machine readable media. The term "machine readable medium" can include a single medium or multiple media (e.g., a centralized or distributed database, and/or associated caches and servers) configured to store the one or more instructions. In addition, the memory 304 may store messages, signed messages, public key, secret keys, certificates, and the various parameters required to generate the public key and the secret keys. [0046] Memory 304 stores parameters that have been agreed on by signer device 12 and certificate authority device 18, such as encryption method, one or more key derivation functions, one or more hash functions, one or more functions associated with a signature scheme to be implemented, as well as parameters associated with the signature scheme, such as a prerequisite length L of a message authentication code. Memory 304 may store additional elements. [0047] The term “machine readable medium” can include any medium that is capable of storing, encoding, or carrying instructions for execution by the device 12 or 18 and that cause the machine device 12 or 18 to perform any one or more of the techniques of the present disclosure, or that is capable of storing, encoding, or carrying data structures used by or associated with such instructions. Nonlimiting machine- readable medium examples can include solid-state memories, and optical and magnetic media. Specific examples of machine-readable media can include: non- volatile memory, such as semiconductor memory devices (e.g., Electrically Programmable Read-Only Memory (EPROM), Electrically Erasable Programmable Read-Only Memory (EEPROM)) and flash memory devices; magnetic disks, such as internal hard disks and removable disks; magneto-optical disks; Random Access Memory (RAM); Solid State Drives (SSD); and CD-ROM and DVD-ROM disks. In some examples, machine readable media can include non-transitory machine-readable media. In some examples, machine readable media can include machine readable media that is not a transitory propagating signal. [0048] The instructions from device 12 or 18 can further be transmitted or received over a communications network using a transmission medium via the communication interface device 306. The device 12 or 18 can communicate with one or more other machines utilizing any one of a number of transfer protocols (e.g., frame relay, internet protocol (IP), transmission control protocol (TCP), user datagram protocol (UDP), hypertext transfer protocol (HTTP), etc.). Example communication networks can include a local area network (LAN), a wide area network (WAN), a packet data network (e.g., the Internet), mobile telephone networks (e.g., cellular networks), Plain Old Telephone (POTS) networks, and wireless data networks (e.g., Institute of Electrical and Electronics Engineers (IEEE) 602.11 family of standards known as Wi-Fi®, IEEE 602.16 family of standards known as WiMax®), IEEE 602.15.4 family of standards, a Long Term Evolution (LTE) family of standards, a Universal Mobile Telecommunications System (UMTS) family of standards, peer-to- peer (P2P) networks, among others. In an example, the communication interface device 306 can include one or more physical jacks (e.g., Ethernet, coaxial, or phonejacks) or one or more antennas to connect to the communications network. In an example, the communication interface device 306 can include a plurality of antennas to wirelessly communicate using at least one of single-input multiple-output (SIMO), multiple-input multiple-output (MIMO), or multiple-input single-output (MISO) techniques. In some examples, the communication interface device 306 can wirelessly communicate using Multiple User MIMO techniques. [0049] Examples, as described herein, can include, or can operate on, logic or a number of components, modules, or mechanisms. Modules are tangible entities (e.g., hardware) capable of performing specified operations and are configured or arranged in a certain manner. In an example, circuits are arranged (e.g., internally or with respect to external entities such as other circuits) in a specified manner as a module. In an example, the whole or part of one or more computer systems (e.g., a standalone, client, or server computer system) or one or more hardware processors are configured by firmware or software (e.g., instructions, an application portion, or an application) as a module that operates to perform specified operations. In an example, the software can reside on a machine-readable medium. In an example, the software, when executed by the underlying hardware of the module, causes the hardware to perform the specified operations. [0050] Various embodiments are implemented fully or partially in software and/or firmware. This software and/or firmware can take the form of instructions contained in or on a non-transitory computer-readable storage medium. Those instructions can then be read and executed by one or more processors to enable performance of the operations described herein. The instructions are in any suitable form, such as but not limited to source code, compiled code, interpreted code, executable code, static code, dynamic code, and the like. Such a computer-readable medium can include any tangible non-transitory medium for storing information in a form readable by one or more computers, such as but not limited to read only memory (ROM); random access memory (RAM); magnetic disk storage media; optical storage media; flash memory; etc. [0051] While this specification contains many specific implementation details, these should not be construed as limitations on the scope of any invention or on the scope of what may be claimed, but rather as descriptions of features that may be specific to particular implementations of particular inventions. Certain features that are described in this specification in the context of separate implementations can also be implemented in combination in a single implementation. Conversely, various features that are described in the context of a single implementation can also be implemented in multiple implementations separately or in any suitable sub- combination. Moreover, although features may be described above as acting in certain combinations and even initially claimed as such, one or more features from a claimed combination can in some cases be excised from the combination, and the claimed combination may be directed to a sub-combination or variation of a sub-combination. [0052] Accordingly, the above description of example implementations does not define or constrain this disclosure. Other changes, substitutions, and alterations are also possible without departing from the spirit and scope of this disclosure. [0053] REFERENCES [1] Nina Bindel and Sarah McCarthy. The Need for Being Explicit: Failed At- tempts to Construct Implicit Certificates from Lattices.2022. [2] Nina Bindel, Sarah McCarthy, Geoff Twardokus, and Hanif Rahbari. Drive (Quantum) Safe! – Towards Post-Quantum Security for V2V Communications. 2022. [3] Craig Gentry, Chris Peikert, and Vinod Vaikuntanathan. Trapdoors for Hard Lattices and New Cryptographic Constructions.2008.

Claims

CLAIMS: 1. A post-quantum implicit certificate method for signing a message, the method comprising the following steps implemented using at least one processor- based system: at a public key originator, generating a message attesting to identity (msg) and a FALCON public key (hU), and signing the message using the FALCON public key (h_U) to generate a signature; sending the public key, the message, and the signature to a certificate authority; and at the certificate authority, verifying the signature on the message attesting to the identity (msg), and generating a reconstruction value for the public key using certificate authority’s own secret key; at a verifier, using the reconstruction value and the certificate authority’s public key to generate the public key (h_U). 2. The method of claim 1, wherein signing comprises hashing the message to a single vector c on a lattice, inverting the function, and finding two short vectors (s₁, s₂) in ℤ [x]/( ^^) that map to the single vector c. 3. The method of claim 2, wherein verifying the signature on the message comprises a step of determining whether the least one condition is met. 4. The method of claim 3, wherein generating a reconstruction value for the public key comprises at least the following steps: at the certificate authority, generating a certificate comprising first information (info_U); generating a bit string r ← H₁(h_U∥info_U), wherein r is the random value salt, and computing c = H₂(r∥info_U) with a secret key of the certificate authority (sk_CA); computing a value of the two short vectors (s₁, s₂) ← FalconSample (c+ h_U mod q, skCA); compressing the si values,; whereby the certificate comprises the first information, value r and the encoded short vectors (s1, s2), and whereby the message originator uses its secret key. 5. The method of claim 4, wherein the verifier accepts the signature of the message originator by followings at least steps of: receiving the signed message; reconstructing the message originator’s public key from the certificate by decompressing the si values to full polynomials, computing the public key (hU ← s1 + determining the validity of the certificate by checking the random value salt (r), wherein when r = H1(hU∥infoU) then the certificate is valid, else the certificate is invalid. 6. The method of claim 5, wherein the public key for the FALCON-512 parameter set is encoded in 897 bytes, and the signature consists a 40-byte value r and an encoded short vector s of 626 bytes, such that the public key and the signature have a combined total length of 1563 bytes. 7. The method of claim 6, wherein the reconstruction value consists of the 40-byte value r, and two encoded short vectors (s1, s2) for a total length of 1292 bytes, thereby representing a payload savings of 271 bytes, and thereby maintaining a frame size below a predefined threshold. 8. A public key originator device configurable to generate a message attesting to identity (msg), the public key originator device comprising: a processor; a communication interface coupled to the processor; a memory device coupled to the processor, the memory device storing instructions which, when executed by the processor, is arranged to: sign the message using the FALCON public key (hU) to generate a signature; send the public key, the message, and the signature via the communication interface to a certificate authority which verifies the signature on the message attesting to the identity, and generate a reconstruction value for the public key using the certificate authority own secret key. 9. The message originator device of claim 8, wherein the public key is a long basis of a q-ary lattice and comprises a private key being a short basis of the same lattice. 10. The message originator device of claim 9, wherein applying the signature comprises hashing the message to a single vector c on the lattice, inverting the function, and finding two short vectors (s₁, s₂) in ℤ [x]/( ^^) that map to the single vector c. 11. The message originator device of claim 10, wherein the public key for the FALCON-512 parameter set is encoded in 897 bytes, and the signature consists a 40-byte value r and an encoded short vector s of 626 bytes, such that the public key and the signature have a combined total length of 1563 bytes. 12. A certificate authority configurable to generate a reconstruction value for a public key of a public key originator, the certificate authority comprising: a processor; a communication interface coupled to the processor; a memory device coupled to the processor, the memory device storing instructions which, when executed by the processor, is arranged to: generate a certificate comprising first information (info_U); generate a bit string r ← H₁(h_U∥info_U), wherein r is a random value salt, and compute a single vector c on the lattice c = H2(r∥infoU) with a secret key of the certificate authority device (sk_CA); compute a value of the two short vectors (s₁, s₂) ← FalconSample (c+ h_U mod q, skCA); compress the si values; whereby the certificate comprises the first information, value r and the encoded short vectors (s1, s2). 13. The certificate authority of claim 12, wherein a third party or verifier accepts the signature of the public key originator device by followings at least steps of: reconstructing the public key originator device’s public key from the certificate by decompressing the s_i values to full polynomials, computing the public key (h_U ← s₁ + s₂h_CA − H₂(r∥info_U); and determining the validity of the certificate by checking the random value salt (r), wherein when r = H₁(h_U∥info_U) then the certificate is valid, else the certificate is invalid. 14. The certificate authority of claim 13, wherein the public key for the FALCON- 512 parameter set is encoded in 897 bytes, and the signature consists a 40-byte value r and an encoded short vector s of 626 bytes, such that the public key and the signature have a combined total length of 1563 bytes. 15. The certificate authority device of claim 14, wherein the reconstruction value consists of the 40-byte value r, and two encoded short vectors (s1, s2) for a total length of 1292 bytes, thereby representing a payload savings of 271 bytes, and thereby maintaining a frame size below a predefined threshold.