edgetk

1. Africacrypt 2009: Galindo-Garcia Identity-Based Signature (IBS)
2. Anubis Involutional SPN 128-bit block cipher (Barreto, ESAT/COSIC)
3. Asiacrypt 2001: Short Signatures from the Weil Pairing (BLS)
4. Asi­acrypt 2005: Barreto Identity-Based Signature (IBS)
5. BSI TR-03111 Elliptic Curve Cryptography (ECC) Technical Guideline
6. CHASKEY Message Authentication Code (Nicky Mouha, ESAT/COSIC)
7. CubeHash and SipHash64/128 (Daniel J. Bernstein & JP Aumasson)
8. CRYPTO 1999: IND-CCA2 Fujisaki-Okamoto Transformation (IBE)
9. CRYPTO 2001: Boneh-Franklin Identity-Based Encryption (IBE)
10. DSTU 7564:2014 A New Standard of Ukraine: The Kupyna Hash Function
11. DSTU 7624:2014 A Encryption Standard of Ukraine: Kalyna Block Cipher
12. Eurocrypt 1996: Security Proofs for Signature Schemes (EUF-CMA ElGamal)
13. Eurocrypt 2004: Boneh-Boyen Identity-Based Encryption (IBE)
14. GB/T 32907-2016 - SM4 128-bit Block Cipher
15. GB/T 32918.4-2016 SM2 Elliptic Curve Asymmetric Encryption
16. GB/T 38636-2020 - Transport Layer Cryptography Protocol (TLCP)
17. GM/T 0001-2012 ZUC Zu Chongzhi Stream cipher 128/256-bit key
18. GM/T 0002-2012 SM4 Block cipher with 128-bit key
19. GM/T 0003-2012 SM2 Public key algorithm 256-bit
20. GM/T 0004-2012 SM3 Message digest algorithm 256-bit hash value
21. GM/T 0044-2016 SM9 Public key algorithm 256-bit
22. GM/T 0086-2020 Specification of key management system based on SM9
23. GOST 28147-89 64-bit block cipher (RFC 5830)
24. GOST R 34.10-2012 VKO key agreement function (RFC 7836)
25. GOST R 34.10-2012 public key signature function (RFC 7091)
26. GOST R 34.11-2012 Streebog hash function (RFC 6986)
27. GOST R 34.11-94 CryptoPro hash function (RFC 5831)
28. GOST R 34.12-2015 128-bit block cipher Kuznechik (RFC 7801)
29. GOST R 34.12-2015 64-bit block cipher Magma (RFC 8891)
30. GOST R 50.1.114-2016 GOST R 34.10-2012 and GOST R 34.11-2012
31. HC-128 Stream Cipher simplified version of HC-256 (Wu, ESAT/COSIC)
32. IGE (Infinite Garble Extension) Mode of Operation for Block ciphers
33. ISO/IEC 10118-3:2003 RIPEMD128/160/256 and Whirlpool (ESAT/COSIC)
34. ISO/IEC 18033-3:2010 HIGHT, SEED, Camellia and MISTY1 Block ciphers
35. ISO/IEC 18033-4:2011 SNOW 2.0 and KCipher-2 stream ciphers (RFC 7008)
36. ISO/IEC 29192-3:2012 Trivium Stream cipher with 80-bit key
37. ISO/IEC 18033-5:2015 IBE - Identity-based Encryption Mechanisms
38. ISO/IEC 18033-5:2015/Amd.1:2021(E) SM9 Mechanism
39. ISO/IEC 14888-3:2018 EC-SDSA Schnorr-based Signature Scheme
40. ISO/IEC 29192-2:2019 PRESENT, CLEFIA and LEA block ciphers
41. ISO/IEC 15946-5:2022 Barreto-Naehrig and Barreto-Lynn-Scott Curves
42. ITI DOC-ICP-01.01 Curve E-521 Brazilian Digital Signature Standard
43. KS X 1213-1 ARIA 128-bit block cipher with 128/192/256-bit keys
44. KS X 3246 LEA - Lightweight Encryption Algorithm (TTAK.KO-12.0223)
45. KS X 3262 LSH - A New Fast Secure Hash Function Family (in Korean)
46. LNCS 1838 - A One Round Protocol for Tripartite Diffie-Hellman
47. NIST SP800-186 X25519 Diffie-Hellman (OpenSSL compliant)
48. NIST SP800-38D GCM AEAD mode for 128-bit block ciphers (RFC 5288)
49. NIST SP800-232 Ascon-Based Lightweight Cryptography Standard
50. PiLBA 2008: The Curupira-2 Block Cipher for Constrained Platforms
51. PKC 2003: Cha-Cheon Identity-Based Signature (IBS)
52. RFC 1423: Privacy Enhancement for Internet Electronic Mail
53. RFC 2104: HMAC - Keyed-Hashing for Message Authentication
54. RFC 2144: CAST-128 64-bit Block cipher with 128-bit key
55. RFC 2612: The CAST-256 Encryption Algorithm
56. RFC 3610: Counter with CBC-MAC Mode of Operation (CCM Mode)
57. RFC 4009: The SEED Encryption Algorithm (KISA)
58. RFC 4253: Serpent 128-bit Block cipher with 128/192/256-bit keys
59. RFC 4493: Cipher-based Message Authentication Code (CMAC)
60. RFC 4503: Rabbit Stream Cipher Algorithm with 128-bit key
61. RFC 4543: Galois Message Authentication Code (GMAC)
62. RFC 4764: EAX Authenticated-Encryption Mode of Operation
63. RFC 4648: Base16, Base32, and Base64 Data Encodings
64. RFC 5246: Transport Layer Security (TLS) Protocol Version 1.2
65. RFC 5280: Internet X.509 PKI Certificate Revocation List (CRL)
66. RFC 5297: Synthetic Initialization Vector (SIV Mode)
67. RFC 5639: Elliptic Curve Cryptography (ECC) Brainpool Standard Curves
68. RFC 5869: HMAC-based Key Derivation Function (HKDF)
69. RFC 6114: The 128-Bit Blockcipher CLEFIA (Sony)
70. RFC 7008: KCipher-2 Encryption Algorithm (KDDI R&D Laboratories)
71. RFC 7253: OCB3 Offset Codebook Authenticated-Encryption Algorithm
72. RFC 7292: PKCS #12 Personal Information Exchange Syntax v1.1
73. RFC 7539: ChaCha20-Poly1305 AEAD Stream cipher
74. RFC 7693: The BLAKE2 Cryptographic Hash and MAC (JP Aumasson)
75. RFC 7748: Curve25519 and Curve448: Elliptic Curves for Security
76. RFC 7914: The Scrypt Password-Based Key Derivation Function
77. RFC 8032: Ed25519 Signature a.k.a. EdDSA (Daniel J. Bernstein)
78. RFC 8446: Transport Layer Security (TLS) Protocol Version 1.3
79. RFC 8554: Post-Quantum Leighton-Micali Hash-Based Signatures
80. RFC 9058: MGM AEAD mode for 64 and 128 bit ciphers (E. Griboedova)
81. RFC 9367: GOST Cipher Suites for Transport Layer Security (TLS 1.3)
82. SAC 2002: Hess Efficient Identity Based Signature (IBS)
83. SBRC 2007: Curupira1 96-bit block cipher with 96/144/192-bit keys
84. STB 34.101.31-2011 Belarusian standard (Bel-T) block cipher
85. STB 34.101.45-2013 Belarusian BignV1 public key algorithhm
86. STB 34.101.77-2020 Belarusian standard BASH hash function
87. TTAS.KO-12.0004/R1 128-bit Block Cipher SEED (ISO/IEC 18033-3:2010)
88. TTAS.KO-12.0040/R1 64-bit Block Cipher HIGHT (ISO/IEC 18033-3:2010)
89. TTAS.KO-12.0011/R2 HAS-160 Korean-standardized hash algorithm
90. TTAK.KO-12.0015/R3 EC-KCDSA Korean Digital Signature Algorithm
91. TTAK.KO-12.0223 LEA 128-bit block cipher (ISO/IEC 29192-2:2019)
92. TTAK.KO-12.0276 LSH Message digest algorithm (KS X 3262)
93. US FIPS 197 Advanced Encryption Standard (AES)
94. US FIPS 180-2 Secure Hash Standard (SHS) SHA1 and SHA2 Algorithms
95. US FIPS 202 SHA-3 Permutation-Based Hash (instance of the Keccak)
96. US FIPS 203 Module-Lattice-Based Key-Encapsulation Mechanism (ML-KEM)
97. US FIPS 204 Module-Lattice-Based Digital Signature Standard (ML-DSA)
98. US FIPS 205 Stateless Hash-Based Digital Signature Standard (SLH-DSA)

