Description:DESCRIPTION
Technical Field
[001] This disclosure relates generally to cryptography, and more particularly to method and system for structurally validating Post-Quantum Cryptographic (PQC) assets.
Background
[002] In today’s world, an emergence of quantum computing presents an existential threat to traditional cryptographic approaches such as Rivest–Shamir–Adleman (RSA), Elliptic Curve Cryptography (ECC), and discrete logarithm-based approaches. To mitigate this risk, a National Institute of Standards and Technology (NIST) has standardized Post-Quantum Cryptographic (PQC) algorithms, including CRYSTALS-Kyber, CRYSTALS-Dilithium, Falcon, and SPHINCS+. Organizations worldwide have begun migrating to these standardized PQC algorithms in preparation for a quantum era. With this transition, there emerges a critical need to verify that cryptographic implementations are constructed in a secure manner and provide genuine resistance against quantum adversaries.
[003] However, existing validation approaches for PQC assets are not sufficient to guarantee a true security of PQC algorithm implementations. These existing validation approaches such as certificate chain verification, expiration checking, binary hash fingerprints, and Object Identifier (OID) inspection only verify surface-level integrity or metadata of the PQC assets. In other words, the problem lies in the inability of existing validation approaches to verify whether cryptographic assets that claim PQC algorithms compliance are indeed constructed using secure, standardized mathematical parameters. For example, certificates may include metadata or OID tags declaring PQC algorithms, while in reality the underlying implementation may use weakened or non-standard parameters. Similarly, polynomial coefficients in lattice-based schemes may be tampered at a coefficient level without detection, and different vendors may introduce non-standard parameter sets that weaken security. In addition, in hybrid deployments that combine PQC algorithms with classical algorithms, there is no reliable mechanism to validate the true quantum-resistant components.
[004] A core challenge arises because PQC algorithms are mathematically more complex than traditional cryptographic approaches, e.g., the RSA, the ECC, etc. While validation in the RSA or the ECC can be achieved by checking modulus properties or curve correctness, PQC algorithm schemes rely on intricate structures such as polynomial coefficients, modular arithmetic, matrix dimensions, hash-based tree structures, and compression or encoding schemes. These complexities make it possible to conceal subtle manipulations that cannot be identified through existing validation approaches. As a result, organizations face a significant compliance blind spot. They lack the ability to reliably audit their cryptographic infrastructure or prove its readiness against quantum-enabled adversaries. This gap leaves systems vulnerable to hidden weaknesses and undermines confidence in the ongoing migration to PQC standards.
[005] Thus, the exiting techniques in the present state of art fails to address the problem of structually validating the PQC assets.
SUMMARY
[006] In one embodiment, a method for structurally validating Post-Quantum Cryptographic (PQC) assets is disclosed. In one example, the method may include extracting a set of mathematical parameters from a PQC asset using a set of parsing rules pre-defined for a PQC algorithm associated with the PQC asset. The method may further include applying a normalization technique to the set of mathematical parameters to generate a standardized set of mathematical parameters consistent across a plurality of vendor-specific implementations of the PQC algorithm. The method may further include generating a structural fingerprint corresponding to the standardized set of mathematical parameters associated with the PQC asset using a pre-defined hashing algorithm. The method may further include associating the structural fingerprint with the PQC asset to perform real-time structural validation of the PQC asset. It may be noted that the real-time structural validation of the PQC asset is performed based on user requirements.
[007] In another embodiment, a system for structurally validating Post-Quantum Cryptographic (PQC) assets is disclosed. The system may include a processor and a memory communicatively coupled to the processor. The memory may store processor-executable instructions, which, on execution, may cause the processor to extract a set of mathematical parameters from a PQC asset using a set of parsing rules pre-defined for a PQC algorithm associated with the PQC asset. The processor-executable instructions, on execution, may further cause the processor to apply a normalization technique to the set of mathematical parameters to generate a standardized set of mathematical parameters consistent across a plurality of vendor-specific implementations of the PQC algorithm. The processor-executable instructions, on execution, may further cause the processor to generate a structural fingerprint corresponding to the standardized set of mathematical parameters associated with the PQC asset using a pre-defined hashing algorithm. The processor-executable instructions, on execution, may further cause the processor to associate the structural fingerprint with the PQC asset to perform real-time structural validation of the PQC asset. It should be noted that the real-time structural validation of the PQC asset is performed based on user requirements.
[008] It is to be understood that both the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the invention, as claimed.

