Version 0.4.0

GitOrigin-RevId: 32f0321f8799530d331b905034a2006e66ae2130

Author: Terra Quantum AG

.github/workflows/push.yml

@@ -43,12 +43,13 @@ jobs:
           architecture: x86_64
 
         - os: Linux
-          image: ubuntu-latest
+          image: ubuntu-22.04
           configuration: Release
           sanitize: ON
           coverage: OFF
           haswell: OFF
           compiler: GCC
+          gcc: 11
           architecture: x86_64
 
         - os: Linux

.github/workflows/style.yml

@@ -22,12 +22,14 @@ jobs:
         python3 -c 'if True:
           import difflib
           import os
+          import re
           import subprocess
           import sys
 
           import gitignorefile
 
           gi = gitignorefile.Cache()
+          r_pattern = re.compile("[^\\u0000-\\u00FF]", re.U)
           errors = 0
           for root, directories, names in os.walk(os.getcwd()):
             directories[:] = [d for d in directories if d != ".git" and not gi(os.path.join(root, d))]
@@ -54,5 +56,15 @@ jobs:
                     print(f"::error file={rp},line={i1+1},endLine={i2}::{rp}:{i1+1} Please remove line(s) {i1+1}-{i2}")
                     errors += 1
 
+              if os.path.splitext(name)[1] not in (".ico", ".png", ".ent", ".shake") and not gi(path):
+                with open(path) as f:
+                  for row_n, row in enumerate(f, start = 1):
+                    found = r_pattern.findall(row)
+                    if found:
+                      rp = os.path.relpath(path)
+                      print(f"Error: Found symbols {found} in {rp}:")
+                      print(f"Line {row_n}: {row}")
+                      errors += 1
+
           sys.exit(int(bool(errors)))
         '

CMakeLists.txt

@@ -82,3 +82,13 @@ endif()
 if(BENCHMARK)
     add_subdirectory(benchmark)
 endif()
+
+include(CheckIncludeFile)
+file(GLOB proj_headers "include/pqc/*.h")
+foreach(project_header ${proj_headers})
+    get_filename_component(header_name ${project_header} NAME_WE)
+    check_include_file("${project_header}" ${header_name}_IS_STANDALONE)
+    if (NOT ${header_name}_IS_STANDALONE)
+        message(FATAL_ERROR "Header is not self-sufficient: ${project_header}")
+    endif()
+endforeach()

docs/api_reference.md

