> For the complete documentation index, see [llms.txt](https://esper.gitbook.io/esperchain-docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://esper.gitbook.io/esperchain-docs/architecture/publish-your-docs/isogeny-based-cryptography.md).

# Isogeny-based cryptography

### **What Is Isogeny-Based Cryptography?**

#### Core Idea:

It’s built on the **hardness of computing isogenies** — algebraic maps between elliptic curves that preserve group structure.

* You have two elliptic curves E\_1​ and E\_2​
* An **isogeny** is a morphism ϕ:E1→E2\phi: E\_1 \rightarrow E\_2ϕ:E1​→E2​ that respects point addition

> The hard problem: *Given E\_1​ and E\_2​, find the isogeny ϕ\phiϕ*

This is believed to be **hard even for quantum computers** — unlike ECDLP (used in Bitcoin/Ethereum), which Shor’s algorithm breaks.

***

### **Mathematical Foundations**

Isogeny cryptography involves:

| Concept                  | Role in Cryptography                                 |
| ------------------------ | ---------------------------------------------------- |
| **Elliptic curves**      | Base structure for keys and maps                     |
| **Isogeny graphs**       | Nodes = curves, edges = isogenies                    |
| **Supersingular curves** | Provide rich algebraic structure over finite fields  |
| **Class groups**         | Act on isogeny classes in certain systems            |
| **Quaternion algebras**  | Used to represent isogenies algebraically            |
| **Modular curves**       | Classify isogeny relations (like X0(N)X\_0(N)X0​(N)) |

These structures can build **key exchange**, **digital signatures**, and even **VDFs (verifiable delay functions)**.

***

### **Key Isogeny-Based Cryptographic Schemes**

| Scheme                                          | Use Case                        | Description                                                    | Status                           |
| ----------------------------------------------- | ------------------------------- | -------------------------------------------------------------- | -------------------------------- |
| **SIDH** (Supersingular Isogeny Diffie-Hellman) | Key exchange                    | Diffie-Hellman analog using isogeny walks                      | ❌ Broken in 2022                 |
| **SIKE** (SIDH + key encapsulation)             | Public key encryption           | NIST finalist (was)                                            | ❌ Broken (Castryck–Decru 2022)   |
| **CSIDH** (Commutative SIDH)                    | Static key exchange, signatures | Uses commutative group action (class group) on ordinary curves | ✅ Research-active                |
| **SQISign**                                     | Digital signatures              | Short signatures using quaternion-based trapdoors              | ✅ Post-quantum, competitive size |
| **SeaSign**, **GPST**                           | Signatures                      | Variants improving performance and compression                 | ✅ Under development              |

***

### **How Can Isogeny-Based Crypto Be Used in Blockchains?**

Let’s map them to **blockchain security primitives**:

| Blockchain Function        | Isogeny-Based Tool                            | Benefit                                      |
| -------------------------- | --------------------------------------------- | -------------------------------------------- |
| Account Authentication     | SQISign, CSIDH-based signatures               | Post-quantum signatures with small key sizes |
| Key Exchange (e.g., P2P)   | CSIDH or SIDH (if fixed)                      | Secure handshakes between nodes              |
| Validator Keys             | SQISign or hybrid keys                        | Quantum-proof consensus signing              |
| zkRollup Circuits          | Isogeny-based VDF or isogeny-in-ZK            | Delay or prove state changes securely        |
| Verifiable Delay Functions | Isogeny walks (e.g., VDF via expander graphs) | Cheap unspoofable randomness                 |
| Smart Contract Conditions  | Verify isogeny path proofs                    | Secure proofs of access or identity          |

***

### **SQISign: A Blockchain-Ready Signature Scheme**

#### Key Features:

* **Short signatures**: \~200–300 bytes (competitive with ECDSA)
* **Based on class group action and quaternion algebras**
* **Post-quantum secure**
* Practical to implement (unlike SPHINCS+ which has \~16KB signatures)

#### Potential Blockchain Use:

* Replace Ed25519 or ECDSA for validator or user accounts
* Enable hybrid signature schemes (ECDSA + SQISign)
* Add support for it in account abstraction or programmable verification systems

***

### **Challenges to Using Isogeny-Based Crypto**

| Challenge                           | Explanation                                                                           |
| ----------------------------------- | ------------------------------------------------------------------------------------- |
| **Slow computation**                | Isogeny pathfinding is slower than EC scalar mult                                     |
| **Implementation complexity**       | Quaternion algebras, ideal class computations require special libraries               |
| **Trusted setup for some variants** | Trapdoor generation must be securely done                                             |
| **SIDH is broken**                  | Early optimism dampened by attacks — only non-SIDH schemes like SQISign remain viable |

***

### **Research Directions**

| Area                                     | Focus                                                           |
| ---------------------------------------- | --------------------------------------------------------------- |
| **CSIDH optimization**                   | Reduce size and improve signing speed                           |
| **Circuit-compatible isogeny verifiers** | Use isogeny-based math inside SNARK/STARK provers               |
| **Post-quantum wallets**                 | Add isogeny key support for high-security users                 |
| **Hybrid consensus keys**                | Validators sign with both Ed25519 and SQISign                   |
| **Bridge security**                      | Replace threshold signatures with PQ-safe ones (CSIDH multisig) |

***

### Summary Table

| Scheme            | Application              | Quantum-Safe? | Used in Blockchain Yet?           |
| ----------------- | ------------------------ | ------------- | --------------------------------- |
| **SQISign**       | Signatures               | ✅ Yes         | Research-ready                    |
| **CSIDH**         | Key exchange, signatures | ✅ Yes         | Theoretical, not production yet   |
| **SIDH/SIKE**     | Encryption               | ❌ Broken      | Was candidate, now defunct        |
| **Isogeny VDFs**  | Delay/randomness         | ✅ Yes         | Used in theoretical VDF protocols |
| **Isogeny-in-ZK** | Proofs of knowledge      | ✅ Yes         | Future zkRollup use cases         |

Let's jump into 2 prospective options here SQISign and CSIDH.

***

### 🔵 **CSIDH (Commutative Supersingular Isogeny Diffie-Hellman)**

#### 💡 Core Concept:

CSIDH is a **Diffie-Hellman-style key exchange** scheme, but instead of scalar multiplication on a single elliptic curve, it uses **class group actions on a set of elliptic curves** over Fp\mathbb{F}\_pFp​.

***

#### 📚 Mathematical Framework:

* Let E\mathcal{E}E be the set of supersingular elliptic curves over Fp\mathbb{F}\_pFp​.
* Let Cl(O)\text{Cl}(\mathcal{O})Cl(O) be the class group of a certain quadratic order.
* Each **ideal class** a∈Cl(O)\mathfrak{a} \in \text{Cl}(\mathcal{O})a∈Cl(O) acts on a curve E∈EE \in \mathcal{E}E∈E by isogeny:

  E′=a∗EE' = \mathfrak{a} \* EE′=a∗E
* The action is **commutative**, allowing classic DH-like key agreement.

***

#### 🔐 Key Exchange (Blockchain Context):

**Setup:**

* Curve E\_0​ is fixed and public.
* Alice selects secret ideal class a\mathfrak{a}a → public key: EA=a∗E0E\_A = \mathfrak{a} \* E\_0EA​=a∗E0​
* Bob selects secret b\mathfrak{b}b → public key: EB=b∗E0E\_B = \mathfrak{b} \* E\_0EB​=b∗E0​

**Shared secret:**

Alice computes: a∗EB,Bob computes: b∗EA\text{Alice computes: } \mathfrak{a} \* E\_B,\quad \text{Bob computes: } \mathfrak{b} \* E\_AAlice computes: a∗EB​,Bob computes: b∗EA​

These yield the same curve due to commutativity.

***

#### 🔗 Blockchain Applications

**✅ Use Case 1: Post-Quantum Key Exchange**

* Node-to-node encrypted channels (e.g., validator gossip layer)
* Blockchain-enforced VPNs (ZKMesh-style)

**✅ Use Case 2: Account Key Derivation**

* Derive account addresses from isogeny path result curves
* Can be combined with ZK-proof of path knowledge for account abstraction

**✅ Use Case 3: Quantum-Resistant Multisig**

* Combine multiple ideal class actions to derive shared public curves

***

#### ⚠️ Practical Challenges

* Requires custom curve and field support
* Public key is a full curve description (not a point)
* Slower than ECDH but acceptable for setup, not frequent signing

***

### 🟣 **SQISign (Short Quaternion Isogeny Signature)**

#### 💡 Core Concept:

SQISign is a **digital signature scheme** based on:

* The hardness of finding **short isogeny paths**
* The structure of **quaternion algebras**
* **Class group actions** on supersingular curves

***

#### 📚 Mathematical Foundation

**Signing:**

* Your private key is a secret **ideal class** a\mathfrak{a}a
* Your public key is the result of acting on a fixed base curve E0E\_0E0​:

  Epub=a∗E0E\_{\text{pub}} = \mathfrak{a} \* E\_0Epub​=a∗E0​

To sign a message mmm:

1. Hash mmm into a challenge curve EcE\_cEc​
2. Use a **trapdoor** to find a short path (isogeny) from EcE\_cEc​ to EpubE\_{\text{pub}}Epub​
3. Compress that path into a signature

**Verifying:**

* Verifier checks that applying the path brings Ec→EpubE\_c \rightarrow E\_{\text{pub}}Ec​→Epub​

***

#### 🔗 Blockchain Applications

**✅ Use Case 1: Post-Quantum Account Authentication**

* Replace Ed25519 or ECDSA
* Very short signature (\~200–300 bytes)
* Public key = elliptic curve class; private key = trapdoor

**✅ Use Case 2: Validator Block Signing**

* Validators sign blocks using SQISign
* Combine with BLS-style compression for aggregation

**✅ Use Case 3: On-chain Proof of Ownership**

* Use Move or Solidity contracts to verify isogeny paths
* Or verify compressed ZK-proof that path exists (for gas efficiency)

***

#### 💻 Blockchain-Specific Integration Plan

**🔧 Hybrid Signature Contract (like in Arbitrum)**

* Use ECDSA + SQISign verifier contract
* Require both sigs to pass

**🔧 ZK Proof Wrapping**

* Wrap SQISign verification into a SNARK/STARK circuit
* Publish a zkProof instead of raw signature (gas-efficient)

**🔧 Account Abstraction**

* Signature scheme logic inside user account contract
* E.g., `AuthModule::verify(path, challenge_curve, pub_curve)`

***

#### ⚠️ Implementation Challenges

* Requires trapdoor setup and safe ideal generation
* Requires robust implementation of quaternion and class group ops
* Fewer libraries exist (not yet in widespread use)

***

### ✅ Comparison: CSIDH vs SQISign for Blockchain

| Feature         | CSIDH                       | SQISign                                 |
| --------------- | --------------------------- | --------------------------------------- |
| Type            | Key Exchange                | Digital Signature                       |
| Quantum-Safe    | ✅ Yes                       | ✅ Yes                                   |
| Signature Size  | N/A                         | \~200–300 bytes                         |
| Public Key Size | Large (curve data)          | Medium (curve ID + class info)          |
| Speed           | Slow (acceptable for setup) | Faster than SPHINCS+, slower than ECDSA |
| Usage           | Key exchange, multisig      | Validator/user signing                  |
| Libraries       | Few (csidh, libisogeny)     | Even fewer, but growing                 |

***


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://esper.gitbook.io/esperchain-docs/architecture/publish-your-docs/isogeny-based-cryptography.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.