BRIEF DESCRIPTION OF THE DRAWINGS
[009] The accompanying drawings, which are incorporated in and constitute a part of this disclosure, illustrate exemplary embodiments and, together with the description, serve to explain the disclosed principles.
[010] FIG. 1 is a block diagram of an exemplary system configured for structurally validating Post-Quantum Cryptographic (PQC) assets, in accordance with some embodiments of the present disclosure.
[011] FIG. 2 illustrates a functional block diagram of various modules within a memory of a computing device configured to structurally validate PQC assets, in accordance with some embodiments of the present disclosure.
[012] FIG. 3 illustrates a flow diagram of an exemplary process for structurally validating PQC assets, in accordance with some embodiments of the present disclosure.
[013] FIG. 4 illustrates a flow diagram of an exemplary process for extracting a set of mathematical parameters from a PQC asset, in accordance with some embodiments of the present disclosure.
[014] FIG. 5 illustrates a flow diagram of an exemplary process for performing real-time structural validation of the PQC asset, in accordance with some embodiments of the present disclosure.
[015] FIG. 6 illustrates a detailed flow diagram of an exemplary process for extracting a set of mathematical parameters from a PQC asset, in accordance with some embodiments of the present disclosure.
[016] FIG. 7 illustrates an exemplary flow diagram depicting a predefined set of normalization rules of a canonical normalization technique, in accordance with some embodiments of the present disclosure.
[017] FIG. 8 illustrates a detailed flow diagram of an exemplary process of generating a structural fingerprint, in accordance with some embodiments of the present disclosure.
[018] FIG. 9 illustrates a detailed flow diagram of an exemplary process for performing real-time structural validation of a PQC asset, in accordance with some embodiments of the present disclosure.
[019] FIG. 10 is an exemplary representation of a set of mathematical parameters extracted from a PQC asset configured with a CRYSTALS-Kyber algorithm, in accordance with some embodiments of the present disclosure.
[020] FIG. 11 is an exemplary representation of a set of mathematical parameters extracted from a PQC asset configured with a CRYSTALS-Dilithium algorithm, in accordance with some embodiments of the present disclosure.
[021] FIG. 12 is an exemplary representation of a set of mathematical parameters extracted from a PQC asset configured with a Falcon algorithm, in accordance with some embodiments of the present disclosure.
[022] FIG. 13 is an exemplary representation of a set of mathematical parameters extracted from a PQC asset configured with a SPHINCS+ algorithm, in accordance with some embodiments of the present disclosure.
[023] FIG. 14 is a block diagram of an exemplary computer system for implementing embodiments consistent with the present disclosure.
DETAILED DESCRIPTION
[024] Exemplary embodiments are described with reference to the accompanying drawings. Wherever convenient, the same reference numbers are used throughout the drawings to refer to the same or like parts. While examples and features of disclosed principles are described herein, modifications, adaptations, and other implementations are possible without departing from the spirit and scope of the disclosed embodiments. It is intended that the following detailed description be considered as exemplary only, with the true scope and spirit being indicated by the following claims.
[025] Referring now to FIG. 1, a block diagram of an exemplary system 100 configured for structurally validating Post-Quantum Cryptographic (PQC) assets is illustrated, in accordance with some embodiments of the present disclosure. As depicted via the present FIG. 1, the system 100 may include a computing device 102. The computing device 102 may be configured to structurally validate the PQC assets. A PQC asset refers to any cryptographic element, object, or component that is generated, stored, transmitted, or validated using PQC algorithms. Examples of the PQC asset may include, but is not limited to, a cryptographic key, a digital certificate, a signature, a protocol, and a software module or a hardware module that implements any PQC algorithm. A type of the PQC algorithm used for generating, storing, transmitting, or validating the PQC asset may include a CRYSTALS-Kyber algorithm, a CRYSTALS-Dilithium algorithm, a Falcon algorithm, a SPHINCS+ algorithm, and the like.
[026] In order to structurally validate the PQC assets, initially, the computing device 102 may be configured to extract a set of mathematical parameters from a PQC asset. The set of mathematical parameters may be extracted using a set of parsing rules pre-defined for a PQC algorithm associated with the PQC asset. In an embodiment, the set of parsing rules corresponding to each type of the PQC algorithm may be pre-defined by a national authority. For example, the national authority may be a National Institute of Standards and Technology (NIST). Other examples of the national authority apart from the NIST may include a Bundesamt für Sicherheit in der Informationstechnik (BSI), a Agence nationale de la sécurité des systèmes d'information (ANSSI), a Canadian Centre for Cyber Security (CCCS), a Communications Security Establishment (CSE), and the like.
[027] In an embodiment, the set of mathematical parameters may correpond to underlying numerical and structural values that define security properties of the PQC asset. The set of mathematical parameters are specific to the type of the PQC algorithm and directly determine strength and correctness of the PQC algorithm implementation. For example, in lattice-based schemes such as the CRYSTALS-Kyber algorithm and the CRYSTALS-Dilithium algorithm, the set of mathematical parameters may include polynomial coefficients, modulus values, matrix dimensions, and error distribution values. In code-based schemes such as the Falcon algorithm, the set of mathematical parameters may include a generator matrix, a parity-check matrix, and an error weight, while in multivariate polynomial schemes, the set of mathematical parameters may involve degree of polynomials, number of variables, and coefficient ranges. In hash-based signatures such as the SPHINCS+ algorithm, the set of mathematical parameters may include tree height, leaf size, Winternitz parameter, and hash function identifiers
[028] In an embodiment, the set of parsing rules may correspond to predefined instructions or logical steps used by the computing device 102 to extract and interpret the set of mathematical parameters embedded in the PQC asset. The set of parsing rules may be specific to the type of the PQC algorithm and ensures that the set of mathematical parameters are read in a correct order, format, and representation according to standardized specifications, such as those defined by the NIST. For example, for a CRYSTALS-Kyber public key, the set of parsing rules may specify how to parse a key header, extract modulus values, vector length, and polynomial coefficients, and recover a matrix generation seed. For a CRYSTALS-Dilithium signature, the set of parsing rules may define how to parse a challenge polynomial, extract matrix dimensions, and separate random seeds from a signature. For a SPHINCS+ certificate, the set of parsing rules may describe how to read a Merkle tree height, the Winternitz parameter, and hash function identifiers from certificate fields. In the case of the Falcon algorithm or other code-based schemes, the set of parsing rules may include steps for parsing generator matrices, parity-check matrices, and error weights to ensure compliance with the PQC algorithm’s specification. A method of extracting the set of mathematical parameters has been further explained in detail in conjunction with FIG. 4 and FIG. 6.
[029] Once the set of mathematical parameters are extracted, the computing device 102 may be configured to apply a normalization technique to the set of mathematical parameters. The normalization technique may be applied to generate a standardized set of mathematical parameters consistent across a plurality of vendor-specific implementations of the PQC algorithm. In an embodiment, the plurality of vendor-specific implementations refers to multiple independent implementations of the same PQC algorithm developed by different vendors or organizations, which may vary in encoding, data structures, or internal representations while still adhering to specifications of the PQC algorithm. For example, different software libraries implementing the CRYSTALS-Kyber algorithm may store polynomial coefficients in varying binary formats. By way of another example, hardware security modules from different vendors implementing the CRYSTALS-Dilithium algorithm may use different memory layouts for keys and signatures. Similarly, certificates signed using the SPHINCS+ algorithm from multiple providers may encode the Merkle trees and hash parameters differently.
[030] In an embodiment, the normalization technique may be a canonical normalization technique. The canonical normalization technique may include a predefined set of normalization rules configured for generating the standardized set of mathematical parameters. In an embodiment, the canonical normalization technique may refer to a process of converting mathematically equivalent structures into identical, standardized representations regardless of implementation format or the plurality of vendor-specific implementations. The predefined set of normalization rules of the canonical normalization technique is further depicted and explained in conjunction with FIG. 7.
[031] Further, the computing device 102 may be configured to generate a structural fingerprint corresponding to the standardized set of mathematical parameters associated with the PQC asset using a pre-defined hashing algorithm. In an embodiment, the predefined hashing algorithm may be a cryptographic secure hashing algorithm including a quantum-resistant hash function. In an embodiment, the standardized set of mathematical parameters may refer to a uniform representation of the set of mathematical parameters of the PQC asset that looks the same across different vendor-specific implementations, i.e., the plurality of vendor-specific implementations. This standardized set of mathematical parameters allows accurate comparison, validation, and verification of the PQC asset against PQC algorithm specifications. Examples of the cryptographic secure hashing algorithm may include a Secure Hash Algorithm 2 (SHA-2), SHA-3, and the like. Further, examples of the quantum-resistant hash function may include a Secure Hash Algorithm Keccak Extendable-Output Function (SHAKE), a BLAKE3, and the like.
[032] Once the structural fingerprint is generated, the computing device 102 may be configured to associate the structural fingerprint with the PQC asset. The structural fingerprint may be associated with the PQC asset to perform real-time structural validation of the PQC asset. In an embodiment, associating the structural fingerprint to the PQC asset includes embedding the structural fingerprint within the PQC asset or linking the structural fingerprint to the PQC asset such that the structural fingerprint can be reliably used to perform real-time structural validation of the PQC asset. The real-time structural validation of the PQC asset is performed based on user requirements. In an embodiment, a user may correspond to an entity or a system responsible for managing, monitoring, or validating the PQC assets, such as a security officer, a system administrator, a cryptographic auditor, or an automated software module. Further, the user requirements, for example may include verifying PQC asset integrity, ensuring compliance with algorithm standards (e.g., NIST PQC specifications), and monitoring a security level of the PQC asset to detect any reduction in quantum resistance. A method of performing the real-time structural validation of the PQC asset is further explained in detail in conjunction with FIG. 5 and FIG. 9.
[033] In an embodiment, the computing device 102 may provide structural validation of PQC assets by extracting, analyzing, and generating structural fingerprints of underlying mathematical parameters (i.e., the set of mathematical parameters) that define cryptographic security. In contrast to conventional binary hash-based techniques, the computing device 102 may perform validation based on mathematical correctness and standards compliance of PQC algorithm implementations. Examples of the computing device 102 may include, but is not limited to, a mobile phone, a laptop, a desktop, or a PDA, an application server, and so forth. The computing device 102 may further include a memory 104, a processor 106, and an Input/Output unit 108. The I/O unit 108 may further include a user interface 110. The user or an administrator may interact with the computing device 102 and vice versa through the I/O unit 108.
[034] The I/O unit 108 may be used to display results (i.e., the set of mathematical parameters, the standardized set of mathematical parameters, the structural fingerprint, etc.) based on actions performed by the computing device 102, to the user. The user interface 110 may be used by the user to provide inputs to the computing device 102. Thus, for example, in some embodiment, the computing device 102 may ingest an input that includes a user input corresponding to the PQC asset. Further, for example, in some embodiments, the computing device 102 may render intermediate results (e.g., the set of mathematical parameters, the standardized set of mathematical parameters, the structural fingerprint, a real-time structural fingerprint, one or more anomalies corresponding to the PQC asset) or final results (e.g., the structural fingerprint or a report) to the user via the user interface 110.
[035] The memory 104 may store instructions that, when executed by the processor 106, may cause the processor 106 to structurally validate the PQC assets. As will be described in greater detail in conjunction with FIG. 2 to FIG. 13, in order structurally validate the PQC assets, the processor 106 in conjunction with the memory 104 may perform various functions including extracting the set of mathematical parameters, applying the normalization technique to the set of mathematical parameters, generating the structural fingerprint, associating the structural fingerprint with the PQC asset, etc.
[036] The memory 104 may also store various data (e.g., the set of mathematical parameters, the standardized set of mathematical parameters, the type of the PQC algorithm, the set of parsing rules, and the like) that may be captured, processed, and/or required by the computing device 102. The memory 104 may be a non-volatile memory (e.g., flash memory, Read Only Memory (ROM), Programmable ROM (PROM), Erasable PROM (EPROM), Electrically EPROM (EEPROM) memory, etc.) or a volatile memory (e.g., Dynamic Random Access Memory (DRAM), Static Random-Access memory (SRAM), etc.).
[037] Further, the computing device 102 may interact with the server 112 or external device 118 over a network 116 for sending and receiving various data. The network 116, for example, may be any wired or wireless communication network and the examples may include, but may be not limited to, the Internet, Wireless Local Area Network (WLAN), Wi-Fi, Long Term Evolution (LTE), Worldwide Interoperability for Microwave Access (WiMAX), and General Packet Radio Service (GPRS).
[038] In an embodiment, the computing device 102 may fetch the set of mathematical parameters associated with the PQC asset from the server 112. In addition, the server 112 may provide information, such as details about the structural fingerprint of the PQC asset, the type of PQC algorithm of the PQC asset to the user. The server 112 may further include a database 114. By way of an example, the database 114 may store information regarding the PQC assets. The database 114 may be periodically updated based on a new PQC asset. Alternatively, the computing device 102 may receive input from the user from external devices 118. Examples of the external device 118 may include, a laptop, a desktop, a smartphone, a tablet, and the like. This complete process followed by the system 100 is further explained in detail in conjunction with FIG. 2 to FIG. 13.
[039] Referring now to FIG. 2, a functional block diagram 200 of various modules within the memory 104 of the computing device 102 configured to structurally validate the PQC assets, in accordance with some embodiments of the present disclosure. FIG. 2 is explained in conjunction with FIG. 1. The memory 104 may include a mathematical parameter extraction model 204, a structural fingerprint generation module 206, a canonical normalization module 208, and a validation and integrity verification module 210.
[040] Initially, a PQC asset 202 may be provided as an input to the mathematical parameter extraction module 204. The PQC asset 202 may correspond to any cryptographic element, object, or component generated, stored, transmitted, or validated using the PQC algorithms. Examples of the PQC asset 202 may include, but are not limited to, the digital certificate, the cryptographic key, or the cryptographic token. Examples of the PQC algorithm may include the CRYSTALS-Kyber algorithm, the CRYSTALS-Dilithium algorithm, the Falcon algorithm, or the SPHINCS+ algorithm.
[041] In an embodiment, the mathematical parameter extraction module 204 may be configured to extract the set of mathematical parameters from the PQC asset 202 using the set of parsing rules predefined for the PQC algorithm associated with the PQC asset 202. For example, when the PQC asset 202 is a CRYSTALS-Kyber public key, the set of parsing rules predefined for the PQC algorithm (i.e., the CRYSTALS-Kyber algorithm) associated with the PQC asset 202 may include instruction on how to parse the key header, extract polynomial coefficients, modulus values, and matrix dimensions. In another example, when the PQC asset 202 is a SPHINCS+ certificate, the set of parsing rules predefined for the PQC algorithm (e.g., the SPHINCS+ algorithm) associated with the PQC asset 202 may describe how to extract the Winternitz parameter, the tree height, and the hash function identifiers. Once the set of mathematical parameters is extracted, the mathematical parameters extraction module 204 is configured to provide the set of mathematical parameters to a canonical normalization module 208.
[042] Upon receiving the set of mathematical parameters, the canonical normalization module 208. The canonical normalization module 208 is configured to apply the normalization technique to the set of mathematical parameters. The normalization technique may be applied to generate the standardized set of mathematical parameters. The standardized set of mathematical parameters may be consistent across the plurality of vendor-specific implementations of the PQC algorithm. In an embodiment, the normalization technique may be the canonical normalization technique. The canonical normalization technique may refer to the process of converting mathematically equivalent structures into identical, standardized representations regardless of implementation format or the plurality of vendor-specific implementations. Further, the plurality of vendor-specific implementations refers to multiple independent implementations of the same PQC algorithm developed by different vendors or organizations, which may vary in encoding, data structures, or internal representations while still adhering to specifications of the PQC algorithm. For example, the plurality of vendor-specific implementations of the CRYSTALS-Dilithium algorithm may store signatures in varying binary layouts, but by applying the canonical normalization technique, the canonical normalization module 208 ensures a uniform representation of the signatures across each of the plurality of vendor-specific implementations.
[043] Further, the standardized set of mathematical parameters may be provided by the canonical normalization module 208 to a structural fingerprint generation module 206. The canonical normalization module 208 may provide the standardized set of mathematical parameters to the structural fingerprint generation module 206 via the mathematical parameter extraction module 204. In some embodiments, the canonical normalization module 208 may directly provide the standardized set of mathematical parameters to the structural fingerprint generation module 206. Upon receiving the standardized set of mathematical parameters, the structural fingerprint generation module 206 may be configured to generate the structural fingerprint corresponding to the PQC asset 202 using the predefined hashing algorithm (i.e., the cryptographic secure hashing algorithm). The cryptographic secure hashing algorithm may include the quantum-resistant hash function. Examples of the cryptographic secure hashing algorithms may include SHA-2 or SHA-3 families, etc. Examples of the quantum-resistant hash function may include the SHAKE, the BLAKE3, etc.
[044] In an embodiment, the structural fingerprint of the PQC asset 202 may correspond to a unique, standardized cryptographic identifier generated from the standardized set of mathematical parameters of the PQC asset 202 that is independent of the plurality of vendor-specific implementations. The structural fingerprint serves as a consistent representation for validation and checking integrity of the PQC asset 202. For example, two CRYSTALS-Kyber public keys encoded differently by separate vendors after undergoing canonical normalization, yield the same structural fingerprint, thereby ensuring uniformity and interoperability across heterogeneous implementations. In an embodiment, the structural fingerprint for the PQC asset 202 may be expressed as a fixed-length hash string (e.g., a hexadecimal format or a base64 format) derived from the standardized mathematical parameters of the PQC asset 202. For example, the structural fingerprint generated for the two CRYSTALS-Kyber public keys using a SHA-3 cryptographic secure hashing algorithm may look like “3a4f9b6c1d827e56a8c3b92fdd4e2c7f0ab5198e6d447fbb29c5ef12a9b3d6f1”.
[045] Once the structural fingerprint is generated for the PQC asset 202, the structural fingerprint may be associated with the PQC asset 202 to structurally validate the PQC asset. To associate the structural fingerprint with the PQC asset 202, the structural fingerprint may be either embedded within the PQC asset 202 or linked to the PQC asset 202. In an embodiment, the structural fingerprint may be associated with the PQC asset 202 to perform the real-time structural validation of the PQC asset 202.
[046] In an embodiment, the real-time structural validation of the PQC asset 202 may be performed by the validation and integrity verification module 210. The validation and integrity verification module 210 may be configured to verify correctness and integrity of the PQC asset 202 by comparing the real-time structural fingerprint corresponding to the PQC asset 202 against the structured fingerprint associated with the PQC asset 202. In some embodiments, the structural fingerprint may be stored in a secure repository, e.g., the database 114. For example, when the PQC asset 202 is the CRYSTALS-Kyber public key distributed by a vendor, the structural fingerprint corresponding to the CRYSTALS-Kyber public key may be generated and embedded within the key metadata or linked to the CRYSTALS-Kyber public key via a secure reference. Further, during deployment, based on the user requirement, the validation and integrity verification module 210 may extract and normalize the set of mathematical parameters of the CRYSTALS-Kyber public key in real-time to generate the real-time structural fingerprint for the PQC asset 202. Further, the validation and integrity verification module 210 may compare the generated real-time structural fingerprint with the structural fingerprint associated with the PQC asset 202. In an embodiment, if both fingerprints match, the CRYSTALS-Kyber public key is structurally valid and compliant with standards defined by the national authority (e.g., the NIST) for the CRYSTALS-Kyber algorithm. In another embodiment, if both fingerprints differ, the CRYSTALS-Kyber public key may have been tampered with or encoded incorrectly. In this case, the computing device 102 may alert the user (e.g., a cryptographic auditor) about the tampering of the CRYSTALS-Kyber public key.
[047] It should be noted that all such aforementioned modules 204 – 210 may be represented as a single module or a combination of different modules. Further, as will be appreciated by those skilled in the art, each of the modules 204 – 210 may reside, in whole or in parts, on one device or multiple devices in communication with each other. In some embodiments, each of the modules 204 – 210 may be implemented as dedicated hardware circuit comprising custom application-specific integrated circuit (ASIC) or gate arrays, off-the-shelf semiconductors such as logic chips, transistors, or other discrete components. Each of the modules 204 – 210 may also be implemented in a programmable hardware device such as a field programmable gate array (FPGA), programmable array logic, programmable logic device, and so forth. Alternatively, each of the modules 204 – 210 may be implemented in software for execution by various types of processors (e.g., the processor 106). An identified module of executable code may, for instance, include one or more physical or logical blocks of computer instructions, which may, for instance, be organized as an object, procedure, function, or other construct. Nevertheless, the executables of an identified module or component need not be physically located together but may include disparate instructions stored in different locations which, when joined logically together, include the module and achieve the stated purpose of the module. Indeed, a module of executable code could be a single instruction, or many instructions, and may even be distributed over several different code segments, among different applications, and across several memory devices.
[048] As will be appreciated by one skilled in the art, a variety of processes may be employed for structurally validating the PQC assets. For example, the exemplary system 100 and the associated computing device 102 may structurally validate the PQC assets by the processes discussed herein. In particular, as will be appreciated by those of ordinary skill in the art, control logic and/or automated routines for performing the techniques and steps described herein may be implemented by the system 100 and the associated computing device 102, either by hardware, software, or combinations of hardware and software. For example, suitable code may be accessed and executed by the one or more processors on the system 100 to perform some or all of the techniques described herein. Similarly, application specific integrated circuits (ASICs) configured to perform some, or all of the processes described herein may be included in the one or more processors on the system 100.
[049] Referring now to FIG. 3, a flow diagram of an exemplary process 300 for structurally validating the PQC assets is depicted via a flowchart, in accordance with some embodiments of the present disclosure. FIG. 3 is explained in conjunction with FIGs. 1 and 2. Further, each step of the process 300 may be implemented by various modules present within the memory 104 of the computing device 102 of the system 100.
[050] In order to structurally validate the PQC assets, initially, at step 302, the set of mathematical parameters may be extracted from the PQC asset. The set of mathematical parameters may be extracted using the set of parsing rules pre-defined for the PQC algorithm associated with the PQC asset. The PQC asset may correspond to any cryptographic element, object, or component that is generated, stored, transmitted, or validated using the PQC algorithms. Examples of the PQC asset may include the cryptographic key, the digital certificate, the signature, the protocol, and the software module or the hardware module that implements any PQC algorithm. In an embodiment, the type of the PQC algorithm used for generating, storing, transmitting, or validating the PQC asset may include the CRYSTALS-Kyber algorithm, the CRYSTALS-Dilithium algorithm, the Falcon algorithm, the SPHINCS+ algorithm, and the like. With reference to FIG.2, the set of mathematical parameters may be extracted by the mathematical parameters extraction module 204. A method of extracting the set of mathematical parameters is further explained in detail in conjunction with FIG. 4.
[051] In an embodiment, the set of parsing rules used for extracting the set of mathematical parameters from the PQC asset may be pre-defined by the national authority according to the type of the PQC algorithm. For example, the national authority may be the NIST. Other examples of national authority apart from the NIST may include the BSI, the ANSSI, the CCCS, the CSE, and the like. In an embodiment, the set of mathematical parameters may correspond to underlying numerical and structural values that define security properties of the PQC asset. For example, in lattice-based schemes such as the CRYSTALS-Kyber algorithm and the CRYSTALS-Dilithium algorithm, the set of mathematical parameters may include the polynomial coefficients, the modulus, the matrix dimensions, the error distribution values, etc.
[052] Further, at step 304, the normalization technique may be applied to the set of mathematical parameters. The normalization technique may be applied to the set of mathematical parameters to generate the standardized set of mathematical parameters consistent across the plurality of vendor-specific implementations of the PQC algorithm. In an embodiment, the normalization technique is the canonical normalization technique. The canonical normalization technique includes the predefined set of normalization rules configured for generating the standardized set of mathematical parameters. In particular, the canonical normalization technique including the predefined set of normalization rules, may be applied on the set of mathematical parameters to produce a deterministic, vendor-agnostic representation (i.e., a standardized representation) for each of the set of mathematical parameters. Examples of the predefined set of normalization rules may include parameter ordering, encoding standardization, coefficient normalization, matrix representation, applying uniform endianness for multi-byte integers, removing implementation-specific padding or metadata, and the like. With reference to FIG.2, the normalization technique may be applied by the canonical normalization module 208.
[053] Once the standardized set of mathematical parameters are generated for the PQC asset, at step 306, the structural fingerprint may be generated corresponding to the standardized set of mathematical parameters associated with the PQC asset. The structural fingerprint is generated using the pre-defined hashing algorithm, i.e., the cryptographic secure hashing algorithm. The cryptographic secure hashing algorithm includes the quantum-resistant hash function. In other words, the structural fingerprint is generated over a canonical serialization of the standardized set of mathematical parameters using the cryptographically secure hash function. The canonical serialization specifies aspects such as byte order, field ordering, and omission of non-semantic encodings, thereby ensuring a deterministic and equivalent representation of the set of mathematical parameters across heterogeneous vendor implementations. With reference to FIG.2, the structural fingerprint may be generated by the structural fingerprint generation module 206.
[054] Examples of the cryptographic secure hashing algorithms may include SHA-2 or SHA-3 families. Examples of the quantum-resistant hash function may include the SHAKE, the BLAKE3, etc. In an embodiment, the quantum-resistant hash function may provide a security strength of 256 bits against Grover’s algorithm-based quantum attacks, ensure 512-bit collision resistance under classical security models, comply with NIST Federal Information Processing Standard Publication (FIPS) 202 standards, and produce deterministic outputs such that identical mathematical structures yield equivalent structural fingerprints across different cryptographic implementations. In particular, the cryptographically secure hashing algorithm is quantum-resistant, and domain separation is applied by employing an algorithm-specific prefix or context string to avoid cross-algorithm collisions. In an embodiment, the structural fingerprint generated for the PQC asset is bound to metadata including a cryptographic salt and a timestamp. The cryptographic salt may refer to a random value added to input data (i.e., the standardized set of mathematical parameters of the PQC asset) before or during a hashing process. The purpose of the cryptographic salt is to ensure that even if two PQC assets have identical standardized set of mathematical parameters, resulting structural fingerprints of the two PQC assets remain unique. The addition of the cryptographic salt to the structural fingerprint may prevent precomputation attacks (e.g., rainbow tables) and strengthen security. Further, the timestamp may be a time value recorded when the structural fingerprint is generated. The timestamp may provide temporal context, enabling validation of when the structural fingerprint was generated, and supporting lifecycle management (e.g., key expiration, revocation, or re-validation). In an embodiment, the generated structural fingerprint is stored in association with the PQC asset or in an external registry (i.e., the database 114).
[055] Once the structural fingerprint for the PQC asset is generated, at step 308, the generated structural fingerprint is associated with the PQC asset to perform real-time structural validation of the PQC asset. In an embodiment, the real-time structural validation of the PQC asset is performed based on the user requirements. The user requirements, for example, may include verifying PQC asset integrity, ensuring compliance with algorithm standards (e.g., the NIST PQC specifications), monitoring the security level of the PQC asset to detect any reduction in quantum resistance, and the like. In particular, the real-time structural validation of the PQC asset may be performed by the user based on his requirements (i.e., the user requirements) during certificate issuance, certificate validation, key exchange, code signing verification, or artifact attestation workflows. With reference to FIG.2, the real-time structural validation of the PQC asset may be performed by the validation and integrity verification module 210.
[056] In an embodiment, associating the structural fingerprint to the PQC asset includes embedding the structural fingerprint within the PQC asset or linking the structural fingerprint to the PQC asset such that the structural fingerprint can be reliably used to perform the real-time structural validation of the PQC asset. A method of performing the real-time structural validation of the PQC asset is further explained in detail in conjunction with FIG. 5 and FIG. 9.
[057] Referring now to FIG. 4, a flow diagram of an exemplary process 400 for extracting the set of mathematical parameters from the PQC asset is depicted via a flowchart, in accordance with some embodiments of the present disclosure. FIG. 4 is explained in conjunction with FIGS. 1 - 3. Each step of the process 400 may be implemented by the mathematical parameter extraction module 204 present within the memory 104 of the computing device 102.
[058] With reference to FIG. 3, in order to extract the set of mathematical parameters from the PQC asset as mentioned via step 302, initially, at step 402, the type of the PQC algorithm associated with the PQC asset. The type of the PQC algorithm may be one of the CRYSTALS-Kyber algorithm, the CRYSTALS-Dilithium algorithm, the Falcon algorithm, and the SPHINCS+ algorithm. In other words, the PQC asset may be generated using one of the CRYSTALS-Kyber algorithm, the CRYSTALS-Dilithium algorithm, the Falcon algorithm, and the SPHINCS+ algorithm. Upon identifying the type of the PQC algorithm associated with the PQC asset, at step 404, one or more mathematical parameters corresponding to the PQC asset may be identified based on the type of the PQC algorithm. Further, at step 406, the one or more mathematical parameters are validated based on the set of parsing rules pre-defined for the type of the PQC algorithm. In an embodiment, the one or more mathematical parameters are validated as per the set of parsing rules to detect mathematical parameters tampering. In order to validate the one or more mathematical parameters mathematical consistency checks, such as verifying polynomial coefficient ranges, ensuring matrix dimensions align with algorithm specification, and confirming that error distribution values are within expected statistical bounds, are performed. In other words, validating the one or more mathematical parameters may include checking whether values of the one or more mathematical parameters taken from the PQC asset are within limits, i.e., the algorithm standards (e.g., NIST PQC specifications), defined for that PQC algorithm. If any value of any mathematical parameter may fall outside those allowed limits, then that mathematical parameter is marked as invalid or flagged. In some embodiments, the PQC asset may be part of a hybrid cryptographic construct that includes both classical cryptographic components and PQC components. In such embodiment, the validation of the one or more mathematical parameters of the PQC asset may be performed independently from classical cryptographic metadata.
[059] Further, in response to validating, at step 408, the set of mathematical parameters are extracted from the PQC asset. In an embodiment, the set of parsing rules and corresponding parameters limits are based on specifications (e.g., the NIST PQC specifications) defined by a recognized standards body (i.e., the national authority), such as the NIST, including published parameter values and acceptable ranges. By way of example, when the PQC asset is the CRYSTALS-Kyber public key, the type of the PQC algorithm may be identified as the CRYSTALS-Kyber algorithm. Further, based on the type of the PQC algorithm, the one or more mathematical parameters may be determined for a Kyber scheme, such as the modulus values, the matrix dimensions, and the polynomial coefficients. Further, the one or more mathematical parameters are validated against the set of parsing rules pre-defined for the CRYSTALS-Kyber algorithm, for instance, confirming an expected byte ordering, header fields, and coefficient ranges. Upon successful validation, the set of mathematical parameters, e.g., the corresponding modulus, the matrix dimensions, and the polynomial coefficients are extracted from the one or more mathematical parameters that are determined for the CRYSTALS-Kyber public key.
[060] In some embodiments, to extract the set of mathematical parameters from the PQC asset, the set of mathematical parameters may be decoded from an encapsulation format selected from a group consisting of X.509 Public Key Infrastructure (X.509/PKIX) certificates, Concise Binary Object Representation (CBOR) and CBOR Object Signing and Encryption (COSE) structures, or binary artifacts used in secure transport protocols. For example, when the PQC asset is the SPHINCS+ certificate embedded within an X.509/PKIX certificate structure, the extraction may involve decoding the SPHINCS+ certificate fields to obtain corresponding mathematical parameters such as the tree height, the Winternitz parameter, and the hash function identifiers. By way of another example, when the PQC asset is the CRYSTALS-Kyber public key encoded in a CBOR/COSE structure, the extraction may include parsing a CBOR map and retrieving corresponding mathematical parameters such as the polynomial coefficients, the modulus, and the matrix dimensions. In an embodiment, an extraction process for the set of mathematical parameters may support a variety of encapsulation formats, ensuring compatibility of a structural validation device (e.g., the computing device) with widely adopted cryptographic standards and transport mechanisms.
[061] Referring now to FIG. 5, a flow diagram of an exemplary process 500 for performing the real-time structural validation of the PQC asset is depicted via a flowchart, in accordance with some embodiments of the present disclosure. FIG. 5 is explained in conjunction with FIGS. 1 – 4. Each step of the process 500 may be implemented using the validation and integrity verification module 210 within the memory 104 of the computing device 102. With reference to FIG. 3, in order to perform the real-time structural validation of the PQC asset, initially, at step 502, the real-time structural fingerprint corresponding to the PQC asset may be generated. In an embodiment, the real-time structural fingerprint may be generated using a similar method used for generating the structural fingerprint. In other words, to generate the real-time structural fingerprint for the PQC asset, a set of mathematical parameters associated with the PQC asset may be extracted in real-time. Further, the real-time set of mathematical parameters may be normalized by applying the canonical normalization technique to generate a standardized set of mathematical parameters for the PQC asset based on which the real-time structural fingerprint may be generated.
[062] Once the real-time structural fingerprint is generated, at step 504, the associated structural fingerprint corresponding to the PQC asset may be retrieved. In particular, the structural fingerprint that was initially generated and associated with the PQC asset may be retrieved. In an embodiment, the associated structural fingerprint may be retrieved from the PQC asset. In another embodiment, the associated structural fingerprint may be retrieved from the external repository (e.g., the database 114) associated with PQC asset. In an embodiment, the real-time structural fingerprint of the PQC asset may be also referred to as a regenerated fingerprint and the associated structural fingerprint may be also referred to as a reference fingerprint.
[063] Upon retrieving the associated structural fingerprint, at step 506, the real-time structural fingerprint of the PQC asset is compared with the associated structural fingerprint of the PQC asset. In an embodiment, the real-time structural fingerprint of the PQC asset is compared with the associated structural fingerprint to identify any mismatch between the real-time structural fingerprint and the associated structural fingerprint. In an embodiment, the comparison of the real-time structural fingerprint with the associated structural fingerprint is performed using a constant-time comparison and a timing-safe comparison to mitigate side-channel leakage.
[064] In an embodiment, the constant-time comparison may refer to a computational technique where two data values are compared in such a way that an execution time of the comparison of the two data values remains identical regardless of a location or a number of mismatches between the two data values. The constant-time comparison prevents information leakage through execution time differences. The timing-safe comparison may refer to a secure comparison mechanism designed to ensure that no observable variations in the execution time can be exploited by an adversary to infer partial knowledge of a secret value. The timing-safe comparison thus mitigates risks of timing-based side-channel attacks. Further, the side-channel leakage may refer to an unintended disclosure of sensitive information through observable characteristics of a system’s operation, such as execution time, power consumption, or electromagnetic emissions, rather than through a direct output of a cryptographic algorithm, i.e., the PQC algorithm.
[065] Further, in response to comparing, at step 508, the PQC asset may be validated. In an embodiment, the validation of the PQC asset may be performed according to policy-defined validation criteria. The policy-defined validation criteria may refer to a configurable set of rules and requirements established by the national authority (e.g., NIST) that dictate how correctness, integrity, and compliance of the PQC asset must be validated. Examples of the policy-defined validation criteria may include an algorithm compliance, structural integrity, lifecycle policies, security thresholds (e.g., minimum key size), and the like.
[066] In order to validate the PQC asset, in response to comparing upon identifying the mismatch, the one or more anomalies corresponding to the PQC asset may be detected. In an embodiment, the one or more anomalies may include, but are not limited to, coefficient manipulation, mathematical parameters substitution, encoding attacks, downgrade attacks, and non-compliant PQC implementations. Upon detecting the one or more anomalies, a report corresponding to the PQC asset may be generated based on the one or more anomalies. In an embodiment, the report may include detailed information about the one or more anomalies. For example, the detailed information corresponding to the one or more anomalies may include a type of an anomaly (e.g., coefficient manipulation, parameter substitution, etc.), a location within the PQC asset where the anomaly was identified (e.g., a specific field, a byte offset, or a parameter set), a severity level (or an impact level) of the anomaly with respect to compliance, security, and operational reliability, and the like. Upon generating the report, the generated report may be rendered to the user via a Graphical User Interface (GUI). In some embodiments, the generated report may be rendered to the user via an Application Programming Interface (API). In an embodiment, the user may correspond to the entity or the system responsible for managing, monitoring, or validating the PQC asset, such as the security officer, the system administrator, the cryptographic auditor, or the automated software module.
[067] Referring now to FIG. 6, a detailed flow diagram of an exemplary process 600 for extracting the set of mathematical parameters from the PQC asset is depicted via a flowchart, in accordance with some embodiments of the present disclosure. FIG. 6 is explained in conjunction with FIGS. 1 – 5. Each step of the process 600 may be implemented using the mathematical parameter extraction module 204 within the memory 104 of the computing device 102.
[068] At step 602, a PQC asset, such as a binary certificate or a key may be received as an input. The PQC asset may be encapsulated in the encapsulation format including, but not limited to, the X.509/PKIX certificate, the CBOR/COSE structure, or the binary artifact used in secure transport protocols. Upon receiving the PQC asset as the input, at step 604, the type of the PQC algorithm associated with the PQC asset is identified. The type of the PQC algorithm may include one of the CRYSTALS-Kyber algorithm, the CRYSTALS-Dilithium algorithm, the Falcon algorithm, or the SPHINCS+ algorithm. In some embodiments, the encapsulation format is decoded to determine the type of the PQC algorithm prior to extraction.
[069] In one embodiment, when the PQC algorithm associated with the PQC asset corresponds to the CRYSTALS-Dilithium algorithm, at step 606, mathematical parameters such as polynomial coefficients, modulus values, matrix dimensions, and seeds are identified. In another embodiment, when the PQC algorithm associated with the PQC asset corresponds to the CRYSTALS-Kyber algorithm, at step 608, mathematical parameters such as signature parameters, matrix dimensions, and power-of-two rounding factors are identified. Similarly, when the PQC algorithm associated with the PQC asset corresponds to the Falcon algorithm, at step 610, mathematical parameters such as Nth-degree Truncated polynomial Ring Unit (NTRU) polynomials, Fast Fourier Transform (FFT) parameters, and hash values modulo ‘q’ are identified. Further, when the PQC algorithm associated with the PQC asset corresponds to the SPHINCS+ algorithm, at step 612, mathematical parameters such as tree structure, Winternitz One-Time Signature (WOTS+) parameters, Forest of Random Subsets (FORS) parameters, and hash function identifiers are identified.
[070] Once the mathematical parameters (i.e., the one or more mathematical parameters) corresponding to the PQC asset, are identified based on the type of the PQC algorithm, at step 614, the one or more identified mathematical parameters are validated against the set of parsing rules pre-defined for the type of the PQC algorithm. The set of pre-defined parsing rules may include bounds checking (e.g., coefficient ranges) compliance with specifications published by the national authority (e.g., NIST), and enforcement of security levels. In some embodiments, mathematical consistency checks, such as ensuring matrix dimensions align with algorithm specification or verifying statistical distribution of error terms, may be performed to detect tampering. Upon successful validation, at step 616, the one or more mathematical parameters are serialized into a structured output, representing normalized parameters, i.e., the set of mathematical parameters.
[071] Referring now to FIG. 7, an exemplary flow diagram 700 depicting the predefined set of normalization rules of the canonical normalization technique is illustrated, in accordance with some embodiments of the present disclosure. FIG. 7 is explained in conjunction with FIGS. 1 – 6. Each step of the process 700 may be implemented using the canonical normalization module 208 within the memory 104 of the computing device 102.
[072] In FIG. 7, the flow diagram 700 shows an input 702, a process 704, and an output 706. The input 702 may represent various vendor-specific implementations 708 (i.e., the plurality of vendor-specific implementation). For example, as depicted, the various vendor-specific implementations 708 may include an Open Secure Socket Layer (SSL) format Distinguished Encoding Rules (DER) encoding (Abstract Syntax Notation One (ASN.1)) 708-2, a BouncyCastle custom binary layout 708-4, a Microsoft Cryptography Next Generation (CNG) proprietary structure 708-6, a hardware Security Module (HSM) vendor-specific format 708-8, and other formats representing the same underlying mathematical constructs 708-10. These diverse input formats highlight heterogeneity in how cryptographic or mathematical data (i.e., the set of mathematical parameters) may be represented prior to normalization.
[073] Further, the input 702 may be processed using the process 704. The process 704 illustrates normalization rules 710 (i.e., the predefined set of normalization rules) that applied to convert the input 702 in the various vendor-specific implementations 708 into a unified canonical form, i.e., the standardized set of mathematical parameters. For example, as depicted, the normalization rules 710 may include a parameter ordering (i.e., canonical sequence) 710-2, which ensures a consistent order of parameters. The normalization rules 710 may include an encoding standardization (Little-Endian) 710-4 that is used to normalize encoding format. The normalization rules 710 may further include a coefficient normalization (i.e., reduced form) 710-6 to standardize coefficients. The normalization rules 710 may include a matrix representation (i.e., standard form) 710-8 to represent data uniformly in matrix form. The normalization rules 710 may further include a metadata stripping (i.e., Pure Mathematics) 710-10 that is configured to remove vendor-specific or extraneous metadata. Lastly, the normalization rules 710 may include a security level verification 710-12 to ensure compliance with security requirements.
[074] Further, based on processing the input 702 according to the normalization rules 710, the output 706 may be generated. As represented via the output 706, an identical canonical form 712 with a standardized structure 714 may be generated for the various vendor-specific implementations 708 of the set of mathematical parameters. In other words, the standardized set of mathematical parameters are generated by processing the set of mathematical parameters according to the normalization rules 710. The standardized structure 714 of the output 702 may be characterized by ordered parameters, normalized coefficients, standard encoding, consistent formatting, mathematical purity, vendor independence, and reproducible output, while remaining mathematically equivalent 716 to the input 702 regardless of the various vendor-specific implementations 708.
[075] Referring now to FIG. 8, a detailed flow diagram of an exemplary process 800 of generating the structural fingerprint is illustrated in accordance with some embodiments of the present disclosure. FIG. 8 is explained in conjunction with FIGS. 1-7. Each step of the process 800 may be implemented using the structural fingerprint generation module 206 within the memory 104 of the computing device 102.
[076] In order to generate the structural fingerprint corresponding to the PQC asset, at step 802, a domain separation is performed as per the type of the PQC algorithm. In an embodiment, performing the domain separation may include assigning a unique identifier to each PQC algorithm so that inputs of each PQC algorithm are clearly distinguished before structural fingerprint generation. For example, as depicted via step 802-2, the CRYSTAL-KYBER algorithm may be assigned a unique identifier ‘0xA6B95425’, the CRYSTAL-DILITHIUM algorithm may be assigned a unique identifier ‘0x4494CC49’, and the FALCON algorithm may be assigned a unique identifier ‘0x46414C43’. By prefixing inputs with these unique identifiers, the domain separation may enforce protocol-level isolation and ensure that structural fingerprints derived from different PQC algorithms cannot collide or be mistaken for one another.
[077] Further, at step 804, the canonical serialization may be applied to the set of mathematical parameters of the PQC asset. This ensures that equivalent mathematical parameters are always represented in a uniform format (i.e., the standardized representation), thereby eliminating ambiguities in representation. As mentioned via step 804-2, during the canonical serialization, each mathematical parameter is encoded in little-endian format, arranged in a standard coefficient order, and reduced to a canonical mathematical form (i.e., the standardized representation). As a result, semantically identical PQC assets consistently yield the same standardized representation of the set of mathematical parameters, providing determinism in the structural fingerprint generation.
[078] Further, at step 806, salt (i.e., the cryptographic salt) and timestamp integration may be performed to enhance a security of a structural fingerprint generation process. As shown in 806-2, for example, a 32-byte random salt and an 8-byte Unix timestamp are appended to the standardized set of mathematical parameters. The cryptographic salt introduces randomness, preventing precomputation and rainbow-table attacks, while the timestamp introduces temporal uniqueness. Together, the cryptographic salt and the timestamp enhancements may prevent replay attacks and ensure that even identical PQC assets fingerprinted at different times produce unique outputs, i.e. unique structural fingerprints.
[079] Once the cryptographic salt and the timestamp are integrated with the standardized set of mathematical parameters, at step 808, the standardized set of mathematical parameters may be processed by a SHA3-512 cryptographic hash function (i.e., the cryptographic secure hashing algorithm including the quantum-resistant hash function). As shown in 808-2, the SHA3-512 cryptographic hash function may be compliant with FIPS 202 standards, generates a 512-bit (64-byte) output, and is resistant to quantum attacks. The SHA3-512 cryptographic hash function may provide a core transformation that compresses an input data (i.e., the standardized set of mathematical parameters) into a fixed-length digest, ensuring collision resistance and preimage resistance.
[080] Further, at step 810, a final output, e.g., a 64-byte fingerprint (i.e., the structural fingerprint) is generated. As depicted via step 810-2, the final output is deterministic (the same input always produces the same result), collision-resistant (two different inputs cannot feasibly yield the same structural fingerprint), and tamper-evident (any change in input results in a substantially different structural fingerprint). The structural fingerprint may be typically represented as 128 hexadecimal characters corresponding to 64 bytes or 512 bits of data, as mentioned via step 812. This format of the structural fingerprint enables efficient storage, verification, and comparison. In an embodiment, the structural fingerprint produced using the above-mentioned process exhibits multiple security properties as mentioned via step 814. The multiple security properties may include a collision resistance property 814-2, a preimage resistance property 814-4, a quantum resistance property 814-6, a deterministic output 814-8, an avalanche effect 814-10, and a non-reversible property 814-12.
[081] In an embodiment, the collision resistance property 814-2 may ensure that that it is computationally infeasible to generate two different inputs that yield the same structural fingerprint. The preimage resistance property 814-4 may ensure that it is computationally infeasible to derive an original input from the structural fingerprint. The quantum resistance property 814-6 may ensure that the structural fingerprint remains secure against attacks from quantum algorithms, such as Grover’s algorithm. The deterministic output property 814-8 may ensure that identical inputs consistently produce identical structural fingerprints. The avalanche effect property 814-10 may ensure that even a one-bit change in the input results in significant and unpredictable changes in the output (i.e., the structural fingerprint). The non-reversible property 814-12 may ensure that the structural fingerprint generation process is one-way and does not allow reconstruction of an original input.
[082] Referring now to FIG. 9, a detailed flow diagram of an exemplary process 900 for performing real-time structural validation of the PQC asset is illustrated, in accordance with some embodiments of the present disclosure. FIG. 9 is explained in conjunction with FIGS. 1-8. Each step of the process 900 may be implemented using the validation and integrity verification module 210 within the memory 104 of the computing device 102.
[083] In order to perform real-time structural validation of the PQC asset, at step 902, the PQC asset may be received as an input. For example, the PQC asset may include, a PQC certificate, a private or public PQC key, a PQC token, or any file or data structure that encodes the set of mathematical parameters of a PQC implementation. In an embodiment, the PQC asset may be provided as the input by the user. The user may correspond to the entity or the system responsible for managing, monitoring, or validating the PQC asset. For example, the user may be the security officer, the system administrator, the cryptographic auditor, or the automated software module.
[084] Further, at step 904, the set of mathematical parameters corresponding to the PQC asset may be re-extracted in real-time. For example, the set of mathematical parameters may include the polynomial coefficients, the modulus values, the basis vectors, the key components, the encoded parameter fields, any algorithm identifier, etc. The re-extraction of the set of mathematical parameters may use secure, format-aware parsers to locate and read mathematical parameter fields while validating basic syntactic integrity and expected field lengths. In an embodiment, a processing time for re-extracting the set of mathematical parameters may vary based on the size and format of the PQC asset. The processing time may be approximately 10–100 microseconds (ms). The extracted set of mathematical parameters may constitute raw input for a canonical normalization stage.
[085] Once the set of mathematical parameters is extracted, at step 906, the canonical normalization technique (including the canonical serialization) is applied to the extracted set of mathematical parameters. In an embodiment, the canonical normalization technique may convert the extracted set of mathematical parameters into a standardized, machine-independent representation (i.e., the standardized representation) by applying rules such as fixed endianness (e.g., little-endian encoding), prescribed coefficient ordering, canonical mathematical reduction, and removal of optional or non-semantic padding. In response to applying the canonical normalization technique a deterministic standardized representation of the extracted set of mathematical parameters is generated that eliminates representational ambiguities across implementations. In other words, the standardized set of mathematical parameters is generated. In an embodiment, this step of performing the canonical normalization technique may complete in under about 5 ms.
[086] At step 908, a structural fingerprint corresponding to the PQC asset may be re-generated in real-time. In other words, the real-time structural fingerprint corresponding to the PQC asset is generated. In an embodiment, this regeneration process of the real-time structural fingerprint may be completed in less than approximately 5 ms. Once the structural fingerprint corresponding to the PQC asset is re-generated, at step 910, the regenerated fingerprint (i.e., the real-time structural fingerprint) is compared with the associated structural fingerprint (i.e., the reference fingerprint) previously stored corresponding to the PQC asset. In other words, a cryptographic comparison may be performed between the real-time structural fingerprint and the associated structural fingerprint. The comparison may be performed using the timing-safe and the constant-time comparison to mitigate timing-based side-channel leakage. The comparison may may provide a binary equality result (match/no match) while ensuring that execution time, memory access patterns, and other observable characteristics do not vary in a way that could leak information about structural fingerprint contents.
[087] At step 912, based on the comparison, a check may be performed to determine whether the regenerated structural fingerprint matches with the associated structural fingerprint of the PQC asset. In one embodiment, if the regenerated structural fingerprint matches with the associated structural fingerprint, step 914 is executed. At step 914, the PQC asset may be marked as successfully verified (or validated). The successful verification of the PQC asset may indicate that the PQC asset is authentic and structural parameters (i.e., the set of mathematical parameters) of the PQC asset have not been tampered.
[088] In another embodiment, if the regenerated structural fingerprint does not match with the associated structural fingerprint, step 916 may be executed. At step 916 the PQC asset may be flagged as verification failed, indicating possible tampering or non-compliance. In response to flagging the PQC asset as verification failed, at step 916, immediate protective actions may be generated and rendered to the user. The immediate protective actions may include rejecting the PQC asset for cryptographic operations, marking the PQC asset for quarantine, blocking use in secure sessions, and generating alerts for users or administrators. In an embodiment, the report corresponding to the PQC asset may be generated. To generate the report, at step 918, the PQC asset may be analyzed to identify the one or more anomalies. To identify the one or more anomalies, parameter violations and security downgrades may be determined based on the policy-defined parameter ranges (e.g., key size or coefficient bounds). The one or more anomalies, for example may include the coefficient manipulation, the mathematical parameters substitution, the encoding attacks, the downgrade attacks, the non-compliant PQC implementations, etc. In an embodiment, this identification of the one or more anomalies may be completed anywhere between 5–20 ms.
[089] At step 920, a total verification time of a real-time validation process performed for validating the real-time structural fingerprint of the PQC asset may be measured. In an embodiment, for example, the total verification time may range between approximately 20–130 ms, thereby enabling the real-time validation process to be used in latency-sensitive applications such as Transport Layer Security (TLS) handshakes, API validations, and certificate checks. At step 1122, performance characteristics of the real-time validation process may be specified. As illustrated in step 1122-2, the real-time validation process approximately consumes less than 10 megabytes (MB) of memory and achieves an overall verification time of about 20–130 ms. As illustrated in step 1122-4, throughput of a device (e.g., the computing device 102) that is used for the real-time validation process may range from approximately 8–50 verifications per second on a single CPU thread. As illustrated in step 1122-6, the real-time validation process may be horizontally scalable and designed to support low-latency execution. Further, as illustrated in step 1122-8, the real-time validation process may be optimized for real-time applications such as TLS handshakes, API validations, and certificate checking.
[090] Referring now to FIG. 10, an exemplary representation 1000 of a set of mathematical parameters extracted from a PQC asset configured with the CRYSTALS-Kyber algorithm is illustrated, in accordance with some embodiments of the present disclosure. FIG. 10 is explained in conjunction with FIGS. 1-9. In particular, FIG. 10 illustrates a high-level overview of a generic CRYSTAL-Kyber key encapsulation structure, showing various components and mathematical parameter relationships commonly associated with lattice-based post-quantum digital signature schemes.
[091] As shown in FIG. 10, the exemplary representation 1000 depicts the set of mathematical parameters extracted from the PQC asset utilizing the CRYSTALS-Kyber algorithm. In particular, the exemplary representation 1000 is structured into several distinct ways, each responsible for a specific aspect of parameter extraction. A block 1002 may represents a binary key structure 1002-2 that illustrates three variants of the CRYSTALS-Kyber algorithm, i.e., Kyber-512 1002-4, Kyber-768 1002-6, and Kyber-1024 1002-8, each variant corresponding to different security levels. The binary key structure 10022 visually represents a byte-wise structure of public and private keys for each Kyber variant. A block 1004 may represent a polynomial coefficient extraction 1004-2 depicting polynomial coefficients extracted from an encoded key data. The polynomial coefficient extraction 1004-2 may include decomposing polynomial coefficients 1004-4 and extracting vector components 1004-6 using mathematical operations such as t = As+emod q 1004-8, which are foundational to a lattice-based encryption scheme of the CRYSTALS-Kyber algorithm. In the mathematical operation t = As+emod q 1004-8, ‘t’ represents a vector of polynomial coefficients, ‘A’ represents a public matrix of polynomials, ‘s’ represents a secret vector of polynomials, ‘e’ represents an error vector, and ‘q’ a prime modulus (e.g., q=3329q).
[092] A block 1006 may represent a vector decompression 1006 that facilitates the reconstruction of plain text values by transforming compressed vector components into their original form. Each coefficient is mapped back to a specified range using modular arithmetic, thereby restoring the full-resolution polynomial data. Further, a block 808 may represent a mathematical validation 1008-2 that ensures extracted set of mathematical parameters meets expected criteria. This includes checking coefficient bounds 1008-4, validating matrix dimensions 1008-6, and performing security level verification 1008-8 to detect inconsistencies or tampering in the PQC asset. A block 1010 may represent a matrix seed recovery 1010-2 that depicts extraction of a 32-byte seed 1010-4, using which generation of a matrix (e.g., a matrix A) can be deterministically verified, depicted as matrix A generation verification 1010-6. Finally, a detailed parameter structure block 1012 depicts the set of mathematical parameters for each Kyber variant, i.e., a Kyber-512 parameter structure 1012-2, a Kyber-768 parameter structure 1012-4, and a Kyber-1024 parameter structure 1012-6. Each Kyber variant specifies values for the set of mathematical parameters including public/private key sizes, ciphertext length, matrix dimensions, and the number and size of polynomials.
[093] Referring now to FIG. 11, an exemplary representation 1100 of a set of mathematical parameters extracted from a PQC asset configured with the CRYSTALS-Dilithium algorithm is illustrated, in accordance with some embodiments of the present disclosure. FIG. 11 is explained in conjunction with FIGS. 1-10. In particular, FIG. 11 illustrates a high-level overview of a generic CRYSTAL-Dilithium signature structure, showing various components and mathematical parameter relationships commonly associated with lattice-based post-quantum digital signature schemes.
[094] As shown via the exemplary representation, a block 1102 may represent public key components. The public key components may include a seed value ‘ρ’ typically used to deterministically generate a public matrix A, and other public values such as the high-order bits of ‘t1’. A block 1104 may represent matrix dimension configurations (k×l) providing a comparative layout of matrix sizes (k×l) associated with three different security levels of the CRYSTAL-Dilithium scheme, i.e., a Dilithium2 (4×4), a Dilithium3 (6×5), and a Dilithium5 (8×7). A block 1106 may represent a standard decomposition and rounding function, commonly denoted as a Power2Round process, which is employed to split elements into high and low-order components during key generation and signature processes. Additionally, the block 1106 may represent mathematical parameters such as ‘d’, i.e., decomposition parameter and formulas for computing t1 and t0.
[095] Further, a block 1108 may represent detailed mathematical parameter structure for each security level. For instance, the block 1108 may enumerate matrix dimensions, polynomial degree (n), public key size, private key size, signature size, and ring dimension for Dilithium2, Dilithium3, and Dilithium5, thereby providing a comprehensive view of variant-specific configurations. Lastly, a block 1110 may represent parameter relationship validation depicting various validation and consistency checks typically involved in implementation, including matrix generation and dimension checks, coefficient bound enforcement, security compliance with published standards, and reconstruction or rounding verification.
[096] Referring now to FIG. 12, an exemplary representation 1200 of a set of mathematical parameters extracted from a PQC asset configured with the Falcon algorithm is illustrated, in accordance with some embodiments of the present disclosure. FIG. 12 is explained in conjunction with FIGS. 1 -11. In particular, FIG. 12 illustrates a high-level overview of a generic Falcon signature structure, showing various components and mathematical parameter relationships commonly associated with NTRU lattice-based post-quantum digital signature schemes.
[097] As shown via the exemplary representation 100, a block 1202 may represent NTRU polynomial extraction, where the public key polynomial ‘h(x)’ is constructed in a ring Z[x] / (xn+1). The block 1202 may further include standard parameter values for different Falcon algorithm variants, such as Falcon-512 and Falcon-1024, with respective settings for the ring degree ‘n’ and modulus ‘q’. For instance, both Falcon variants may use q=12289 but differ in the ring size, with n=512 or n=1024 depending on the required security level. Further, a block 1204 may represent FFT domain representation of polynomial structures, enabling efficient computation during key generation and signature processes. The block 1204 may include components such as a Fast Number Theoretic Transform (NTT), a root of unity used for modular polynomial arithmetic, and support for O (n log n) complexity for efficient multiplication in a frequency domain.
[098] A block 1206 may represent coefficient distribution analysis, illustrating how Falcon samples secret and error polynomials from a discrete gaussian distribution. The block 1206 may further include constraints on coefficient bounds and validation mechanisms for ensuring statistical soundness of the distribution. The block 1206 may also reference essential checks, such as verifying the standard deviation and confirming that coefficients conform to an expected range. A block 1208 may represent a structural relationship between private key polynomials and a public key. In particular, Falcon uses a congruence relation with ‘f’ and ‘g’ are private polynomials and ‘h’ is a derived public key. The block 1208 may also represent relation verification and security properties relevant to this structural relationship. Further, a block 1210 may represent detailed coefficient structure and validation associated with a specific Falcon parameter set, such as Falcon-512. The block 1210 may include a sub-block 1210-2 and a sub-block 1210-4. The sub-block 1210-2 may represent a Falcon-512 example where the polynomial consists of 512 coefficients (e.g., 2847, -156, 891, ..., -1024), each constrained within a valid range. Further, the sub-block 1210-4 may enumerate a series of validation checks performed.
[099] Referring now to FIG. 13, an exemplary representation 1300 of a set of mathematical parameters extracted from a PQC asset configured with the SPHINCS+ algorithm is illustrated, in accordance with some embodiments of the present disclosure. FIG. 13 is explained in conjunction with FIGS. 1 -12. In particular, FIG. 13 illustrates a high-level overview of a generic SPHINCS+ signature structure, showing various components and mathematical parameter relationships commonly associated with hash-based post-quantum digital signature schemes.
[0100] As shown via the exemplary representation 1300, a block 1302 may represent a Merkle tree layer structure, commonly known as a hypertree, used to organize signature paths and keys across multiple layers. The block 1302 may depict multiple layers (e.g., layer 0 to layer d), each consisting of nodes representing WOTS+ public keys or internal hashes. A sub-block 1302-2 may represent hypertree parameters such as the total tree height ‘h’, the number of layers ‘d’, and the subtree height ‘h/d’. The sub-block 1302-2 may depict reference specific configurations used in SPHINCS+ variants, for example, SPHINCS+-128s using d = 22, h = 66, and h/d = 3.
[0101] A block 1304 may represent WOTS+ components include encoding parameters such as w (e.g., w = 16, 256), which define a Winternitz base and a chain length. The chain length may be calculated using a logarithmic formula based on w, message length, and checksum requirements. A block 1306 may represent FORS parameters used within SPHINCS+ for hashing and encoding messages. The block 1306 may include parameters such as the number of trees k, height of each tree a, and the partitioning of the message into k bit strings that each determine a leaf in the respective FORS trees. These values are used during a message signing phase.
[0102] A block 1308 may represent hash function integration points, where cryptographic hash functions are used across various layers of a SPHINCS+ scheme. As depicted, the block 1308 may include sub-blocks depicting WOTS+ chains 1308-2, tree nodes 1308-4, FORS trees 1308-6, and Pseudorandom Function (PRF)/ Pseudorandom Generator (PRG) operations 1308-8. Further, a sub-block 1308-10 may indicate that hash functions (i.e., the cryptographic secure hashing algorithm including the quantum-resistant hash function) used, e.g., SHA-256, SHAKE-256, or Haraka, depending on the set of mathematical parameters associated with the SPHINCS+ algorithm.
[0103] A block 1310 may represent SPHINCS+ parameter variants, outlining security level options and their associated configurations. These SPHINCS+ parameter variants may include a SPHINCS+-128s 1310-2, a SPHINCS+-128f 1310-4, a SPHINCS+-192s 1310-6, and a SPHINCS+-256s 1310-8. Further, a block 1312 may provide detailed view of the FORS tree structure, including mathematical parameters such as the number of parallel trees ‘k’ and tree height ‘a’. The block 1312 may specify that each FORS tree has 2^a leaves, and a message is split into k parts, with each part guiding selection of a leaf node from a corresponding tree.
[0104] Further, a block 1314 may represent a signature generation process (i.e., the structural fingerprint generation process), composed of several distinct steps. A sub-block 1314-2 of the block 1314 may describe a hashing of a message with randomness. A sub-block 1314-4 may depict the use of FORS for compressing and signing a hashed message. A sub-block 1314-6 may indicate WOTS+ signature generation and inclusion of authentication paths. A sub-block 1314-8 may represent final authentication steps through the hypertree to a root public key. A sub-block 1314-10 may illustrate that a complete SPHINCS+ signature includes the FORS signature, WOTS+ signature, and tree authentication paths, with overall size determined by the selected parameter set.
[0105] In an embodiment, a disclosed technique in the present disclosure may provide enhanced tamper detection capabilities and associated benefits in context of the PQC assets. The present disclosure is configured to detect coefficient manipulation by identifying unauthorized changes to polynomial coefficients, to recognize parameter substitution attempts through detection of non-standard parameter sets, and to mitigate encoding attacks by flagging malicious compression or decompression behaviors. Furthermore, the present disclosure may prevent downgrade attacks by identifying reductions in prescribed security parameters and ensure compliance by detecting implementation deviations introduced by vendor-specific variations.
[0106] Advantageously, the present disclosure may introduce multiple benefits over conventional approaches. Unlike existing methods that rely on a binary hash of an entire certificate blob, the disclosed technique may enable mathematical structure awareness by performing deep analysis of underlying parameters. In addition, the present disclosure may provide format-agnostic validation through canonical normalization to ensure mathematical equivalence, whereas conventional approaches are format-dependent. The present disclosure may further introduce algorithm-specific intelligence by employing specialized parsers for each PQC algorithm family, in contrast to generic cryptographic validation. Moreover, the present disclosure may enhance tamper detection granularity, enabling identification of parameter-level mathematical manipulation rather than only gross certificate tampering. In addition, the present disclosure may help in achieving quantum-resistant security by utilizing SHA3-512 with post-quantum security margins, thereby improving upon conventional SHA-256 mechanisms that remain vulnerable to a Grover algorithm.
[0107] The disclosed technique in the present disclosure may further contemplate a variety of use cases and applications spanning enterprise, certificate authority, governmental, and cloud infrastructure environments. In some embodiments, the disclosed technique may enable enterprise security functions such as cryptographic asset (i.e., the PQC asset) auditing to validate PQC algorithm compliance across organizational infrastructure, supply chain security to verify the cryptographic integrity of vendor components, and regulatory compliance by demonstrating mathematical adherence during audits. Within the domain of Certificate Authorities (CAs), the disclosed technique may be employed for issuance validation to ensure that newly issued PQC certificates are mathematically sound, for root CA protection by validating the structural integrity of foundational cryptographic materials, and for cross-certification by verifying PQC certificates originating from external authorities. For government and critical infrastructure applications, the disclosed technique may validate quantum-resistant cryptography within national security systems, ensure compliance of PQC algorithm implementations in critical infrastructure such as power grids and transportation systems, and secure classified communications by verifying cryptographic assets of embassies and other sensitive facilities. In addition, within cloud and enterprise infrastructure, the disclosed technique may support TLS certificate validation through real-time verification of PQC certificates, enhance API security by validating quantum-resistant signatures on API tokens, and strengthen container security by verifying cryptographic signatures applied to container images.
[0108] As will be also appreciated, the above-described techniques may take the form of computer or controller implemented processes and apparatuses for practicing those processes. The disclosure can also be embodied in the form of computer program code containing instructions embodied in tangible media, such as floppy diskettes, solid state drives, CD-ROMs, hard drives, or any other computer-readable storage medium, wherein, when the computer program code is loaded into and executed by a computer or controller, the computer becomes an apparatus for practicing the invention. The disclosure may also be embodied in the form of computer program code or signal, for example, whether stored in a storage medium, loaded into and/or executed by a computer or controller, or transmitted over some transmission medium, such as over electrical wiring or cabling, through fiber optics, or via electromagnetic radiation, wherein, when the computer program code is loaded into and executed by a computer, the computer becomes an apparatus for practicing the invention. When implemented on a general-purpose microprocessor, the computer program code segments configure the microprocessor to create specific logic circuits.
[0109] The disclosed methods and systems may be implemented on a conventional or a general-purpose computer system, such as a personal computer (PC) or server computer. Referring now to FIG. 14, an exemplary computing system 1400 that may be employed to implement processing functionality for various embodiments (e.g., as a Single Instruction, Multiple Data (SIMD) device, client device, server device, one or more processors, or the like) is illustrated. Those skilled in the relevant art will also recognize how to implement the invention using other computer systems or architectures. The computing system 1400 may represent, for example, a user device such as a desktop, a laptop, a mobile phone, personal entertainment device, Digital Video Recorder (DVR), and so on, or any other type of special or general-purpose computing device as may be desirable or appropriate for a given application or environment. The computing system 1400 may include one or more processors, such as a processor 1402 that may be implemented using a general or special purpose processing engine such as, for example, a microprocessor, microcontroller or other control logic. In this example, the processor 1402 is connected to a bus 1404 or other communication medium. In some embodiments, the processor 1402 may be an Artificial Intelligence (AI) processor, which may be implemented as a Tensor Processing Unit (TPU), or a graphical processor unit, or a custom programmable solution Field-Programmable Gate Array (FPGA).
[0110] The computing system 1400 may also include a memory 1406 (main memory), for example, Random Access Memory (RAM) or other dynamic memory, for storing information and instructions to be executed by the processor 1402. The memory 1406 also may be used for storing temporary variables or other intermediate information during execution of instructions to be executed by the processor 1402. The computing system 1400 may likewise include a Read Only Memory (ROM) or other static storage device coupled to bus 1404 for storing static information and instructions for the processor 1402.
[0111] The computing system 1400 may also include storage devices 1408, which may include, for example, a media drive 1410 and a removable storage interface. The media drive 1410 may include a drive or other mechanism to support fixed or removable storage media, such as a hard disk drive, a floppy disk drive, a magnetic tape drive, an Secure Digital (SD) card port, a Universal Serial Bus (USB) port, a micro-USB, an optical disk drive, a Compact Disc (CD) or Digital Versatile Disc (DVD) drive (R or Rewritable (RW)), or other removable or fixed media drive. A storage media 1412 may include, for example, a hard disk, magnetic tape, flash drive, or other fixed or removable medium that is read by and written to by the media drive 1410. As these examples illustrate, the storage media 1412 may include a computer-readable storage medium having stored therein particular computer software or data.
[0112] In alternative embodiments, the storage devices 1408 may include other similar instrumentalities for allowing computer programs or other instructions or data to be loaded into the computing system 1400. Such instrumentalities may include, for example, a removable storage unit 1414 and a storage unit interface 1416, such as a program cartridge and cartridge interface, a removable memory (for example, a flash memory or other removable memory module) and memory slot, and other removable storage units and interfaces that allow software and data to be transferred from the removable storage unit 1414 to the computing system 1400.
[0113] The computing system 1400 may also include a communications interface 1418. The communications interface 1418 may be used to allow software and data to be transferred between the computing system 1400 and external devices. Examples of the communications interface 1418 may include a network interface (such as an Ethernet or other Network Interface Card (NIC) card), a communications port (such as for example, a USB port, a micro-USB port), Near field Communication (NFC), etc. Software and data transferred via the communications interface 1418 are in the form of signals which may be electronic, electromagnetic, optical, or other signals capable of being received by the communications interface 1418. These signals are provided to the communications interface 1418 via a channel 1420. The channel 1420 may carry signals and may be implemented using a wireless medium, wire or cable, fiber optics, or other communications medium. Some examples of the channel 1420 may include a phone line, a cellular phone link, an RF link, a Bluetooth link, a network interface, a local or wide area network, and other communications channels.
[0114] The computing system 1400 may further include Input/Output (I/O) devices 1422. Examples may include, but are not limited to a display, keypad, microphone, audio speakers, vibrating motor, Light Emitting Diode (LED) lights, etc. The I/O devices 1422 may receive input from a user and also display an output of the computation performed by the processor 1402. In this document, the terms “computer program product” and “computer-readable medium” may be used generally to refer to media such as, for example, the memory 1406, the storage devices 1408, the removable storage unit 1414, or signal(s) on the channel 1420. These and other forms of computer-readable media may be involved in providing one or more sequences of one or more instructions to the processor 1402 for execution. Such instructions, generally referred to as “computer program code” (which may be grouped in the form of computer programs or other groupings), when executed, enable the computing system 1400 to perform features or functions of embodiments of the present invention.
[0115] In an embodiment where the elements are implemented using software, the software may be stored in a computer-readable medium and loaded into the computing system 1400 using, for example, the removable storage unit 1414, the media drive 1410 or the communications interface 1418. The control logic (in this example, software instructions or computer program code), when executed by the processor 1402, causes the processor 1402 to perform the functions of the invention as described herein.
[0116] Various embodiments provide a method and a system for structurally validating PQC assets. The disclosed method and system may extract a set of mathematical parameters from a PQC asset using a set of parsing rules pre-defined for a PQC algorithm associated with the PQC asset. Further, the disclosed method and system may apply a normalization technique to the set of mathematical parameters to generate a standardized set of mathematical parameters consistent across a plurality of vendor-specific implementations of the PQC algorithm. Furthermore, the disclosed method and system may generate a structural fingerprint corresponding to the standardized set of mathematical parameters associated with the PQC asset using a pre-defined hashing algorithm. Thereafter, the disclosed method and system may associate the structural fingerprint with the PQC asset to perform real-time structural validation of the PQC asset. It may be noted that the real-time structural validation of the PQC asset may be performed based on user requirements.
[0117] Thus, the disclosed method and system try to overcome the technical problem of structurally validating the PQC assets. The disclosed method and system enable advanced validation of the PQC asset implementations by detecting mathematical parameter tampering, verifying compliance with the NIST (i.e., the national authority) specifications, and ensuring genuine quantum resistance in hybrid deployments. In other words, the disclosed method and system overcome the challenges of traditional certificate or compliance checking, which often fail to identify coefficient-level manipulation in lattice-based schemes or subtle implementation variances across vendors. In addition, the disclosed method and system provide mathematical proof of quantum readiness, along with normalized validation across different implementations, thereby ensuring vendor interoperability and cryptographic integrity.
[0118] Further, the disclosed method and system may remove manual efforts in performing deep PQC asset audits by introducing automated validation and continuous real-time monitoring of the PQC asset operations. Moreover, the disclosed method and system may enable organizations to maintain security even in the presence of quantum adversaries by detecting sophisticated mathematical parameter manipulation attacks and enforcing cryptographic policy compliance automatically. The disclosed method and system work seamlessly across platforms and PQC asset implementations, ensuring cross-platform compatibility and providing an audit trail for regulatory reporting. Further, the disclosed method and system may operate as a standalone solution or integrate with existing cryptographic frameworks to continuously validate post-quantum security readiness, thereby reducing operational overhead and compliance burden. In addition, the disclosed method and system help achieve enhanced tamper resistance, improved governance, and long-term quantum future-proofing, which are not possible with conventional cryptographic validation approaches.
[0119] In light of the above-mentioned advantages and the technical advancements provided by the disclosed method and system, the claimed steps as discussed above are not routine, conventional, or well understood in the art, as the claimed steps enable the following solutions to the existing problems in conventional technologies. Further, the claimed steps clearly bring an improvement in the functioning of the device itself as the claimed steps provide a technical solution to a technical problem.
[0120] The specification has described a method and system for structurally validating the PQC assets. The illustrated steps are set out to explain the exemplary embodiments shown, and it should be anticipated that ongoing technological development will change the manner in which particular functions are performed. These examples are presented herein for purposes of illustration, and not limitation. Further, the boundaries of the functional building blocks have been arbitrarily defined herein for the convenience of the description. Alternative boundaries can be defined so long as the specified functions and relationships thereof are appropriately performed. Alternatives (including equivalents, extensions, variations, deviations, etc., of those described herein) will be apparent to persons skilled in the relevant art(s) based on the teachings contained herein. Such alternatives fall within the scope and spirit of the disclosed embodiments.
[0121] Furthermore, one or more computer-readable storage media may be utilized in implementing embodiments consistent with the present disclosure. A computer-readable storage medium refers to any type of physical memory on which information or data readable by a processor may be stored. Thus, a computer-readable storage medium may store instructions for execution by one or more processors, including instructions for causing the processor(s) to perform steps or stages consistent with the embodiments described herein. The term “computer-readable medium” should be understood to include tangible items and exclude carrier waves and transient signals, i.e., be non-transitory. Examples include random access memory (RAM), read-only memory (ROM), volatile memory, nonvolatile memory, hard drives, CD ROMs, DVDs, flash drives, disks, and any other known physical storage media.
[0122] It is intended that the disclosure and examples be considered as exemplary only, with a true scope and spirit of disclosed embodiments being indicated by the following claims. , Claims:CLAIMS
I/WE CLAIM:
1. A method (300) for structurally validating Post-Quantum Cryptographic (PQC) assets, the method comprising:
extracting (302), by a processor (106), a set of mathematical parameters from a PQC asset using a set of parsing rules pre-defined for a PQC algorithm associated with the PQC asset;
applying (304), by the processor (106), a normalization technique to the set of mathematical parameters to generate a standardized set of mathematical parameters consistent across a plurality of vendor-specific implementations of the PQC algorithm;
generating (306), by the processor (106), a structural fingerprint corresponding to the standardized set of mathematical parameters associated with the PQC asset using a pre-defined hashing algorithm; and
associating (308), by the processor (106), the structural fingerprint with the PQC asset to perform real-time structural validation of the PQC asset, wherein the real-time structural validation of the PQC asset is performed based on user requirements.

