An Internet Messenger Using Post-Quantum Cryptography Algorithms Based on Isogenies of Elliptic Curves

Abstract

This paper presents the design and implementation of an Internet-based instant messaging application that leverages post-quantum cryptographic algorithms founded on isogenies of elliptic curves. The system employs the CSIDH cryptosystem for key exchange and SeaSign for digital signatures, integrating these with the X3DH and Double-Ratchet protocols to enable end-to-end encryption for both text messages and binary file transfers. Key generation is supported for new users upon registration, ensuring robust cryptographic foundations from the outset. The performance of the CSIDH and SeaSign algorithms is evaluated at various security levels using a Python-based prototype, providing practical benchmarks. By combining isogeny-based cryptographic schemes with widely adopted secure messaging protocols, this work presents an illustration of a selected quantum-resistant communication solution and offers insights into the feasibility and practicality of deploying such protocols in real-world applications.

1. Introduction

Currently, elliptic curves form the basis for numerous widely used cryptographic systems. A prominent example is ECDH [1], which serves as a fundamental component in protocols such as TLS [2], IPsec [3], and the Signal Protocol [4]. The security of ECDH relies on the difficulty of calculating the discrete logarithm in an additive group. Although this problem remains computationally infeasible for classical computers, it can be calculated efficiently by a hypothetical quantum computer employing Shor’s [5] or the recently proposed Regev’s [6] algorithms. The discrete logarithm is not the only mathematically hard problem in elliptic curves. There are also the mappings known as isogenies. The related problem is to find such a mapping between two curves defined over a finite field. Importantly, this problem remains hard not only for classical computers but also for quantum computers.

The primary objective of this article is to describe and examine the practicality of selected isogeny-based post-quantum cryptographic protocols for real-world applications. Due to the significant compromise of the SIKE algorithm, isogeny-based approaches do not inherently inspire trust. Within the scope of this work, we also aimed to demonstrate that CSIDH and SeaSign, available at specific NIST security levels I, III, and V, can serve as a viable alternative. Therefore, we have provided our own complete implementation of the CSIDH algorithm, encompassing all required operations and elliptic curve Python classes. The entire implementation was developed from scratch using Python 3.11, and it represents our original solution. Furthermore, for signing the initial message within the instant messaging conversation, we developed the SeaSign algorithm, which, to our knowledge, represents the first openly accessible implementation of SeaSign entirely written in Python. We also present an Internet-based instant messenger featuring end-to-end encryption. The resulting desktop application (web-based using PyWebview 5.4), integrating Python and JavaScript 2024 was entirely authored by us. As backend support for the application, we used a built-in web database and employed a non-relational database in our implementation, specifically MongoDB, although no specific vendor is strictly required. This database constitutes our server, from which data is retrieved and to which data is uploaded. The encryption mechanisms are provided by employing the Extended Triple Diffie–Hellman (X3DH) key exchange and the Double-Ratchet algorithm. Both algorithms were thoroughly analyzed based on the Signal documentation [4]. Since direct Python implementations of these protocols exist, we decided to utilize the established patterns developed by the Signal Foundation. Due to our initiative, these were appropriately integrated with the CSIDH and SeaSign algorithms. Additionally, we conducted a performance analysis of the implemented solutions to assess the practical feasibility of the proposed cryptographic protocols—CSIDH and SeaSign.

The remainder of the paper is organized as follows. Section 2 contains a sketch of the most important literature positions related to the topic. Then, we deal with the background material (Section 3) necessary to understand our implementation. Therein, we widely describe the mathematics of isogeny. We also include descriptions of our implemented cryptosystems. Then, Section 4 focuses on demonstrating the concepts of end-to-end encryption. Section 5 describes the application infrastructure itself. Subsequently, Section 6 presents the complete results from the implemented algorithms. Finally, Section 7 summarizes the contribution and provides ideas on further topic studies.

2. Context and Related Work

The first documented concept of the usage of isogenies in cryptography dates back to 1997 (not published until 2006), when Jean-Marc Couveignes proposed the shared-key establishment system [7]. Independent of Couveignes, Anton Stolbunow described the same system, named CRS, in his master’s thesis [8]. However, the mentioned system was unusable in terms of practical aspects. For security at the level of AES-128, i.e., NIST I security level [9], the establishment process takes several minutes. Furthermore, in 2010, Childs, Jao, and Soukharev, in their work [10], proved that there exists a sub-exponential algorithm that breaks CRS.

The best known isogeny-based protocol is Supersingular Isogeny Diffie–Hellman (SIDH) key exchange. The system can be used in order to establish a shared secret key. A comprehensive description of SIDH appeared in 2014 [11]. SIDH is characterized by interactivity, practical efficiency in terms of time complexity (especially when juxtaposed to CRS), and its reliance on elliptic curves. It uses isogeny graphs with the vertices representing supersingular elliptic curves defined over the finite field ${\mathbb{F}}_{p^2}$, and the edges represent the isogenies between these curves. The extended version of SIDH, named Supersingular Isogeny Key Encapsulation (SIKE) [12], participated in the NIST competition for post-quantum cryptosystems. SIKE was one of the best candidates and reached the third round. Unfortunately for it, in 2022, Wouter Castryck and Thomas Decru [13] devised an attack on SIDH and, as a result, an attack on the instance of SIKE. The attack is valid only for instances that are directly based on the SIDH scheme, not for all isogeny-based cryptosystems.

Importantly, besides SIDH, another notable isogeny-based signing-scheme protocol is Short Quaternion and Isogeny Signature (SQISign). The protocol was proposed in 2020 by Luca De Feo et al. [14]. A distinctive feature of the algorithm, setting it apart from other isogeny-based protocols, is the connection of both sophisticated mathematical domains: quaternions and isogenies. Nevertheless, none of the proposed post-quantum signing schemes are able to guarantee the NIST I security level, and neither can SQISign, even though its keys and signings are compact and the signing scheme is practical.

At the time of writing this article, only one position [15] can be treated as competitive to our contributions since it also discusses the practical implementation of the CSIDH cryptosystem created by Wouter Castryck et al. [16]. The mentioned attack [13] is not applicable to CSIDH because the concept does not strictly rely on SIDH. While the cited work [15] outlines the concept of instant messenger, their solution does not offer end-to-end encryption unlike our proposed concept. Additionally, the authors use a latticed-based signing scheme: Falcon [17].

3. Materials and Methods

3.1. Isogenies of Elliptic Curves in Post-Quantum Cryptography

The mathematical details justifying the mode of operation of the presented protocols are given in Appendix A.

3.1.1. CSIDH: Protocol Scheme and Choice of the Parameters