@@ -118,4 +118,4 @@ Below you may find the reference to the all API methods or examples that exist i
 ## Common functions
 - [`PQC_cipher_get_length`](common_functions.html#pqc_cipher_get_length)
 - [`PQC_context_get_length`](common_functions.html#pqc_context_get_length)
-- [Constants](common_functions.html#сonstants)
+- [Constants](common_functions.html#constants)

docs/common_functions.md

@@ -60,7 +60,7 @@ size_t PQC_API PQC_context_get_length(CIPHER_HANDLE context, uint32_t type);
 *   `0`: Indicates an error, such as an invalid context or type.
 
 
-## Сonstants
+## Constants
 
 ### Cipher:
 

docs/keys/PRNG.md

@@ -42,7 +42,7 @@ Algorithm
 
     * **Hash Truncation and Reuse**: The resulting hash is then truncated, taking a portion of the hash and overwriting the original elements of `dt` with this truncated hash data. This step is essential to mix the entropy and reduce predictability.
 
-    * **Initial AES Encryption**: The array `dt` is then encrypted using the AES block cipher in OFB mode. This mode of operation turns a block cipher into a stream cipher, producing a keystream that is then XORed with the plaintext—in this case, the data in `dt`.
+    * **Initial AES Encryption**: The array `dt` is then encrypted using the AES block cipher in OFB mode. This mode of operation turns a block cipher into a stream cipher, producing a keystream that is then XORed with the plaintext - in this case, the data in `dt`.
 
     * **XOR with Internal State**: After the encryption, the `dt` array is XORed with an internal state array `v`. The result of this XOR is stored in a new array `r`.
 

docs/keys/pbkdf2.md

@@ -66,7 +66,7 @@ size_t PQC_API PQC_pbkdf_2(
 *   `key_length`: The length of the key buffer.
 *   `master_key`:  Buffer for storing the derived key.
 *   `master_key_length`: Define the length of the master key to be derived.
-*   `salt`: Salt value used in file encryption. It’s recommended to use a constant specific to the application for enhanced security.
+*   `salt`: Salt value used in file encryption. It's recommended to use a constant specific to the application for enhanced security.
 *   `salt_length`: The length of the salt.
 *   `iterations`: Number of iterations, positive integer value.
 

docs/post_quantum_algs/digital_signature/falcon.md

@@ -28,11 +28,11 @@ nav_order: 3
 
 Copyright (c) 2017-2019  Falcon Project
 
-Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the “Software”), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:
+Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:
 
 The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.
 
-THE SOFTWARE IS PROVIDED “AS IS”, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
 
 
 ## Falcon - Parameter set summary

docs/post_quantum_algs/kem/kem.md

@@ -11,11 +11,11 @@ The Key Encapsulation Mechanisms (KEMs) for post-quantum algorithms serve as cry
 
 The operational framework of a KEM in post-quantum cryptography involves three main algorithms:
 
-1.  **Key Generation (Generate):** This algorithm is responsible for generating a pair of keys—an openly shared public key and a privately kept secret key.
+1.  **Key Generation (Generate):** This algorithm is responsible for generating a pair of keys - an openly shared public key and a privately kept secret key.
 
 2.  **Encapsulation (Encapsulate):** In this step, a sender utilizes the recipient's public key to encapsulate a shared secret, resulting in a pair consisting of a ciphertext (or "encapsulation") and a shared secret value, enabling the derivation of encryption keys.
 
 3.  **Decapsulation (Decapsulate):** Upon receiving the encapsulated key, the recipient uses their private key to decapsulate the shared secret from the ciphertext, thereby enabling secure communication.
 
 
-Post-quantum KEMs leverage complex mathematical problems believed to be intractable for quantum computers, such as those based on lattice structures, code-based principles, or other quantum-resistant foundations. These KEMs play a critical role in achieving secure key exchange in the next generation of cryptographic protocols, ensuring secure communications even in the presence of sophisticated quantum computing capabilities. The development and standardization of such mechanisms, as carried out by organizations like NIST, are essential steps towards maintaining global digital security standards in the post-quantum future.
+Post-quantum KEMs leverage complex mathematical problems believed to be intractable for quantum computers, such as those based on lattice structures, code-based principles, or other quantum-resistant foundations. These KEMs play a critical role in achieving secure key exchange in the next generation of cryptographic protocols, ensuring secure communications even in the presence of sophisticated quantum computing capabilities. The development and standardization of such mechanisms, as carried out by organizations like NIST, are essential steps towards maintaining global digital security standards in the post-quantum future.

docs/post_quantum_algs/kem/mceliece.md

@@ -34,7 +34,7 @@ The McEliece algorithm implementation has successfully passed the Known Answer T
 
 ## Leveraging McEliece and True Entropy
 The customization of the McEliece algorithm within TQ42 Cryptography is designed to work in synergy with true entropy, sourced from the Single Photon Quantum Random Number Generator (QRNG). This technology ensures that the randomness required for cryptographic keys is of the highest quality, providing unparalleled security for company data.
-Since the effectiveness of any cryptographic algorithm heavily relies on the randomness of its keys, incorporating QRNG-derived true entropy with TQ42’s customized McEliece algorithm ensures that your company’s sensitive information is safeguarded in the most robust manner possible.
+Since the effectiveness of any cryptographic algorithm heavily relies on the randomness of its keys, incorporating QRNG-derived true entropy with TQ42's customized McEliece algorithm ensures that your company's sensitive information is safeguarded in the most robust manner possible.
 
 ## Classic McEliece 8192128f - Parameter set summary
 
@@ -74,7 +74,7 @@ The latest state of the NIST standardization process for the McEliece Key Encaps
 - **Unique Position**: Unlike some other algorithms being considered for standardization, Classic McEliece does not directly compete with many as a general-purpose KEM. Its primary competition, in terms of lattice-based approaches like ML-KEM, differs in key aspects, such as key sizes and computational efficiency. Nevertheless, NIST is evaluating Classic McEliece along with others for its potential unique benefits, such as its long-standing security assumptions resilience to certain types of attacks (<https://blog.cloudflare.com/pq-2024>).
 
 - **Performance Considerations**: Although Classic McEliece provides certain advantages, 
-including a high level of security, its performance aspects–particularly in terms of key sizes–do not directly compete 
+including a high level of security, its performance aspects-particularly in terms of key sizes - do not directly compete 
 with some of the more computationally efficient algorithms like ML-KEM. This factor is crucial as NIST also considers the 
 practicality of implementing these algorithms in real-world systems.
 

docs/post_quantum_algs/kem/ml-kem.md

@@ -66,7 +66,7 @@ FIPS 203, which standardizes Module-Lattice-based Key-Encapsulation Mechanisms (
 The TQ42 Cryptography ML-KEM algorithm implementation has successfully passed the Known Answer Tests (KAT) provided by NIST. This confirms that the algorithm performs reliably as anticipated. For those interested in a deeper dive into the specifics of these tests, they are available [for review](https://github.com/terra-quantum-public/tq42-pqc-oss/tree/main/test/mlkem).
 
 ## Leveraging ML-KEM and True Entropy
-The customization of the ML-KEM algorithm within TQ42 Cryptography is designed to work in synergy with true entropy, sourced from the Single Photon Quantum Random Number Generator (QRNG). This technology ensures that the randomness required for cryptographic keys is of the highest quality, providing unparalleled security for company data. Since the effectiveness of any cryptographic algorithm heavily relies on the randomness of its keys, incorporating QRNG-derived true entropy with TQ42’s customized ML-KEM algorithm ensures that your company’s sensitive information is safeguarded in the most robust manner possible.
+The customization of the ML-KEM algorithm within TQ42 Cryptography is designed to work in synergy with true entropy, sourced from the Single Photon Quantum Random Number Generator (QRNG). This technology ensures that the randomness required for cryptographic keys is of the highest quality, providing unparalleled security for company data. Since the effectiveness of any cryptographic algorithm heavily relies on the randomness of its keys, incorporating QRNG-derived true entropy with TQ42's customized ML-KEM algorithm ensures that your company's sensitive information is safeguarded in the most robust manner possible.
 
 ## ML-KEM - Parameter set summary
 

docs/use_cases.md

@@ -84,6 +84,6 @@ The diagram shows one of the options for building a blockchain based on TQ42 Cry
 
 ![image](img/use_cases_PFS.png)
 
-In the example **Perfect Forward Secrecy (PFS)** example, TQ42 Cryptography is used in such a way that each node contributes its share of entropy to the overall symmetric session key. None of the nodes forward the final encryption key in its entirety, and no one from outside can learn the session key by breaking the long-term keys incompletely (n-1 broken keys will not yield the session key).
+In the **Perfect Forward Secrecy (PFS)** example, TQ42 Cryptography is used in such a way that each node contributes its share of entropy to the overall symmetric session key. None of the nodes forward the final encryption key in its entirety, and no one from outside can learn the session key by breaking the long-term keys incompletely (n-1 broken keys will not yield the session key).
 
 In the above example, we can integrate TQ42 Cryptography into the overall PFS scheme. To start information sharing, the user obtains keys (TQ42 Cryptography), which are then put into a shared repository where each user must retrieve them. Once the keys are obtained and the shared key is computed, the information sharing between users will be considered secure.

examples/aes/aes_cbc_example.cpp

@@ -8,7 +8,7 @@
 // parties can obtain a common key through asymmetric key exchange
 
 // CBC takes a fixed-length iv, fixed-length key and
-// fixed-length plaintext. Plaintext size MUST be mutile of AES_BLOCKLEN;
+// fixed-length plaintext. Plaintext size MUST be multiple of AES_BLOCKLEN;
 
 // Party A encrypts its plaintext using a key and iv. Then data, its length, key and iv must be
 // transmitted to party B

examples/aes/aes_ctr_example.cpp

@@ -6,7 +6,7 @@
 // parties can obtain a common key through asymmetric key exchange
 
 // CTR encryption doesn't need an iv. It takes a fixed-length key and
-// fixed-length plaintext. Plaintext size MUST be mutile of AES_BLOCKLEN;
+// fixed-length plaintext. Plaintext size MUST be multiple of AES_BLOCKLEN;
 // Decryption works in the same way
 
 // Party A encrypts its plaintext using a key. Then data, its length, and key must be

examples/aes/aes_ofb_example.cpp

@@ -9,7 +9,7 @@
 // OFB
 
 // OFB  takes a fixed length iv, fixed-length key and
-// fixed-length plaintext. Plaintext size MUST be mutile of AES_BLOCKLEN;
+// fixed-length plaintext. Plaintext size MUST be multiple of AES_BLOCKLEN;
 // Decryption works in the same way
 
 // Party A encrypts its plaintext using a key and iv. Then data, its length, key and iv must be

examples/asymmetric_container/asymmetric_container_example_2_byte_string_falcon.cpp

@@ -1,5 +1,6 @@
 #include <cstring>
 #include <iostream>
+#include <memory>
 
 #include <pqc/aes.h>
 #include <pqc/container.h>
@@ -34,15 +35,15 @@ int main()
     /*
     We can transform container to the encrypted byte string. Let's do it
     */
-    uint8_t * container_data = new uint8_t[PQC_asymmetric_container_size(new_container)];
+    std::shared_ptr<uint8_t[]> container_data(new uint8_t[PQC_asymmetric_container_size(new_container)]);
 
     // aes will use for string encryption
     uint8_t creation_key[PQC_AES_KEYLEN] = {1, 2, 3, 4, 5, 6, 7, 8, 9, 0, 1, 2, 3, 4, 5, 6,
                                             7, 8, 9, 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 0, 1, 2};
     uint8_t creation_iv[PQC_AES_IVLEN] = {9, 8, 7, 6, 5, 6, 7, 8, 9, 0, 1, 2, 3, 4, 5, 6};
 
     size_t result = PQC_asymmetric_container_get_data(
-        new_container, container_data, PQC_asymmetric_container_size(new_container), creation_key, PQC_AES_KEYLEN,
+        new_container, container_data.get(), PQC_asymmetric_container_size(new_container), creation_key, PQC_AES_KEYLEN,
         creation_iv, PQC_AES_IVLEN
     );
     if (result != PQC_OK)
@@ -55,8 +56,8 @@ int main()
     */
 
     PQC_CONTAINER_HANDLE resultContainer = PQC_asymmetric_container_from_data(
-        PQC_CIPHER_FALCON, container_data, PQC_asymmetric_container_size(new_container), creation_key, PQC_AES_KEYLEN,
-        creation_iv, PQC_AES_IVLEN
+        PQC_CIPHER_FALCON, container_data.get(), PQC_asymmetric_container_size(new_container), creation_key,
+        PQC_AES_KEYLEN, creation_iv, PQC_AES_IVLEN
     );
     if (resultContainer == PQC_FAILED_TO_CREATE_CONTAINER)
     {
@@ -80,8 +81,6 @@ int main()
         std::cout << "\nERROR!!! Keys are not equal!!!\n";
     }
 
-    delete[] container_data;
-
     PQC_asymmetric_container_close(new_container);
     PQC_asymmetric_container_close(resultContainer);
 

examples/asymmetric_container/asymmetric_container_example_2_byte_string_mceliece.cpp

@@ -39,15 +39,15 @@ int main()
     /*
     We can transform container to the encrypted byte string. Let's do it
     */
-    uint8_t * container_data = new uint8_t[PQC_asymmetric_container_size(new_container)];
+    std::shared_ptr<uint8_t[]> container_data(new uint8_t[PQC_asymmetric_container_size(new_container)]);
 
     // aes will use for string encryption
     uint8_t creation_key[PQC_AES_KEYLEN] = {1, 2, 3, 4, 5, 6, 7, 8, 9, 0, 1, 2, 3, 4, 5, 6,
                                             7, 8, 9, 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 0, 1, 2};
     uint8_t creation_iv[PQC_AES_IVLEN] = {9, 8, 7, 6, 5, 6, 7, 8, 9, 0, 1, 2, 3, 4, 5, 6};
 
     size_t result = PQC_asymmetric_container_get_data(
-        new_container, container_data, PQC_asymmetric_container_size(new_container), creation_key, PQC_AES_KEYLEN,
+        new_container, container_data.get(), PQC_asymmetric_container_size(new_container), creation_key, PQC_AES_KEYLEN,
         creation_iv, PQC_AES_IVLEN
     );
     if (result != PQC_OK)
@@ -60,8 +60,8 @@ int main()
     Let's restore container from string. The keys inside should be equal with others we generated before
     */
     PQC_CONTAINER_HANDLE resultContainer = PQC_asymmetric_container_from_data(
-        PQC_CIPHER_MCELIECE, container_data, PQC_asymmetric_container_size(new_container), creation_key, PQC_AES_KEYLEN,
-        creation_iv, PQC_AES_IVLEN
+        PQC_CIPHER_MCELIECE, container_data.get(), PQC_asymmetric_container_size(new_container), creation_key,
+        PQC_AES_KEYLEN, creation_iv, PQC_AES_IVLEN
     );
     if (resultContainer == PQC_FAILED_TO_CREATE_CONTAINER)
     {
@@ -88,8 +88,6 @@ int main()
         return 1;
     }
 
-    delete[] container_data;
-
     PQC_asymmetric_container_close(new_container);
     PQC_asymmetric_container_close(resultContainer);
 

examples/sha3/const_size_sha3_example.cpp

@@ -3,6 +3,7 @@
 // Look shake_sha3_example.cpp to use arbitary size of hash.
 #include <cstring>
 #include <iostream>
+#include <memory>
 
 #include <pqc/sha3.h>
 
@@ -50,10 +51,10 @@ int main(void)
         std::cout << "\nERROR!!! Returned value must be equal to hash size of this mode!" << std::endl;
 
     // create memory space for hash result
-    uint8_t * hash = new uint8_t[hash_size];
+    std::shared_ptr<uint8_t[]> hash(new uint8_t[hash_size]);
 
     size_t pqc_hash_retrieve_return = PQC_hash_retrieve(
-        sha3, hash, hash_size
+        sha3, hash.get(), hash_size
     ); // PQC_hash_retrieve gets hash from message. pqc_hash_retrieve_return should be equal to PQC_OK
     if (pqc_hash_retrieve_return != PQC_OK)
         std::cout << "\nERROR!!! Returned value must be PQC_OK if operation was done successfully";
@@ -65,7 +66,7 @@ int main(void)
 
 
     // Verification. Hash should be similar with constant digest message for this initial message
-    if (memcmp(hash, expected, sha_len / 8) == 0)
+    if (memcmp(hash.get(), expected, sha_len / 8) == 0)
     {
         std::cout << "Verification successfull" << std::endl;
     }
@@ -74,8 +75,5 @@ int main(void)
         std::cout << "Verification failed" << std::endl;
     }
 
-    // Free memory
-    delete[] hash;
-
     return 0;
 }