2. The method (300) as claimed in claim 1, wherein extracting (302) the set of mathematical parameters from the PQC asset comprising:
determining (402), by the processor (106), a type of the PQC algorithm associated with the PQC asset;
identifying (404), by the processor (106), one or more mathematical parameters corresponding to the PQC asset based on the type of the PQC algorithm;
validating (406), by the processor (106), the one or more mathematical parameters based on the set of parsing rules pre-defined for the type of the PQC algorithm; and
in response to validating, extracting (408), by the processor (106), the set of mathematical parameters from the PQC asset.

3. The method (300) as claimed in claim 2, wherein the type of the PQC algorithm is one of a CRYSTALS-Kyber algorithm, a CRYSTALS-Dilithium algorithm, a Falcon algorithm, and a SPHINCS+ algorithm.

4. The method (300) as claimed in claim 3, wherein the set of parsing rules corresponding to each type of the PQC algorithm is pre-defined by a national authority.

5. The method (300) as claimed in claim 1, wherein the normalization technique is a canonical normalization technique, and wherein the canonical normalization technique comprises a predefined set of normalization rules configured for generating the standardized set of mathematical parameters.

6. The method (300) as claimed in claim 1, wherein the pre-defined hashing algorithm is a cryptographic secure hashing algorithm comprising a quantum-resistant hash function.