🇨🇳 SM2, SM3, SM4, SM9, ZUC — Chinese national cryptographic standards

Defined by the State Cryptography Administration (SCA) and standardized under GB/T and GM/T series. Widely used in Chinese government, banking, and telecom infrastructure.

🇷🇺 GOST R 34.10, Kuznechik, Streebog — Russian Federation cryptographic standards

Approved by FSTEC and Federal Security Service (FSB), standardized under GOST R series. Used across official and military systems in Russia.

🇺🇦 Kalyna, Kupyna — Ukrainian national cryptographic standards

Standardized as DSTU 7624:2014 (Kalyna block cipher) and DSTU 7564:2014 (Kupyna hash function) by the Ukrainian State Service for Special Communications and Information Protection.

🇰🇷 ARIA, SEED, LEA, LSH, KCDSA — Korean national cryptographic algorithms

Developed under TTAS.KO and KS X standards. Used in public sector systems and Korean financial institutions. Published by KISA and TTA.

🇧🇾 BignV1, Bel-T, BASH — Belarusian cryptographic standards

Standardized by the STB 34.101 series. Designed for public key encryption (BignV1), block cipher encryption (Bel-T), and hashing (BASH), primarily for use within Belarusian national security frameworks.

🇫🇷 ANSSI FRP256v1 — French national elliptic curve for digital signatures