Initially, small odd prime numbers ${\ell }_1,{\ell }_2,{\ell }_3,\dots ,{\ell }_n$ are chosen. To achieve a classical security level of 128 bits, we choose ℓ as $3,5,7,11,\dots ,367,373,587$. Thus, the prime p in ${\mathbb{F}}_p$ is $p=4\times 3\times 5\times 7\times 11\cdots \times 367\times 373\times 587-1$. This prime must satisfy the congruence $p\equiv 3(mod8)$. This construction ensures that elliptic curves defined over ${\mathbb{F}}_p$ are supersingular. Due to this form of p, there exist points with the order of ${\ell }_i$ for all i.

Subsequently, both parties need to establish their private key. The private key is represented by an n-element integer vector, where each integer component is randomly selected from the set $\{-m,\dots ,m\}$. Practically, m is not greater than 20, and according to [18,19], it is possible to use $m=1$ without losing a proper level of security (what we follow) for suitably large primes p. The private key is expressed as the vector $(e_1,e_2,\dots ,e_n)$ and represents the ideal class $\left[\mathfrak{a}\right]=[{\mathfrak{l}}_1^{e_1}{\mathfrak{l}}_2^{e_2}\cdots {\mathfrak{l}}_n^{e_n}]\in \mathcal{C}l\left(\mathbb{Z}\left[\sqrt{-p}\right]\right)$, where ${\mathfrak{l}}_i=\langle {\ell }_i,\pi -1\rangle$. The public key is the coefficient $A\in {\mathbb{F}}_p$ of the Montgomery curve obtained from the action $\left[\mathfrak{a}\right]E_0$. For all of the ideals in the form ${\left[\mathfrak{l}\right]}^{-1}$, it is necessary to use a quadratic twist. According to [20], the following useful theorem holds for every $\left[\mathfrak{a}\right]\in \mathcal{C}l\left(\mathbb{Z}\left[\sqrt{-p}\right]\right)$ and $E\in S$:

$${\left[\mathfrak{a}\right]}^{-1}E={\left(\left[\mathfrak{a}\right]E^t\right)}^t$$

(1)

The key-exchange procedure unfolds as follows: Alice generates and publishes her public key from her pair $(\left[\mathfrak{a}\right],\left[\mathfrak{a}\right]E_0)$ and similarly, Bob publishes the public part from $(\left[\mathfrak{b}\right],\left[\mathfrak{b}\right]E_0)$. Then, Alice creates the corresponding curve and checks whether this curve is supersingular: $\#\left(\left[\mathfrak{b}\right]E_0\left({\mathbb{F}}_p\right)\right)\stackrel{?}{=}p+1$. Upon successful verification, she calculates her private key action on Bob’s public key, i.e., $\left[\mathfrak{a}\right]\left(\left[\mathfrak{b}\right]E_0\right)$. Bob does the analogous action. Finally, we obtain a shared secret $S\in {\mathbb{F}}_p$, which represents $E_S=\left[\mathfrak{a}\right]\left(\left[\mathfrak{b}\right]E_0\right)=\left[\mathfrak{b}\right]\left(\left[\mathfrak{a}\right]E_0\right)$.

In order to efficiently calculate the actions of ideals $\left[\mathfrak{a}\right]=[{\mathfrak{l}}_1^{e_1}{\mathfrak{l}}_2^{e_2}\cdots {\mathfrak{l}}_n^{e_n}]$, we can perform operations iteratively. Every ideal in the form ${\mathfrak{l}}_i=\langle {\ell }_i,\pi \pm 1\rangle$ can be interpreted as an isogeny with the degree of ${\ell }_i$. Importantly, the sequence in which these operations are performed is not significant. It also does not have any influence on the security for the algorithm, because all of the elements from $\mathcal{C}l\left(\mathbb{Z}\left[\sqrt{-p}\right]\right)$, can be expressed as the multiplication of the exponents of ideals of small ${\ell }_i$ [21]. Finally, to compute the isogeny corresponding to a given kernel subgroup efficiently, the original CSIDH authors adopted Vélu’s formulas [22]. In our implementations, we applied the optimized version of these formulas for Montgomery curves, based on [23].

3.1.2. CSIDH: Security Analysis

The cryptographic security of the CSIDH protocol fundamentally relies on the difficulty of the following mathematical problem: For each given curve $E_A$ and $E_B$ defined over the field ${\mathbb{F}}_p$ with the ${\mathbb{F}}_p$-endomorphism ring $\mathcal{O}$, find an ideal $\mathfrak{a}\in \mathcal{O}$ such that the action of the class $\left[\mathfrak{a}\right]$ on the curve $E_A:\left[\mathfrak{a}\right]E_A=E_B$ yields $E_B$. This ideal must be represented in a form permitting efficient computation of its group action on elliptic curves. The most effective known classical attack against CSIDH is the probabilistic man-in-the-middle attack proposed by Galbraith, characterized by a complexity of $O\left(\sqrt[4]{p}\right)$. The naive brute-force approach was estimated by the authors of [13], exhibiting complexity approximately equal to $2^{{log}_2\sqrt{p}-ϵ}$, where $ϵ$ denotes some small natural number in comparison to ${log}_{2}p$. The number of all valid public keys is about $\left|S\right|\approx \sqrt{p}$. The quantum attack is based on algorithm [24] combined with the claw finding problem [11]. Such a quantum-based method yields a complexity of approximately $O\left(\sqrt[6]{p}\right)$ queries to the quantum oracle, which calculates the result of the group actions over the used set.

CSIDH can also be attacked with the algorithm proposed by Kuperberg [25]. Specifically tailored to solve the hidden-shift problem in abelian groups, this algorithm demonstrates a subexponential complexity, explicitly given by $2^{O\left(\sqrt{{log}_{2}N}\right)}$, where N denotes the order of the underlying abelian group. Nevertheless, in practice, none of these classical or quantum attacks currently possesses sufficient efficiency to compromise the CSIDH protocol for cryptographically relevant parameter sizes.

3.1.3. SeaSign Protocol for Digital Signatures

SeaSign [26] is a digital signature protocol developed in 2018 by Luca De Feo and Steven D. Galbraith, building upon earlier work by Anton Stolbunov [27], which the authors adapted to leverage the mathematical foundations of the CSIDH cryptosystem. This digital signature scheme employs a variation of the Fiat–Shamir transform proposed by Vadim Lyubashevsky [28], known as the Fiat–Shamir with aborts. Signatures generated by SeaSign have a size of 978 bytes when using parameters given by the authors of CSIDH as the NIST I security level, specifically defined as $p=4\times {\ell }_1\times {\ell }_2\times {\ell }_3\times \dots {\ell }_{73}\times 587-1$, where ${\ell }_1,\dots ,{\ell }_{73}$ represents consecutive prime numbers and the private key is chosen from the interval between $-5$ and 5. Public keys corresponding to these parameters have a size of approximately 4 megabytes, while the time required for signing and verifying messages is several minutes. It is worth mentioning here that the authors of the original work use j-invariants of elliptic curves as public keys—values that uniquely identify an elliptic curve. However, for our chosen parameters as $p\equiv 3(mod8)$, these invariants can equivalently be replaced by the Montgomery curve coefficient A.