7. The method (300) as claimed in claim 1, wherein performing (308) the real-time structural validation of the PQC asset comprising:
generating (502), by the processor (106), a real-time structural fingerprint corresponding to the PQC asset;
retrieving (504), by the processor (106), the associated structural fingerprint from the PQC asset;
comparing (506), by the processor (106), the real-time structural fingerprint with the associated structural fingerprint of the PQC asset; and
validating (508), by the processor (106), the PQC asset in response to comparing.

8. The method (300) as claimed in claim 7, wherein validating (508) the PQC asset comprises:
detecting, by the processor (106), one or more anomalies corresponding to the PQC asset, wherein the one or more anomalies comprise coefficient manipulation, mathematical parameters substitution, encoding attacks, downgrade attacks, and non-compliant PQC implementations;
generating, by the processor (106), a report corresponding to the PQC asset based on the one or more anomalies; and
rendering, by the processor (106), the report to a user via a Graphical User Interface (GUI).

9. A system (100) for structurally validating Post-Quantum Cryptographic (PQC) assets, the system (100) comprising:
a processor (106); and
a memory (104) coupled to the processor (106), wherein the memory (104) stores processor executable instructions, which, on execution, causes the processor (106) to:
extract (302) a set of mathematical parameters from a PQC asset using a set of parsing rules pre-defined for a PQC algorithm associated with the PQC asset;
apply (304) a normalization technique to the set of mathematical parameters to generate a standardized set of mathematical parameters consistent across a plurality of vendor-specific implementations of the PQC algorithm;
generate (306) a structural fingerprint corresponding to the standardized set of mathematical parameters associated with the PQC asset using a pre-defined hashing algorithm; and
associate (308) the structural fingerprint with the PQC asset to perform real-time structural validation of the PQC asset, wherein the real-time structural validation of the PQC asset is performed based on user requirements.