Developed by the ANSSI (Agence nationale de la sécurité des systèmes d’information). Used for secure digital signature implementations within French governmental and critical infrastructure systems.

🇯🇵 KCipher-2, Camellia — Japanese national cryptographic algorithms

KCipher-2 is a lightweight stream cipher standardized under ISO/IEC 18033-4:2011.
Camellia is a block cipher developed by Mitsubishi and NTT, internationally adopted and widely used in Japan for various secure communications.

🇧🇷 ITI DOC-ICP-01.01 — Brazilian Cryptographic Standards for Public-Key Algorithms

Brazil’s national public key cryptographic standards are defined in the DOC-ICP-01.01, issued by the Instituto Nacional de Tecnologia da Informação (ITI) under the ICP-Brasil framework. This standard mandates the use of internationally recognized and security-reviewed asymmetric algorithms, including:

• RSA (minimum key size of 2048 bits for end-entities and 4096 bits for CAs),
• Elliptic Curve Cryptography (ECC) using brainpool curves (e.g., brainpoolP256r1, brainpoolP512r1),
• EdDSA over Ed25519 (Curve25519), Ed448-Goldilocks (Curve448), and Ed521 (Curve E-521), defined as a high-security elliptic curve consistent with 256-bit security strength, considered for future-safe digital signatures mechanism.
• ECDH / ECDHE for key agreement protocols, including X25519 and X448 variants.

These algorithms are officially approved through the Instrução Normativa ITI nº 22, de 23 de março de 2022, which consolidates and updates the cryptographic requirements under Brazilian law, ensuring strong digital security for certificates and signatures in national electronic documents and transactions.