The Fiat–Shamir transform is a method that converts an interactive identification scheme into a non-interactive digital signature protocol. The interactivity of the identification scheme relies upon one party (the prover), aiming to demonstrate their identity and providing responses—either once or multiple times—to a challenge sent by the other party (the verifier). The non-interactive property of a digital signature is achieved by replacing this challenge, which might take the form of a single binary bit, with a cryptographic hash computed from the message being signed, concatenated with specific data related to the prover’s identity. In the Fiat–Shamir transform, data associated with the prover’s identity is referred to as a commitment, which may, for instance, be a fragment of the private key combined with some random value. The non-interactive digital signature scheme proceeds as follows:

• Key generation:
  • Start parameters are analogous to the ones used in the CSIDH protocol.
  • The private key is a vector of length n with integer coefficients from a fixed interval $[-M,M]$, represented as $\mathit{sk}=\left(e_1,e_2,\dots ,e_n\right)$.
  • The public key consists of the coefficient A of the Montgomery form elliptic curve calculated as follows: $E_A=\left[\mathfrak{a}\right]E_0$, where $\left[\mathfrak{a}\right]={\prod }_{i=1}^n{\ell }_i^{e_i}$.
• Signing a message:
  • Inputs include the initial curve $E_0$, public key $E_A$, private key $\mathit{sk}$, and the message $\mathit{msg}$. Additionally, a parameter t must be set, which among other things determines the signature length and the number of rounds of the algorithm.
  • Randomly generate t vectors ${\mathbf{f}}_k$ = $\left(f_{k,1},f_{k,2},\dots ,f_{k,n}\right)$, whose coefficients $f_{k,i}$ are integers from the interval $[-nMt,nMt]$ and for each such vector calculate $E_k={\prod }_{i=1}^n{\ell }_i^{f_{k,i}}{E}_0$.
  • Subsequently, using a cryptographic hash function H, whose output consists of exactly t bits, compute a hash of the coefficients A of curves $E_1,\dots ,E_t$ calculated in the previous step, concatenated with the message $\mathit{msg}$, obtaining: $b_1\left|\right|\dots \left|\right|b_t’=H\left(A_1,\dots ,A_t,\mathit{msg}\right)$.
  • In the next step, for each $b_k$ we record into the signature the vector ${\mathbf{z}}_k={\mathbf{f}}_k$ if $b_k=0$ or ${\mathbf{z}}_k={\mathbf{f}}_k-\mathit{sk}$, (interpreted as vector difference) if $b_k=1$.
  • In the case where $b_k=1$, after computing the vector difference, it must be checked whether the obtained coefficients lie within the interval $[-nMt,nMt]$; if not, the signing algorithm must be restarted from the beginning.
  • If all resulting vectors from the vector differences have coefficients within the specified range, the signature is successful and the algorithm outputs the signature: $\sigma =\left({\mathbf{z}}_1,\dots ,{\mathbf{z}}_t,b_1,\dots ,b_t\right)$ (We are aware that the $\sigma$ notation had previously been introduced in the definition of Vélu’s formulas in Equation (A3). However, for the sake of brevity and consistency throughout this text, we have employed this symbol in both instances, following the conventions adopted by both original authors.).
• Verification of signature:
  • Inputs are the message $\mathit{msg}$, starting curve $E_0$, public key $E_A$ and the signature $\sigma$.
  • For each bit $b_k$ if it is zero, compute $E_k={\prod }_{i=1}^n{\ell }_i^{z_{k,i}}{E}_0$; if it equals one, compute $E_k={\prod }_{i=1}^n{\ell }_i^{z_{k,i}}{E}_A$.
  • Using the previously described cryptographic hash function H, calculate: $b_1^{\prime }\left|\right|\dots \left|\right|b_t^{\prime }=H\left(A_1,\dots ,A_t,\mathit{msg}\right)$, where $A_1,\dots ,A_t$ stand for the coefficients A representing the previously calculated curves.
  • Finally, compare the received hash $b_1\left|\right|\dots \left|\right|b_t$ with the computed hash $b_1^{\prime }\left|\right|\dots \left|\right|b_t^{\prime }$; if the values match, the function returns success, indicating the signature is valid; otherwise, it returns false, indicating the signature verification failed.

There exists a probability that the signing process may fail: The algorithm will not produce a correct signature if the coefficients of the vector ${\mathbf{z}}_k={\mathbf{f}}_k-\mathit{sk}$ are not in the interval $[-nMt,nMt]$. According to the authors of [26], the probability of the algorithm successfully generating a correct signature is at least $e^{-1}$. Otherwise, the algorithm must be repeated until it yields a valid signature. The necessity of verifying whether vector values fall within the specified range arises from the fact that using vectors ${\mathbf{z}}_k$, whose coefficients exceed this interval, would lead to leakage of private-key information. The idea of rejecting these incorrect vectors originates from Vadim Lyubashevsky’s aforementioned variant of the Fiat–Shamir transform [28].

Selection of SeaSign as our message-signing algorithm was a quite natural choice. It is one of the two most prominent signature schemes based on elliptic-curve isogenies encountered in the literature. The other scheme, SQISign, relies directly on quaternions—an advanced mathematical construct that also ultimately led to the cryptanalytic break of the SIKE algorithm. Consequently, SQISign is substantially more complex to implement. By contrast, the CSIDH/SeaSign approach offers a unified cryptographic framework, obviating the need to incorporate any additional quaternionic mathematics. Since SeaSign is built directly upon the CSIDH algorithm, we implemented it natively within our application and seamlessly integrated it with X3DH in such a way that the sender can be authenticated upon reception of the very first message. Nevertheless, we acknowledge that SeaSign exhibits a non-negligible failure rate: the success probability of a signature generation can be less than $27\%$ in some cases, and it is of probabilistic character.

3.2. End-to-End Encryption with Signal

Due to the end-to-end encryption (E2EE) approach used, we eliminate the possibility of message inspection by the server, ensuring that only the sender and the recipient can extract plaintext from the encrypted message. The primary advantage of this solution is precisely the aforementioned privacy. Clients store their private keys exclusively on end-user devices. The schema of such a solution is presented as follows:

• The sender encrypts the message using the recipient’s public key and sends the encrypted content.
• The server only forwards the message to the recipient and is itself unable to decrypt it.
• The recipient decrypts the message using their private key and reads its content.