10. The system (100) as claimed in claim 9, wherein, to extract (302) the set of mathematical parameters from the PQC asset, the processor executable instructions further cause the processor (106) to:
determine (402) a type of the PQC algorithm associated with the PQC asset;
identify (404) one or more mathematical parameters corresponding to the PQC asset based on the type of the PQC algorithm;
validate (406) the one or more mathematical parameters based on the set of parsing rules pre-defined for the type of the PQC algorithm; and
in response to validating, extract (408) the set of mathematical parameters from the PQC asset.

11. The system (100) as claimed in claim 10, wherein the type of the PQC algorithm is one of a CRYSTALS-Kyber algorithm, a CRYSTALS-Dilithium algorithm, a Falcon algorithm, and a SPHINCS+ algorithm.

12. The system (100) as claimed in claim 11, wherein the set of parsing rules corresponding to each type of the PQC algorithm is pre-defined by a national authority.

13. The system (100) as claimed in claim 9, wherein the normalization technique is a canonical normalization technique, and wherein the canonical normalization technique comprises a predefined set of normalization rules configured for generating the standardized set of mathematical parameters.

14. The system (100) as claimed in claim 9, wherein the pre-defined hashing algorithm is a cryptographic secure hashing algorithm comprising a quantum-resistant hash function.

15. The system (100) as claimed in claim 9, wherein, to perform (308) the real-time structural validation of the PQC asset, the processor executable instructions further cause the processor (106) to:
generate (502) a real-time structural fingerprint corresponding to the PQC asset;
retrieve (504) the associated structural fingerprint from the PQC asset;
compare (506) the real-time structural fingerprint with the associated structural fingerprint of the PQC asset; and
validate (508) the PQC asset in response to comparing.

16. The system (100) as claimed in claim 15, wherein, to validate (508) the PQC asset, the processor executable instructions further cause the processor (106) to:
detect one or more anomalies corresponding to the PQC asset, wherein the one or more anomalies comprise coefficient manipulation, mathematical parameters substitution, encoding attacks, downgrade attacks, and non-compliant PQC implementations;
generate a report corresponding to the PQC asset based on the one or more anomalies; and
render the report to a user via a Graphical User Interface (GUI).