Source:
ICP-Brasil – DOC-ICP-01.01, v5.0 (2022)
Instrução Normativa ITI nº 22/2022 – Instituto Nacional de Tecnologia da Informação

🇸🇦 SNOW 2.0, Sosemanuk — Saudi Arabian national stream cipher standards

Defined by the National Cybersecurity Authority (NCA) under the National Cryptographic Standards (NCS) framework. Approved for protecting sensitive data within Saudi governmental and critical infrastructure systems.

• SNOW 2.0 — Stream cipher standardized under ISO/IEC 18033-4.

  • 128-bit key — MODERATE security level
  • 256-bit key — ADVANCED security level

• Sosemanuk — Stream cipher from the eSTREAM project.

  • 128-bit and 256-bit keys — MODERATE security level
  • Not approved for ADVANCED security level

Source:
https://nca.gov.sa/ncs_en.pdf
National Cryptographic Standards (NCS–1:2020)

🇩🇪 EC-GDSA, EC-SDSA, ECKA-EG, Brainpool — German national elliptic curve cryptographic standards

Standardized by the BSI (Federal Office for Information Security) in the technical guideline BSI TR-03111, these cryptographic algorithms and curve parameters are used for secure digital signatures, key exchange, and public key infrastructures in German governmental and high-security environments.

• EC-GDSA (German Digital Signature Algorithm): A flexible variant of ECDSA with enhanced domain separation and customization capabilities, adapted for German security requirements.
• EC-SDSA (Schnorr Digital Signature Algorithm): A curve-based implementation of the Schnorr signature scheme, offering provable security and better efficiency than ECDSA, defined in ISO/IEC 14888-3:2018.
• ECKA-EG (Elliptic Curve Key Agreement – ElGamal): A key agreement scheme based on EC-ElGamal, enabling secure exchange of symmetric keys.
• Brainpool curves: A family of elliptic curves (e.g., brainpoolP256r1, brainpoolP384r1, brainpoolP512r1) defined in RFC 5639, recommended by the BSI for use with the above algorithms. Designed to offer high security without potential concerns associated with some NIST curves.

These standards are applied in German eID systems, national PKI, military communication, and EU-coordinated cybersecurity frameworks.

🇺🇸 AES, SHA-1, SHA-2, SHA-3, X25519, Ed25519, Ascon — United States NIST cryptographic standards

• AES (Advanced Encryption Standard, FIPS 197) for symmetric encryption;
• SHA-1 and SHA-2 (Secure Hash Standard, FIPS 180-2);
• SHA-3 (based on Keccak, FIPS 202) for hashing;
• Elliptic curve algorithms X25519 and Ed25519 standardized in NIST SP800-186;
• Lightweight authenticated encryption algorithm Ascon standardized under NIST SP800-232.

All maintained and published by the National Institute of Standards and Technology (NIST) for U.S. federal government use and adoption.

🇪🇺 Whirlpool, RIPEMD, PRESENT, BLS/BN curves — European cryptographic standards (ISO/IEC)

Developed by researchers from Belgium, Germany, and Austria, these algorithms have been standardized by ISO/IEC for international use.

• Whirlpool: A hash function designed by Vincent Rijmen (Belgium) and Paulo Barreto, standardized in ISO/IEC 10118-3:2003.
• RIPEMD: Developed under the EU-funded RIPE project, standardized in the same ISO/IEC 10118-3 family (RIPEMD-128/160/256).
• PRESENT: A lightweight block cipher co-developed by TU Graz (Austria) and Ruhr-University Bochum (Germany), standardized in ISO/IEC 29192-2:2019 for constrained devices.
• BLS (Barreto-Lynn-Scott) and BN (Barreto-Naehrig) curves: Pairing-friendly elliptic curves standardized in ISO/IEC 15946-5:2022, widely used in identity-based and pairing-based cryptography.
• Identity-Based Encryption (IBE): General IBE mechanisms standardized in ISO/IEC 18033-5:2015, including several schemes developed and formalized by researchers at EU institutions.