There is no single standardized approach to E2EE. Therefore, we analyzed the most popular text messaging applications that claim to provide end-to-end encryption. Given our intention to implement our own messenger application, we ultimately selected what we consider the most suitable solution to fulfill the aforementioned requirements for end-to-end encryption. We aimed to use the CSIDH and SeaSign algorithms for practical purposes, clearly demonstrating the everyday applicability of these algorithms.

Currently, the Signal Protocol appears to be the most proper schema of this type. Signal is an application available for iOS, Android, Windows, Linux, and macOS. After discontinuing direct SMS support in 2023, Signal became a messaging application, entirely fulfilling end-to-end encryption assumptions. It encrypts all conversations by default, including group chats, voice calls, and video calls. The application is developed by Signal Foundation, a non-profit organization responsible for creating the aforementioned Signal Protocol cryptographic scheme. It is employed not only in Signal’s proprietary application but also in various other text messaging applications. Below,

Table 1. Comparison of messaging applications utilizing E2EE.

Messaging Application	Is the Source Code Open-Source?	End-to-End Encryption Algorithm
Signal	Yes	Signal Protocol
Facebook Messenger	No	Signal Protocol
Facebook WhatsApp	No	Signal Protocol
Google Messages	No	Signal Protocol
Microsoft Skype	No	Signal Protocol
Wire	Yes	Signal Protocol
Simplex	Yes	Signal Protocol
Threema	Partially (application code open)	NaCl (cryptographic library)
Session	Yes	Session Protocol
Telegram	Partially (application code open)	MTProto 2.0

presents data regarding selected messaging applications utilizing E2EE.

The Signal Protocol is among the most thoroughly analyzed protocols regarding security in text-based messaging applications. Based on studies presented in [29,30] (directly analyzing the Double-Ratchet algorithm, to be explained further), we conclude that the Signal Protocol is secure and comprehensive. Considering the examined literature and the widespread adoption of the Signal Protocol, we opted for this particular algorithm. We selected two algorithms to integrate into our implementation—the Double-Ratchet algorithm and X3DH—to further enhance the application’s security.

4. Implementation of the Selected Algorithms with Signal Protocol

