Privately Generated Key Pairs

How It Works

The Two Vulnerabilities Current PKI Cannot Solve

Every secure digital transaction relies on a public–private key pair. The private key is the root of trust: whoever controls it can impersonate the user, forge signatures, and decrypt sensitive data. Despite decades of deployment, today’s Public Key Infrastructure (PKI) still depends on architectural tradeoffs that leave critical gaps in security and trust.

In many enterprise implementations, key generation and lifecycle management are delegated to trusted third parties such as Certificate Authorities (CAs) and Hardware Security Modules (HSMs). While these systems improve operational control, they concentrate risk: private keys may be exposed during generation, provisioning, or storage, and users must ultimately trust that no copies are retained or compromised. This creates persistent vulnerabilities to insider threats, supply chain attacks, and key interception.

Conversely, when users generate their own key pairs to preserve privacy and control, existing PKI frameworks lack a robust mechanism to verify that a submitted public key is legitimately bound to an authenticated user. This opens the door to impersonation and man-in-the-middle attacks, especially in distributed or zero-trust environments.

As a result, current systems force a fundamental tradeoff:

• Third-party PKI provides identity validation but weakens user sovereignty over private keys

• User-generated keys preserve privacy but lack reliable, scalable authentication

No conventional PKI architecture resolves both simultaneously.

Post-Quantum Public Key Infrastructure Without Third-Party Key Exposure

Our Solution: Private Key Generation With Independent Verification

Verification Without Exposure

Private Keys Stay Private

Eliminates the Weakest PKI Links

The CA independently verifies each public key using the shared cryptographic table, without ever knowing the private key. Users get both privacy and authenticated identity.

The private key is generated entirely on the user's device. It is never transmitted, never stored by a third party, and never seen by the CA or HSM.

The protocol removes dependence on HSMs for private key generation, eliminates the single point of failure at the CA, and mitigates man-in-the-middle attacks at the key distribution step.

The protocol operates in three phases: enrollment, key generation and signing, and CA verification.

Phase 1 - Enrollment (One Time)

1. Root of trust is established. During a secure enrollment session, each user's device establishes a crypto-table: a look-up table mapping challenges to responses, derived from one or more roots of trust. These can include a hardware token, biometrics, or a digital file. The CA retains the crypto-table; the user retains their root of trust source. Neither party can reconstruct the other's secret from what they hold.

Phase 2 - Key Generation and Signing (Each Session)

2. CA issues a challenge. The CA generates a random challenge and transmits it to the user's device over an open network. No sensitive information is exposed at this step.

3. User generates a response. The user's device feeds the challenge into its root of trust via the CRP mechanism and generates a seed. This seed is unique to the challenge-root combination and cannot be reconstructed without the root of trust.

4. User generates the key pair. Using the seed from the CRP response and a second independent random number generator, the user's device computes a public-private key pair via CRYSTALS-Dilithium. The private key never leaves the device.

5. User signs and transmits. The user signs a message with their private key and sends the message, signature, and public key to the CA. The hashed seed is transmitted separately to allow the CA to independently recover and verify the seed.

Phase 3 - CA Verification (Each Session)

6. CA independently recovers the seed. The CA runs the same CRP mechanism against its copy of the Crypto-Table and recovers the matching seed using the Response-Based Correction (RBC) search engine, then reconstructs the full public key, including the seed that was kept secret during transmission.

7. CA verifies the signature. With the reconstructed public key, the CA verifies the user's digital signature. If verification succeeds, the CA confirms three things: the message is valid, the public key is legitimate, and the user's device generated the key pair from an approved root of trust, all without ever seeing the private key.

8. Public key is published. The Registration Authority (RA) publishes the verified public key. For two-way authentication, the CA can transmit its own verification response back to the user, allowing the user to confirm the CA's authenticity as well.

Validated across 20,000 verification cycles with a 100% success rate. Implemented with CRYSTALS-Dilithium 2 (1,312-byte public keys; 2,420-byte signatures). Compatible with existing PKI infrastructure, including credit cards, SIM cards, financial platforms, and private networks, with no hardware replacement required.