These algorithms reflect Europe’s strong academic and institutional contributions to international cryptographic standards.

🌐 Other Notable Cryptographic Curves

🇮🇳 KG-256r1, KG-384r1 (Indian research) — Proposed by Kunal Abhishek and Dr. E. George Dharma Prakash Raj, 2021.
🇪🇺 Tom-256, Tom-384 (European research) — Benchmark curve referenced in IACR ePrint 2021/1183.

OpenSSL-PHP

<?php
function encrypt($plaintext, $key, $aad = '') {
    $nonceSize = 12; // Chacha20-Poly1305 standard nonce size

    $nonce = random_bytes($nonceSize);
    $ciphertext = openssl_encrypt(
        $plaintext,
        'chacha20-poly1305',
        $key,
        OPENSSL_RAW_DATA,
        $nonce,
        $tag,
        $aad
    );
    return $nonce . $ciphertext . $tag;
}

function decrypt($ciphertext, $key, $aad = '') {
    $nonceSize = 12; // Chacha20-Poly1305 standard nonce size
    $tagSize = 16;   // Assuming a 16-byte tag

    $nonce = substr($ciphertext, 0, $nonceSize);
    $tag = substr($ciphertext, -$tagSize);
    $ciphertext = substr($ciphertext, $nonceSize, -$tagSize);

    return openssl_decrypt(
        $ciphertext,
        'chacha20-poly1305',
        $key,
        OPENSSL_RAW_DATA,
        $nonce,
        $tag,
        $aad
    );
}

// Example usage:
$keyHex = ''; // Provide your key in hexadecimal format
$key = hex2bin($keyHex);
$plaintext = "Hello, Chacha20-Poly1305!";

// Encrypt
$ciphertext = encrypt($plaintext, $key);
echo "Encrypted: " . bin2hex($ciphertext) . PHP_EOL;

// Decrypt
$decrypted = decrypt($ciphertext, $key);
echo "Decrypted: " . $decrypted . PHP_EOL;
?>

libsodium Python

import nacl.bindings
import binascii

# Fixed key (32 bytes)
key_hex = "000102030405060708090a0b0c0d0e0f101112131415161718191a1b1c1d1e1f"
key = binascii.unhexlify(key_hex)

# Open the file generated by EDGETk (nonce + ciphertext + tag)
with open("ciphertext.bin", "rb") as f:
  data = f.read()

# Extract the nonce (12 bytes), and ciphertext + tag (remaining bytes)
nonce = data[:12]
ciphertext_and_tag = data[12:]

# Decrypt using libsodium (via PyNaCl bindings)
try:
  plaintext = nacl.bindings.crypto_aead_chacha20poly1305_ietf_decrypt(
      ciphertext_and_tag,  # ciphertext + tag
      aad=None,            # no AAD (Additional Authenticated Data) was used
      nonce=nonce,
      key=key
  )
  print("Decrypted message:", plaintext.decode())
except Exception as e:
  print("Decryption failed:", e)

Parameters

• $l \in {128, 192, 256}$ — Security level.
• $q$ — A $2l$-bit prime number.
• $G$ — A generator of an Abelian group $\langle G \rangle$ of order $q$.
• $H$ — An external hash function: $H: {0, 1}^* \to {0, 1}^{2l}$.
• $OID(H)$ — An identifier uniquely identifying the hash function $H$ (an ASN.1 object identifier).
• $h$ — An internal hash function: $h: {0, 1}^* \to {0, 1}^l$.

Private Key

• $d$ — A secret random/pseudorandom element from ${1, 2, \dots, q-1}$.

Public Key

• $Q = dG$ — The public key associated with the private key $d$.

Message to be signed

• $X \in {0, 1}^*$.

Signing

The signature $s$ of a message $X$ is generated as follows:

1. Choose $k$:
   Select a random (or pseudorandom) value $k$ from ${1, 2, \dots, q-1}$.