In order to provide additional security features, we enhanced our implementation (The whole implementation code, along with our implementation of the cryptographic primitives and the illustrating application, is available at https://github.com/BenJan87/MDPI_isogeny_messenger_app (accessed on 17 July 2025)) with two algorithms. We used schemes:

• X3DH: the algorithm permits us to initialize the conversation in such a way that we can correctly identify the interlocutor.
• Double-Ratchet algorithm: it provides perfect backward secrecy and perfect forward secrecy.

It is worth noting that the following concepts were developed by the Signal Foundation; however, their introduction is essential to understanding the principles of an end-to-end encrypted application.

4.1. Extended Triple Diffie–Hellman Algorithm (X3DH)

Before initiating message exchanges with the other party, it is first necessary to establish the communication session. Additionally, we anticipate being able to identify the intended recipient of our messages. In the case of the Signal application, this is achieved using the Extended Triple Diffie–Hellman X3DH [31], which, when combined with the SeaSign algorithm, satisfies the previously described requirements. Alice will be considered the party initiating the message exchange, while Bob will act as the party awaiting initiation. Within this algorithm, several key types are defined (for simplicity, we refer here to keys, though in reality, each is a pair consisting of a public and private key):

• IK (identity key): A key identifying a particular party.
• EK (ephermal key): A key generated exclusively for initiating the conversation, created only once by Alice.
• SPK (signed prekey): A key used for creating signatures.
• OPK (one-time prekey): Each party generates multiple single-use keys. During initiation, the server provides Alice with one of Bob’s one-time prekeys.

Firstly, Alice must verify Bob’s identity. For this purpose, she obtains Bob’s signature and independently determines the correctness of the verification result. In these steps, we use the SeaSign algorithm. Following this step, Alice can proceed with the algorithm for generating the shared key. As Bob—the party receiving the message—we require Alice to provide the public SPK keys. Thus, Alice sends an initial message to start the conversation, including these keys. Due to these actions, Bob, upon collecting this information, is able to decrypt the initial message received. A summary of the Diffie–Hellman exchanges can be illustrated by Figure 1.

During the exchange, we also generate a parameter known as AD, created as a combination of the public IK keys. By comparing the AD character sequence with that of the other user, we can be certain that the conversation is between us and the intended party. In other words, no unauthorized party has impersonated our correspondent. In the absence of the previously mentioned Double-Ratchet algorithm, the shared key would directly serve as the encryption key for all transmitted messages.

4.2. Double-Ratchet Algorithm

There are two distinct approaches to implementing end-to-end encryption, which should be highlighted when discussing the Double-Ratchet algorithm:

• Each message would be encrypted with an individually negotiated key established through any form of the Diffie–Hellman algorithm. However, such an approach would not be practical, for example, when sending multiple messages consecutively. After each message, the user interaction would be required so the parties could generate a new key. This approach proves impractical and necessitates active user participation throughout the communication process.
• Encrypting all messages using a single shared key generated via the DH algorithm does not appear fully secure. In the case where the key was compromised, an attacker would be able to decrypt the entire conversation.

The Double-Ratchet algorithm can ensure key security without requiring active participation from the users. While each message must indeed be encrypted with a unique key, this algorithm successfully addresses previously mentioned concerns regarding practicality and security. The core concept of the algorithm is the so-called key derivation function (KDF) chains. KDF refers to a function that, given certain input data, enables the generation of symmetric encryption keys. As illustrated in Figure 2, a chain is created wherein each subsequent key relies upon certain input data and an output derived from the previous iteration of the KDF. This design fulfills the requirement of perfect forward secrecy. Within the Double-Ratchet algorithm, there are three distinct chains:

• root chain: the principal chain responsible for generating subsequent keys used by the respective sending chain and receiving chain;
• sending chain: the chain dedicated to message transmission, corresponding to the receiving chain on the recipient’s side;
• receiving chain: the chain designated for message reception, corresponding to the sending chain on the sender’s side.

The first of the ratchets is the Symmetric-key ratchet, which is almost identical to the structure of a KDF chain. Its role is to determine subsequent keys for each individual chain. The second of these ratchets is the Diffie–Hellman ratchet. In the event that an attacker acquires both sending and receiving keys, they would be capable of generating all subsequent keys. Therefore, a solution was introduced involving the incorporation of a KDF function into the input data, significantly complicating further key generation. Each message header includes a Diffie–Hellman public key component, enabling continuous generation of subsequent keys without requiring active participation from either party. When combined with the previously described ratchet mechanism, these two components form the scheme presented in Figure 3, where the following elements can be distinguished:

• The three main ratchets: Root chain, Sending chain, and Receiving chain.
• Symmetric-key ratchet: Beneath this chain are several messages (two in this particular case) received by one party. After decrypting these messages, the chain resets to its initial state, subsequently initiating the creation of a new short chain within the Sending chain.
• DH ratchet: A chain responsible for producing input data utilized by the KDF function.

4.3. Combining Both Algorithms: X3DH and Double-Ratchet

The X3DH algorithm is employed to establish a single shared secret. The Double-Ratchet algorithm is designed to provide security against the compromise of encryption keys, ensuring that previously transmitted messages as well as future communications cannot be decrypted. Both algorithms complement each other, for the Double-Ratchet algorithm requires an initial shared secret at the outset of message exchange. According to Signal’s documentation [32], the outcome of the X3DH algorithm serves as the primary key from which the Root chain originates, subsequently becoming known as the Root key.

5. Application Design

By design, the application requires end-to-end encryption: only the communication endpoints possess the cryptographic material necessary to decrypt transmitted messages. To realize this guarantee, our messenger is implemented as a desktop application—all cryptographic operations are performed locally on the client—and messages are delivered to the server exclusively in encrypted form. Moreover, each user’s private key is stored solely within the client’s local file system and never leaves the device.

5.1. Application’s Architecture

The application’s operational data reside in a non-relational MongoDB database, organized into three collections. The users collection stores authentication credentials—specifically, the login, password, and username—along with the user’s public keys. The chats collection records information about established conversations: each document comprises the pair of participants, the identifier of the user who created (i.e., hosted) the chat, and the public keys negotiated for the Double-Ratchet algorithm in that context. Finally, the messages collection holds encrypted messages that have been sent, but not yet retrieved by their intended recipients. Once a message is successfully received, it is purged from the database. The choice of a non-relational database was driven by the lack of requirement for rigidly structured data, the ease of managing a document-oriented store, and the overall reduced complexity relative to a traditional relational database system.

To establish trust between users, our application adopts a Trust On First Use (TOFU) model. When a user initiates a conversation with a new contact, the contact’s public key is accepted and stored locally upon first encounter; all subsequent communications are verified against this key, and any changes will trigger a security warning to the user.

The structure of the application is built around a central server, implemented with the Flask 3.1.1 framework. This server exposes endpoints for all core client operations, namely, user registration, authentication (login and logout), creation of new chats between users, enumeration of existing conversations, and the sending and retrieval of messages (including those with attachments). Uploaded attachments are additionally retained in the server’s volatile memory until they are delivered.

The paramount component of our messenger is the desktop application, developed using the PyWebview 5.4 library. This framework enables the construction of desktop applications in the same manner as web applications—namely, with HTML and JavaScript—and affords access to browser-provided storage mechanisms (e.g., localStorage), which we have likewise leveraged. Furthermore, PyWebview supplies a bridged API that permits invocation of Python functions directly from JavaScript executing within the application. This capability is essential for our implementation, since our cryptographic modules are authored in Python. Furthermore, by employing PyWebview, all cryptographic operations execute exclusively on the client machines, thereby preserving end-to-end encryption.

In order to persist received messages and the cryptographic state required by the Double-Ratchet protocol, we leverage the browser’s built-in storage mechanisms: messages themselves are stored in IndexedDB (https://developer.mozilla.org/en-US/docs/Web/API/IndexedDB_API, accessed on 1 May 2025), while the protocol state is maintained in localStorage. To ensure an additional layer of confidentiality, messages stored in IndexedDB are encrypted using the AES-256 algorithm, with each user’s encryption key derived from their password. The resulting architecture of interconnected components is illustrated in Figure 4.

The application’s graphical interface is deliberately minimalist. One representative view is shown in Figure 5. The layout and styling are implemented using the Bootstrap 5.3 framework. Dynamic rendering of the views is achieved via the Jinja templating engine, which is widely adopted in applications whose server-side logic is developed with Flask.

5.2. Passive Attacks

It should be emphasized that this architecture precludes any possibility of passive attacks or eavesdropping. As noted above, each message is encrypted under a distinct key derived from multiple factors—rather than a single secret—which are described in detail in Section 4.2. Given the extensively analyzed instance of the Double-Ratchet protocol, we see no viable way for key compromise except through an attack on the endpoint device itself—an out-of-scope risk inherent to any client-side solution. Furthermore, even the compromise of an individual message key does not permit decryption of past or future messages, thus ensuring both perfect backward secrecy and perfect forward secrecy. The conversation-initiation procedure has similarly been designed to eliminate any initial key exposure. As previously mentioned, messages are stored securely—see the Section 5. Crucially, because our application enforces true end-to-end encryption, the server is incapable of accessing the message plaintext and functions solely as a blind relay.

5.3. Active Attacks

Active attacks pose a more significant threat to our desktop application. On top of that, because we have implemented only a proof of concept, we prioritized responsiveness and fidelity to the underlying cryptographic algorithms. We incorporate essential software-security measures—such as input sanitization (e.g., during authentication)—and exclusively employ state-of-the-art, up-to-date libraries. To uncover any latent vulnerabilities, comprehensive penetration testing should be performed to clearly identify weaknesses in the source code. At the network layer, we rely on rigorously audited frameworks such as Flask 3.1.1 and observe no fundamental design flaws. For potential denial-of-service (DoS) attacks, we would emphasize network-level protections (i.e., deployment of firewalls or IDS/IPS) rather than modifications to the application itself. In a production deployment of our server, external network security controls would be positioned as close as possible to the server’s egress point. Finally, end users are expected to maintain their own network-security perimeter to safeguard against client-side threats.

6. Results

6.1. Implementation

The CSIDH function is responsible for traversing a particular isogeny graph to ultimately derive a shared secret. This creates the main component of our entire implementation, ensuring the establishment of a common key. The fragment of the CSIDH algorithm implementation responsible for parsing the secret key is based on [33]—specifically, we reconstructed the logic presented in the reference from the SageMath language, subsequently translating and implementing it in pure Python programming language. The advantage gained by employing such a solution lies in the transparency of the utilized mathematical functions and the absence of any requirement to install additional software supporting advanced mathematical operations. Moreover, code written in this manner is significantly easier to optimize and, in general, exhibits greater versatility. On the other hand, the remainder of the implementation has been entirely designed and developed for the sake of this contribution. The originally implemented components are as follows:

• Mathematical operations related to points on elliptic curves—point addition, point subtraction, scalar multiplication, and computation of inverses in a field;
• Operations on elliptic curves—conversion between the Weierstrass and Montgomery forms of elliptic curves, generation of subgroups for subsequent isogeny computations, computation of quadratic twists, and calculation of isogenies using Vélu’s formulas for Montgomery curves;
• Implementation of the CSIDH algorithm—encapsulation of logic utilizing the aforementioned functions,
• Implementation of the SeaSign algorithm—development of the complete logic for the algorithm, including signature generation and verification;
• Web application—development of a web application incorporating well-known cryptographic schemes inspired by the Signal application to illustrate the operation of the above in practice.

6.2. CSIDH Function

The implemented CSIDH function, whose purpose is to establish a shared key, accepts as arguments a given curve, a private key represented as a list of integers, a prime number p, and the “prime factors of the number p” (small primes mentioned in Section 3.1.1). The time complexity of this algorithm is given as $O(l\times p^3\times {log}^{2}p)$, where l is the number of primes that compose the special p prime number. It is worth mentioning that l is relatively small when compared to the prime p and it can be neglected. The space complexity is the same as the time complexity in this case. Initially, a straightforward check is performed to verify whether the given curve is supersingular (as discussed in Appendix A.1). Negative values within the key vector are replaced with their absolute values, as these will subsequently need a twist operation on the curve. The algorithm continues execution as long as ideal class group actions remain to be performed. If any actions remain, we proceed to map prime numbers to their corresponding integers within the private key vector. This step allows us to determine how many times each $e_i$ action within the ideal class group should be executed. A random element from the initial curve is then selected. Subsequently, the step of randomly selecting a point on the curve is repeated until we identify a point belonging to the specified curve, as not every selected abscissa yields a corresponding ordinate on the given curve. We then create a list S containing indices of actions yet to be executed. If no suitable result is found, the next element $cl$ is selected, and the aforementioned step is repeated. For all remaining elements within the list S, we compute the product of primes corresponding to the designated indices. We multiply the selected point P by the integer $(p+1)//k$ (Here, the symbol $//$ denotes integer division, i.e., extracting the characteristic part of the number.). The subsequent step involves selecting prime numbers that indicate the degrees of the isogenies to be computed. These are precisely the numbers contained within the set S—see Equation (A8). Thus, we calculate the point R with the order l, which will serve as the kernel generator for the isogeny. Employing Vélu’s formulas enables us to determine the image of a point Q obtained from the isogeny characterized by the specified kernel. Additionally, we evaluated the newly derived curve. Since we have computed the kernel l isogeny, we update the integer k to $k//l$. Consequently, we also decrease the number of remaining actions to be performed. It can be performed by decrementing $cl\left[i\right]$ by 1. Upon completion of the algorithm, during which all ideal class group actions are performed, the operation that remains is substituting the curve with its quadratic twist. Due to the previously noted fact that ${\left[\mathfrak{a}\right]}^{-1}E={\left(\left[\mathfrak{a}\right]E^t\right)}^t$, we effectively employ a quadratic twist. This operation allows us to proceed even when negative values appear within the private key vector. At the conclusion of this entire sequence, we obtain a curve that can either be transmitted to the other party or directly utilized as the shared secret, depending on the stage of the CSIDH algorithm.

The functions implementing the SeaSign algorithm represent a precise translation into Python of the steps described in Section 3.1.3. Given the existing implementation of the CSIDH protocol—specifically, the algorithm computing the outcome of isogeny operations corresponding to particular ideal classes on elliptic curves—the implementation of SeaSign is significantly straightforward.

Given that the cryptographic modules X3DH and Double-Ratchet have already been deeply described in Section 4, our further analysis will focus solely on providing a general overview of these modules. Furthermore, we will illustrate the protocol exclusively from Alice’s perspective, since Bob needs to perform almost identical operations, only substituting the corresponding public keys with private ones and vice versa. It is crucial to recall that prior to initiating the X3DH protocol, Alice’s first step is the process of verifying Bob’s signature transmitted to the server. To accomplish this verification, we employ the SeaSign algorithm implemented by us. As previously explained in Section 4.2, the algorithm functions through two interlocking ‘ratchets,’ designed to ensure both perfect forward secrecy and perfect backward secrecy. While Figure 2 and Figure 3 visually depict this conceptual approach, the practical realization may initially obscure the underlying concept. Given that we have utilized a partial implementation of this algorithm, derived from the Signal authors’ documentation [32], we refrain from reproducing the complete source code herein, as it is already publicly accessible at the referenced site. Moreover, the principle of a ‘drop-in replacement’ has been effectively validated by our implementation of the CSIDH algorithm, seamlessly integrating it as a substitute for the traditional Diffie–Hellman scheme.

As a proof of concept, and to show the operation of the whole end-to-end encryption, we have prepared an exemplary application, namely a Python-based Internet communicator. The resulting application should be perceived primarily as an environment designed for showing the potential and evaluating the performance of isogeny-based cryptosystems, rather than as a component of equal significance to the cryptographic modules within this work. Consequently, greater emphasis has been placed on the implementation and rigorous testing of the aforementioned cryptographic modules rather than on the application itself.

6.3. Performance Evaluation

To compare the performance of our cryptographic algorithms, we aimed to examine the relationship between security and computational efficiency. It is worth noting that the objective of our work was not to develop the most efficient solution in terms of algorithmic speed, but rather to present an implementation based on the proof-of-concept principle. The input parameters for the CSIDH algorithm are provided below. The variables refer to all CSIDH variants (64, 128, 256, 512, 1024, 1792).

The public key length, understood as the approximate bit-length of the prime number p, doubles with each next variant. Another fundamental parameter is PARAMETERS[“ELL”]. The length of this list determines the size of the private key. It specifies the set of prime numbers from which we subsequently construct the main prime parameter p in the field ${\mathbb{F}}_q$, over which our elliptic curves are defined. The parameter PARAMETERS[“FP”] explicitly represents the fixed prime number p. The parameter PARAMETERS[“BOUND”] is always set to 1—it defines the absolute value limit for randomly selected numbers. Consequently, the private key consists of values: $-1$, 0, or 1. Each algorithm is associated with an approximate bit-length derived from the transformed value of p.

To standardize the security levels, we referred to the NIST classification. The NIST levels are defined as follows (the levels can be investigated on the NIST’s website [34]):

• NIST I—equivalent to the effort required to recover an AES-128 key or lower;
• NIST III—equivalent to the effort required to recover an AES-192 key or lower;
• NIST V—equivalent to the effort required to recover an AES-256 key or lower.

6.3.1. Results on CSIDH Implementation

The crucial metric that we considered was the time required to establish a shared secret key. For this purpose, we investigated a scenario in which only one party’s computation time is taken into account. Ultimately, we measured the sum of the following two time intervals:

• The duration for one party to apply their private key operation to the initial curve;
• The time taken to apply the private key operation to the curve received from the other party (the second party performs their step beforehand and subsequently transfers this resulting curve to the first party).

We decided to implement the CSIDH-64 algorithm in our application, as we were looking for a reasonable compromise between the practical applicability of the algorithm and its security. It should be made explicitly clear that this provision is not at the level of NIST I security, and therefore does not afford sufficient protection for production deployment. Since our project’s foremost objective is the practical realization of the algorithm, we have chosen to employ the 64-bit variant, which we have examined in detail and will describe further on in this article. We also report measurement times for CSIDH-512, which, from a practical standpoint, are prohibitively long for integration into a messaging application without sacrificing overall responsiveness. The approximately ≈17 s per cycle reported in

Table 2. Measurements for the CSIDH algorithm.

Security		Statistical Metrics
Security Level	Prime Parameter p Bit-Length	Number of Measurements	Mean [s]	RMSE [s]	Standard Error of the Mean [s]	Relative Error [%]
—	64	10,000	0.024328	0.003677	0.000037	0.08
—	128	10,000	0.288998	0.013797	0.001380	0.48
—	256	10,000	8.831445	0.103961	0.032875	0.37
NIST I	512	10	16.785786	0.399411	0.126305	0.75
NIST III	1024	10	212.711439	12.288354	3.885919	1.83
NIST V	1792	5	2131.08023	34.506166	17.253083	0.81

is manifestly excessive for direct use of this variant, even though such an implementation remains technically feasible. In such a scenario, the messenger would be rendered impractical. Other variants of the algorithm have likewise been investigated and are detailed further below, along with the reasons why none of them were selected as the default for our application.

Figure 6 presents the timing measurements for CSIDH-64. We can see that certain time measurements notably deviate from the trend. These points occurred due to a randomness factor within the CSIDH algorithm, specifically when randomly selecting a point. Occasionally, the kernel may correspond to a point at infinity, causing computational slowdowns. Furthermore, since these durations are relatively small, measurement inaccuracies may occur, particularly during performance testing conducted in Python.

Summary of statistical data corresponding to the results shown in Figure 6 can be found in Table 2. The measurements indicate that establishing a shared secret key using our implementation on one side takes $(0.024328\pm 0.000037)$ ms. This duration is acceptable from the application’s practicality viewpoint. However, it should be emphasized that CSIDH-64 does not reach the NIST I security standard (which is met by CSIDH-512). Under a potential brute-force attack targeting the private key in the CSIDH-64 scenario, an adversary would need to test approximately $3^{15}$ (roughly $2^{24}$) possibilities.

Below, we also present further measurement results obtained with parameters other than CSIDH-64 for our implementation. The results presented subsequently serve primarily to indicate the degree to which we have approached a security level at which the implementation could be considered suitably secure while maintaining satisfactory performance. Certain measurement sets have been limited in size due to the computational demand involved in the overall performance evaluation. Table 2 summarizes the timing outcomes for algorithms with the previously described parameterizations. We noted while analyzing that the presented dataindicates that the computational time for CSIDH-128 could also be considered acceptable. Nevertheless, we ultimately chose the faster CSIDH-64 variant. However, the same conclusion cannot be said for CSIDH-256. Waiting approximately 9 s to encrypt a single message is impractical, particularly in the context of algorithms used to initialize conversations between communicating parties, such as X3DH. In the X3DH protocol, four separate Diffie–Hellman exchanges must be performed. Consequently, the elapsed time from initiating a conversation until the first message is sent would be at least 36 s. Both CSIDH-128 and CSIDH-256 were included to illustrate how closely we can approach practical performance with respect to algorithms considered ‘secure’ according to the NIST standards.

CSIDH-512 provides the first security level, classified as NIST I. With the parameters proposed by the original CSIDH authors in their paper [35], this variant can be considered secure. CSIDH-1024 corresponds to the second NIST security level. As Table 2 illustrates, this variant becomes impractical for internet-messaging applications when compared to CSIDH-512, owing to its relatively long execution times. Lastly, CSIDH-1792 represents the highest NIST security level considered in this study. The computation time at this level is not satisfactory. This particular variant, along with its associated parameters, was included primarily as a theoretical curiosity, highlighting performance aspects with a 1792-bit prime number p.

Additionally, the differences between individual NIST security levels are significant. For example, the computational time required to execute the CSIDH algorithm at NIST III is approximately $12.5$ times longer compared to NIST I, while at NIST V it is approximately 127 times longer relative to the same baseline. The primary reason for such dramatic increases in execution time is the growth of the prime number p: the length of the corresponding private key increases as well. The length of the private key directly determines the number of computational operations to be executed on a given elliptic curve, provided as input to the CSIDH algorithm. Consequently, the higher the number and degree of the isogenies computed, the slower the algorithm becomes. To illustrate this clearly, the private key length for CSIDH-64 equals merely 15, whereas for CSIDH-1792, it reaches as much as 207. It should be noted that we did not investigate the speed of pure code in our implementation (e.g., no direct comparisons were made between the execution speed of loops). Instead, we focused on identifying which mathematical algorithms theoretically offer the best performance when implemented. Specifically, we employed approaches that allowed for accelerated computations or the direct application of previously derived formulas. An illustrative example includes choosing suitable forms of prime numbers p. In that case, we eliminate the necessity to algorithmically solve cubic equations over finite fields modulo p.

6.3.2. Results on SeaSign Implementation

It is important to highlight the common range from which we randomly select the numbers for the private key vector in SeaSign. Naturally, as the parameter t increases, the signature procedure becomes longer. In our case, we set t = 4, meaning that numbers are randomly selected from (-1)*len(PARAMETERS[“ELL”])*4 to 1*PARAMETERS[“ELL”]*4. Due to significantly longer execution times compared to CSIDH, we opted for a considerably shorter private key length in our application. Particular attention should be drawn to the parameter PARAMETERS[“BOUNDS”] = 1, as the range of the private key values is broader than in CSIDH. This aspect significantly affects the overall performance, which is discussed in greater detail below.

In comparison to CSIDH, the SeaSign algorithm shows lower efficiency. Thus, implementation employs a smaller prime number, ensuring practical usability of the application. It is worth recalling that the SeaSign algorithm internally utilizes the CSIDH algorithm. Consequently, the chosen parameters significantly impact both signature generation and verification times. The prime number selected for our implementation has a length of approximately 22 bits.

The time complexity of the signing procedure is given as $O(t\times \mathit{CSIDH})$, where $\mathit{CSIDH}$ stands for the time complexity of the CSIDH function ($l\times p^3\times {log}^{2}p$). In this scenario, where $t=4$, we can neglect the t parameter and establish that the signing procedure has the same time complexity as the CSIDH function. The verifying procedure has the time complexity of $O(\mathit{HASH}\times CSIDH)$, where $\mathit{HASH}$ is the length of SHA-256 hash. It can be considered as a constant, so it finally gives CSIDH time complexity. In both cases (signing and verifying procedures), the time and space complexity are equal.

A prime number p with a length of 22 bits allows us to maintain the practical usability of the application. Unfortunately, this represents the only advantage of selecting such parameters. In this case, the private key length equals merely 6, which is not a satisfactory result from a security perspective. Nonetheless, within the framework of our proof of concept, employing these parameters ensures efficient overall algorithm performance. Below, by SeaSign-p, we mean p denoting the bit-length of the prime numbers employed in the SeaSign algorithm.

Subsequent parameters refer to SeaSign-64: the private key length here is 15, which constitutes an improvement over SeaSign-22, yet remains insufficient for it to be deemed secure. The next prime number considered has a length of 128 bits. Signature generation times at this parameter level extend to just under one minute. This particular solution was also not integrated into our application due to the excessively prolonged computational duration.

Signature execution times were measured, with results presented in

Table 3. Measurements for the SeaSign algorithm.

Security	Statistical Metrics
Prime Parameter p Bit-Length	Number of Measurements	Mean [s]	RMSE [s]	Standard Error of the Mean [s]	Relative Error [%]
22	10,000	0.039246	0.005275	0.001668	4.25
64	10,000	2.390060	0.203972	0.064502	2.71
128	10	55.578744	7.880409	2.492004	4.48
256	5	2244.487328	122.348519	54.715921	2.44

. As is the case with CSIDH (Table 2), certain values of p involved fewer measurements. However, what stands out here is the relatively high relative error, especially in comparison to the results obtained for CSIDH. This discrepancy stems from the fact that the signature procedure itself may fail. As previously noted, the authors of SeaSign demonstrated in their paper [26] that the probability of signature failure can be as high as $1-e^{-1}$, approximately $63.21$%. Given such a significant failure probability, we repeat the algorithm until successful signature generation is achieved. As this inherently relies on probabilistic outcomes, the relative error ranges from approximately $2.5$% to $4.5$%, noticeably higher than in various instances of CSIDH. In our implementation, SeaSign-22 requires approximately 40 ms to generate a signature, a figure that includes roughly two-thirds of unsuccessful signing attempts. While practically sufficient, this parameter set cannot be deemed secure.

The prolonged execution time results primarily from two factors. The first is the probabilistic nature described above, which significantly impacts the timing results. The second factor is the broader range of integers randomly selected for the signing party’s private key. In CSIDH, using the parameter PARAMETERS[“BOUND”] = 1, the private key values are drawn from the set [ −1 : 1 ]. In contrast, the range for SeaSign is defined as [ −nMt : nMt ], increasing the number of isogenies computed in each step and substantially extending the signature generation process. Consequently, even for the same prime number p, the signature generation time in SeaSign is noticeably longer than the corresponding CSIDH instance. For instance, in SeaSign-22, private key integers are drawn from the set [ −49 : 49 ].

SeaSign-64 could still be considered an acceptable choice among all CSIDH-based algorithms. However, due to the selection of CSIDH-64 for our application, we intended to match the signing algorithm’s timing performance closely. Both SeaSign-128 and SeaSign-256 appear impractical; notably, SeaSign-256 is approximately 40 times slower than SeaSign-128. Larger prime numbers in SeaSign-p variants were not evaluated due to excessively long measurement durations.

Finally, it should be emphasized that the performance of SeaSign should not be directly compared to algorithms ensuring only classical security, as no implementation reference for quantum security is currently available.

6.3.3. Key Size Comparison

Table 4. Comparison of selected PQ Signature and DH Schemes (NIST Level 1).

	Metrics
Algorithms	Signature Size	Public Key Size	Private Key Size
CSIDH	—	64 B	74 B (−1, 0, 1 × 74)
SeaSign	978 B	4 MiB	74 B (−1, 0, 1 × 74)
SIDH	—	378 B	32 B
Dilithium	666 B	897 B	1280 B

presents a comparative overview of key sizes for various algorithms at the NIST Level I security category. The table is compiled on the basis of analyses presented in [17,26,35,36]. The presented data facilitates a direct, size-based comparison across the algorithms. Execution times have been omitted from this table due to inconsistencies in measurement methodologies, which render a clear comparison of Python implementation runtimes infeasible.

The authors of the SeaSign report approximate the timings of 3 min for signature verification and the timings of 9 min for signature generation, obtained with a 3.5 GHz processor (unfortunately, the exact specification has not been given). However, these estimates are rough, and it should be noted that no Python implementation currently exists in the open-source parts of this algorithm. Timing data for CSIDH-512 were provided previously. For SIDH, earlier estimates (see [36]) indicate an execution time of approximately 10 ms on NIST I level.

7. Conclusions

The main objective of our work was to investigate how post-quantum isogeny-based algorithms could be applied in practice. CSIDH, as a key exchange algorithm, serves as a cryptosystem that enables the exchange of certain information between parties that possesses the appropriate encryption key. This exchange is encrypted, and no third party can access the transmitted information without obtaining the corresponding private keys. The SeaSign algorithm provides a digital signature, allowing us to identify the signing party. The combination of these two aforementioned algorithms may serve as a foundation for establishing a channel through which encrypted data can be transmitted. Such data would only be accessible to individuals who have been properly authenticated and possess the necessary cryptographic material. We identified text messengers that contain end-to-end encryption as fitting examples of the practical use of CSIDH and SeaSign algorithms.

We selected the parameters of these algorithms to ensure that both the encryption itself and the entire application remain secure and practical to a satisfactory degree. To this end, we also focused on optimizing the presented implementation, with particular emphasis on the mathematical aspects of the algorithms. The application was intended as a proof of concept, serving to validate our conceptual framework. The execution times listed in Table 2 demonstrate that the application performs efficiently and is suitable for practical use. If we were to disregard the issue of practicality and instead select parameters prioritizing security—such as CSIDH-512 and, for instance, SeaSign-256—the application as a whole could be considered fully secure.

Our implementation of the CSIDH algorithm is the second publicly available Python implementation, aside from the SIBC library, which is available via an online repository [37]. This library includes a variety of isogeny-based cryptosystems. It is worth noting, however, that neither CSIDH nor SeaSign has been used to develop an application in the form of a text messenger with end-to-end encryption. As of the time of writing, there is no publicly available Python implementation of the SeaSign algorithm in open source. Furthermore, the mathematical part of our implementation not only includes the aforementioned algorithms but can also be used for basic operations on elliptic curves. These operations include, for instance, point addition, scalar multiplication, conversion between different curve representations, and the computation of isogenies, given a specified kernel generator.

To summarize, a potential direction for further development of the application involves security enhancement on both the backend and frontend sides.Penetration testing, for example, could be employed to identify security vulnerabilities within the application itself. Since the primary aim of our work was the application of post-quantum algorithms, our focus was predominantly on maintaining cryptographic security.