2. Calculate $R$:
   $R = kG$ — The point $R$ is calculated by multiplying the random value $k$ by the generator $G$.

3. Calculate $s_0$:
   $s_0 = h(OID(H) | R | H(X))$ — Here, $s_0$ is computed by the internal hash function $h$, which involves the identifier of $H$, $R$, and the hash of the message $H(X)$.

4. Calculate $s_1$:
   $s_1 = (k - H(X) - (s_0 + 2^l) d) \mod q$ — The value $s_1$ is computed using $k$, $H(X)$, $s_0$, and the private key $d$, with a modular operation based on the prime $q$.

5. Final signature:
   $s = s_0 | s_1$ — The final signature $s$ is the concatenation of $s_0$ and $s_1$.

6. Return the signature:
   The signature $s$ is returned.

Verification

To verify the signature $s = s_0 | s_1$ of a message $X$ with public key $Q$:

1. Verify the length of $s$:
   If $|s| \neq 3l$, return 0 (invalid signature).

2. Extract $s_0$ and $s_1$:
   Split $s = s_0 | s_1$, where $|s_0| = l$ and $|s_1| = 2l$.

3. Verify $s_1$:
   If $s_1 \geq q$, return 0 (invalid signature).

4. Calculate $R$:
   Compute $R = (s_1 + H(X))G + (s_0 + 2^l)Q$.

5. Verify $R$:
   If $R = O$ (the identity element of the group), return 0 (invalid signature).

6. Verify the hash:
   If $h(OID(H) | R | H(X)) \neq s_0$, return 0 (invalid signature).

7. Valid signature:
   If all checks pass, return 1 (valid signature).

Design Rationale

1. Short signatures:
   The algorithm uses Schnorr’s compression and reduces the length of $s_0$ from $2l$ to $l$ bits, resulting in shorter signatures and faster verification (1.5 exponentiations instead of 2).

2. Pre-hashing:
   Instead of directly using $h(R | X)$, the algorithm uses pre-hashing: $s_0 = h(OID(H) | R | H(X))$. This protects against multiple-target preimage attacks and facilitates integration with existing APIs and data formats.

3. “Whitening” the signature:
   The second part of the signature ($s_1$) is “whitened” by using $Y = H(X)$. This makes finding collisions more difficult, providing security with strength $2^l$.

4. Use of $Q$ during verification:
   While hashing $Q$ during signature generation could help protect against certain attacks, this approach is rejected, as key distribution should already provide protection, and hashing $Q$ would duplicate the proof of possession during key distribution.

5. Deterministic signature:
   The generation of the ephemeral public key $k$ can be made deterministic using a special key generation algorithm $genk$. This involves hashing and symmetric encryption of data such as $OID(H)$, $d$, and $H(X)$ to produce a unique $k$.

Key Generation

1. Private Key (sk): Randomly selected from $r \in \mathbb{Z}_n$, where $n$ is the curve order. It must remain secret.
2. Public Key (pk): $pk = sk * G2$, where $G2$ is the generator point of the curve.

Signing

1. Choose $k \in \mathbb{Z}_n$, keep it secret, and ensure it’s never reused.
2. Compute $\sigma = k \cdot H(M)$, where $H(M)$ is the hash of the message $M$.
3. The final signature is $\sigma = sk \cdot H(M)$, where $sk$ is the private key and $H(M)$ is the hash of the message.

Verification

1. Verify the signature: $e(σ, G2) = e(H(M), pk)$, where $e$ is the bilinear pairing.
2. If the pairing holds, the signature is valid; otherwise, it’s invalid.

Verification Equation:

$e(sk * H(M), G2) = e(H(M), sk * G2)$, or equivalently, $e(H(M), pk) = e(H(M), pk)$. If true, the signature is valid.

Key Generation

1. Generate a large prime number $p$.
2. Select a generator $g \in [2, p-2]$.
3. Generate a private key $x$ randomly.
4. Compute the public key $Y = g^x \mod p$.

Digital Signature

1. Select a random value $k$ such that $1 < k < p-1$, $\text{gcd}(k, p-1) = 1$.
2. Compute the first signature component: $r = g^k \mod p$.
3. Compute the second signature component: $s \equiv (H(m) - x \cdot r) \cdot k^{-1} \mod (p-1)$.

Digital Signature Verification

1. Receive the message $m$ and the signature components $(r, s)$.
2. Compute $w \equiv s^{-1} \mod (p-1)$.
3. Compute $u_1 \equiv H(m) \cdot w \mod (p-1)$.
4. Compute $u_2 \equiv r \cdot w \mod (p-1)$.
5. Compute $v \equiv g^{u_1} \cdot Y^{u_2} \mod p$.
6. The signature is valid if $v \equiv r \mod p$.

Key Agreement

1. Bob generates his key pair $(x_B, Y_B)$.
2. Bob shares his public key $Y_B$ with Alice.
3. Alice generates a random symmetric key $K_{\text{sym}}$.
4. Alice encrypts $K_{\text{sym}}$ using Bob’s public key: $a = g^{k_A} \mod p, \ b = Y_B^{k_A} \cdot K_{\text{sym}} \mod p$.
5. Alice sends the ciphertext $(a, b)$ to Bob.
6. Bob decrypts the received ciphertext using his private key to obtain: $K_{\text{sym}} = (b \cdot a^{-x_B}) \mod p$.
7. Now, both Alice and Bob have the shared symmetric key $K_{\text{sym}}$ for further communication.

First, Alice generates a private key $y$ and a public key of:

$Y = y \cdot G$

where $G$ is the base point on the curve. She can share this public key $Y$ with Bob. When Bob wants to encrypt something for Alice, he generates a random value $r$ and the message value $M$, and then computes:

$C_1 = r \cdot G$

$C_2 = r \cdot Y + M$

To decrypt, Alice takes her private key $y$ and computes:

$M = C_2 - y \cdot C_1$

This works because:

$M = C_2 - y \cdot C_1 = r \cdot y \cdot G + M - y \cdot r \cdot G = M$

Figure 1

The IBE’s Key Management System (KMS) consists of the Private Key Generator (PKG), Registration Agency (RA), Public Parameter Server (PPS), and User Terminal Entity (User/Client). The system architecture is illustrated in Figure 1. The functions of each entity are described below.

1. Private Key Generation Center (PKG):

• Function: Uses the system master key and related parameters to generate private keys for users. Provides related management and query services.

2. Registration Service (RA):

• Functions:
  • Undertakes tasks related to user key application registration, authentication, management, and business communication with PKG.
  • Provides symmetric, asymmetric, and hash cryptographic services.
  • Receives key data returned by PKG and writes it into the key carrier of the terminal entity.

3. Public Parameter Service (PPS):

• Function: A user-oriented information service system, providing publicly accessible addresses for secure query and distribution of public parameters and policies. Public parameters include password parameters and user ID status directories that can be shared publicly.

4. User Terminal Entity (User/Client):

• Functions:
  • Terminal application system of the user information service system.
  • Applies for keys directly from PKG or through a local agent.
  • Realizes the storage and use of its own private keys.

IBE Key Management System Architecture:

• Secure Channels: The generation and distribution of user keys mainly involve entities such as PKG, RA, and User/Client. This is achieved by establishing secure channels between PKG and RA, and between RA and User/Client, ensuring secure transfer and download of keys.

Summary: The architecture of the IBE Key Management System ensures secure generation of private keys by PKG, tasks of key registration and application are carried out by RA, public parameters are provided by PPS, and users interact with the system through the User/Client terminal. Secure channels facilitate the transfer and download of keys between these entities, ensuring the overall security of the key management system.

Threshold IBE enhances the classic Boneh-Franklin scheme by introducing a distributed Private Key Generator (PKG). Instead of a single trusted entity holding the master secret key, the secret is shared across multiple servers using Shamir’s Secret Sharing. To extract a private key for a given identity, at least $t$ out of $n$ servers must collaborate. Each server computes a partial key share, which is then combined via Lagrange interpolation to reconstruct the user’s full private key. This model mitigates single points of failure and strengthens resilience against key compromise.

1. Setup (master authority splits the secret)

• Let $s \in \mathbb{Z}_q$ be the master secret (the PKG’s private key).
• A random polynomial of degree $t - 1$ is defined as $f(x) = s + a_1 x + a_2 x^2 + \dots + a_{t-1} x^{t-1}$.
• Each server $i \in {1, 2, \dots, n}$ receives a partial key (a point on the polynomial): $s_i = f(i)$.
• The public key of the system is: $P_{\text{pub}} = s \cdot P$.

2. Partial Key Extraction (by each server)

• The identity is mapped to a point on the elliptic curve group: $Q_{\text{ID}} = H_1(\text{ID}) \in G_1$.
• Each server computes its partial private key: $d_i = s_i \cdot Q_{\text{ID}}$.

3. Combining Partial Keys (Lagrange Interpolation)

• Given a subset of $t$ partial keys $d_{i_1}, d_{i_2}, \dots, d_{i_t}$, compute the Lagrange coefficients:
  $\lambda_j = \prod_{\substack{1 \leq k \leq t \ k \ne j}} \frac{x_k}{x_k - x_j}$.
• The final private key for the identity is reconstructed as:
  $d_{\text{ID}} = \sum_{j=1}^{t} \lambda_j \cdot d_{i_j} = s \cdot Q_{\text{ID}}$.

This Threshold IBE/IBS scheme supports the Cha-Cheon, Hess, and Boneh-Franklin constructions, i.e., schemes where the private key lies in $G_1$, the public key lies in $G_2$, and the private key extraction involves only linear operations (scalar multiplication), without requiring inversion or non-linear computations. This compatibility is crucial for enabling threshold key extraction via Shamir’s Secret Sharing, as each server can compute a partial key share in $G_1$, which can then be linearly combined using Lagrange interpolation to reconstruct the full private key $s \cdot Q_{\text{ID}}$.

Key Generation

1. Generate a prime $q$ of the desired bit length.
2. Compute $p = 2q + 1$, and verify that $p$ is prime.
3. Find a generator $g$ of the subgroup of order $q$ in $\mathbb{Z}_p^*$.
4. Choose a private key $x \in [0, q - 1]$.
5. Compute the public key $y = g^x \mod p$.

Signing

1. Select a random $k \in [0, q - 1]$.
2. Compute $r = g^k \mod p$.
3. Compute the challenge $e = H(r \parallel m) \mod q$.
4. Compute the response $s = (k + e \cdot x) \mod q$.
5. The signature is the pair $(e, s)$.

Verification

1. Receive the message $m$, and signature $(e, s)$.
2. Compute $g^s \mod p$.
3. Compute $y^e \mod p$ and its modular inverse.
4. Compute $r’ = g^s \cdot (y^e)^{-1} \mod p$.
5. Compute $e’ = H(r’ \parallel m) \mod q$.
6. The signature is valid if $e’ = e$.

Notes

1. $H(m)$ represents a cryptographic hash function (e.g., SHA-256).
2. $k$ must be freshly generated for each signature and kept secret.
3. $\parallel$ denotes byte-wise concatenation.
4. The group $\mathbb{Z}_p^*$ must have a known subgroup of prime order $q$.
5. The hash function must be collision-resistant and preimage-resistant.

Summary instructions for TLCP connection:

1. Requester generates a signing key pair and submits a CSR to the CA.
2. CA issues the signature certificate based on the received CSR.
3. CA generates a new encryption key pair and creates a corresponding CSR using the original CSR as a template.
4. CA issues the encryption certificate and returns to the requester: the signature certi