Multithreaded End to End Encrypted Cryptography

Based Real Time Chat

Viney Chhillar Sparsh Verma Ayush Jindal

Computer Science and Technology Computer Science and Technology Computer Science and Technology
School of Engineering & Technology School of Engineering & Technology School of Engineering & Technology
Sharda University Sharda University Sharda University
Greater Noida ,India Greater Noida ,India Greater Noida ,India
ronaessi28chhillar@gmail.com sparshverma07@gmail.com ayushjindal1026@gmail.com

Abstract— when using the Internet, confidentiality shields
users' data from digital eavesdroppers. Particularly in systems
that entail communication and data exchange between several
users, confidentiality is complicated and expensive. The biggest
impediment in using cryptography to achieve secrecy is
effectively and safely distributing a secret key to a number of
people. The chat programme described in this work offers a
novel method for messaging that is end-to-end encrypted, real-
time, uses a dynamic key store, and does not require data
persistent. The programme differs from the competition due to
the novel approach in which the keys are distributed across
numerous users.
Keywords— Group chat; confidentiality; end-to-end;
Encryption, Encryption algorithm; key store.
I. INTRODUCTION
Computer networking has ingrained itself into daily life
in the modern world. A shared communication channel may
be used by a variety of networks to transfer information
across groups of devices. They differ mostly in terms of
physical media and protocol requirements. Due to its
dependability, effectiveness, and speed, Ethernet is a leading
wired networking standard and is a natural choice for many
network applications. There are several application sectors
where the Ethernet standard is employed. The Client/Server
model architecture, which has been employed in most
network systems and in this study specifically, is depicted in
Figure 1.
Figure 1: A Client/Server Architecture.
Regardless of the importance of information security in the
creation of software applications, the difficulties in achieving
it have been highlighted. Some examples include the
complexity required to crack passwords, the number of
known assaults, and the existence of vulnerabilities. The
terms authenticity and non-repudiation are added to the
Confidentiality-Integrity-Availability (CIA) trinity, which
stands for the information security principles. End-to-end
encryption is a type of encryption in which the only parties
that have the keys to decrypt the data are the sender and the
recipient.
By implementing such encryption, it should be
impossible for anybody, not even the application Server, if
one exists, to access the original data of the exchanged
messages during the transmission process (sniffing, Man-in-
the-Middle attack, etc.). Ensuring that the key is secure and
that only the sender and receiver have access to the
information is one of the main obstacles in putting end-to-
end encryption into practice since only they should be aware
of the key. When trading messages involving numerous
Clients, the difficulty of transferring keys must also be taken
into account.
One thing to keep in mind is that Clients exchange Room
keys, and the Server is never made aware of the key used by
all users of the same Room to encrypt and decode messages.
This work seeks to present a group chat application that
enables the secure and quick exchange of messages between
several users, ensuring the confidentiality of the clients'
information and synchronous and real-time communication
without the need for data storage. Since the same key will be
used for all clients in a Room but in a way that the Server is
ignorant of, the key is also effectively and securely shared,
guaranteeing the feature of being end-to-end encryption.
With the keys being shared between the peers without the
server's involvement, this sort of cryptographic keys
exchange may be effectively used in a broad range of
distributed applications where secrecy should be emphasized,
such as a group chat.
The following is how the paper is set up: The relevant
works and literature reviews are described in Section II. The
application architecture is explained in Section III. In Section

XXX-X-XXXX-XXXX-X/XX/$XX.00 ©20XX IEEE

IV, the results analysis is given. Future works are presented
in Section V. The paper is finally concluded in Section VI.
II. LITERATURE REVIEW
In order to preserve the security of data, encryption is
frequently employed in apps and communications. Use of a
technique that ensures information secrecy is advantageous
for many group chat applications. The most popular message
exchange programmes were selected in order to analyze their
features and encryption techniques in order to determine
which ones would be most suited for usage in the creation of
the application suggested in this research.
A. Signal
One of the most popular protocols is Signal
(https://signal.org), which is popular because to its open-
source code and encryption methods. Numerous smartphone
applications, including WhatsApp, Viber, and the Signal app,
which was developed by the same people who created the
protocol, are based on this protocol. Due to the security
measures it employs and the ease with which it can be
implemented, it ended up being one of the most extensively
used protocols. The Signal protocol distinguished itself by
the use of the following approaches:
 Use either SI (MKS) or CGS as primary units. (SI
units are encouraged.) English units may be used as
secondary units (in parentheses). An exception would
be the use of English units as identifiers in trade, such
as “3.5-inch disk drive”
 KDF (Key Derivation Functions) - It is a hash
function for cryptography that generates a new key
from an existing key with each message exchange,
giving each message a distinct key. In the event that
one of the keys is compromised, this feature ensures
absolute forward secrecy
 Double ratchet - entails adding a Diffie-Hellman
iterative control mechanism to the key exchange that
introduces a fresh salt and periodically reinitializing
the KDF's keys. In the event that one of the keys has
been compromised, this prohibits unauthorized access
to the content of subsequent messages.
 AES256 - Signal employs the CBC block cypher to
encrypt and decode data based on the accepted global
standards (Cipher-block chaining).
Despite the numerous advantages Signal offers, like the
unique encryption of each communication and absolute
forward secrecy, it also has certain drawbacks due to the
complexity of its implementation, which necessitates
specialized understanding in cryptography to verify that it
was effective..
B. mIRC
Topic-oriented and allowing message exchange in groups
or privately, the Internet Relay Chat (IRC) protocol,
introduced in 1993, is a communication protocol extensively
used on the Internet for the exchange of communications.
IRC communications are sent in plaintext and are susceptible
to Man-in-the-Middle attacks since the protocol has no
related encryption (MITM).An development that wants to
use the methodology, such as the mIRC application, must
implement information security mechanisms, such as the
Transport Layer Security (TLS) protocol, in the
communication between Clients and Servers because the
protocol does not by default use any type of encryption.
Users of these applications may also try to safeguard the sent
information by using proxies or Virtual Private Networks
(VPNs).
The IRC system became popular because it was
straightforward, allowed users to communicate with
individuals from all over the world, used minimal data to
send messages, and allowed users to set up their own servers
to discuss certain subjects. These qualities led to the
protocol's widespread usage by hackers and hacktivists.
Despite the fact that IRC is a highly useful protocol for group
conversation, messages are still sent in plaintext because
there is no encryption.
C. Telegram
The MTProto protocol, which is presently in version 2.0
and was created for the Telegram app (https://telegram.org),
is used. The primary goals of this protocol are to ensure
consumer usability and the secrecy of data being exchanged
during message transmission.
The Signal protocol uses its own block cypher
implementation called IGE (Infinite Garble Extension)
for the Advanced Encryption Standard (AES) algorithm,
while this convention upholds the model presented in the
Transceiver protocol with the use of KDF and double
ratchets. This protocol does not use predetermined rules,
such as Electronic Classification model (ECB) or CBC.
However, because it was developed by mathematicians
who were not experts in cryptanalysis, it received a lot of
flak for not adhering to established practices. This
protocol's model was the target of several attacks against
which it lacked sufficient resistance, and it was possible
to decrypt an encrypted message without having the key
that had been used to encrypt it.
D. Threema
 A programme called Threema (https://threema.ch)
seeks to provide safe end-to-end communication.
Compared to more well-known encryption models like
Signal or MTProto 2.0, the Threema encryption scheme
is rather straightforward. The programme distinguishes
itself by employing the symmetric XSalsa20 cypher,
which is less expensive in terms of CPU, and by
constructing a key store that holds the id and public key
for each user. It also employs KDF and double ratchets to
provide complete forward secrecy.
Threema makes sure that a user may only access its
services if he possesses the private key associated with
the Threema-assigned id by implementing a key store on
both the server and the client. Threema additionally
guarantees a comparatively easy and safe method of
group communication. The programme is ignorant that a
user is a member of a group; it only knows that the user
wishes to send a message to another user. In order to
interact with a group of individuals, a user must send
separate messages, each encrypted with a different key, to
each member of the group.
 One benefit of Threema is that it contains key stores, and
when more players are added, it becomes easy to
demonstrate its legitimacy on both the Server and the
Client. Due to the requirement to deliver n-1 individual
messages encrypted with the appropriate keys, where n is
the number of individuals in the group, the programme
would not be useful for group chats with a large number
of users.
III. ARCHITECTURE
After A crucial design difficulty was finding the greatest
balance between security and performance. The application
of security technologies was established, along with an
explanation for not implementing the technologies that were
rejected. The following technologies were ignored
throughout the construction of the application: KDF, double
ratchet, and a key for each pair of customers. This is justified
by the absence of data permanence in the application and the
absence of the need to install very sophisticated security
measures that would slow down message exchange rates.
Additionally, key sharing is made possible and better
management with fewer keys is achieved.
A. Evaluation and Identification of Potential Architecture
It was important to determine which of the many security
and encryption methods used by the apps assessed in the
previous session would be most appropriate for the
development of the application. The technologies that were
adopted and abandoned, together with the related
justifications, are detailed here.
Since messages are being exchanged in real-time,
communication must take place as quickly as possible to
ensure that messages are sent right away. The choice was
made to encrypt communications using symmetric
encryption. In addition to the long life of the Room and
information scarcity, other reasons for acceptance were the
computational cost being comparatively cheap, the short time
required to encrypt and decode the messages, and the
absence of data permanence. Since it would take a long time
to brute-force the key, there would be significant information
security, offsetting the information's true worth.
KDF and double ratchet methodology implementations
were not used. The absence of data permanence in the
application and the requirement to have as little of an
influence on message exchange times as feasible were the
key justifications for abandoning them. Therefore, there
would be no need for such intricate security controls to be
put in place.
It was chosen to utilize the same key for all users while
making sure that the Administration is not granted access to
its key among the key sharing options (a key for each pair of
users or the identical key for all users). The reason for this is
that only individuals who have the right clearance to enter
the Room may partake in a Room, making it the fastest
option to complete the sharing and using the fewest amount
of keys overall.
The speed of message exchanges must be taken into
account as a key issue when analysing the application's
characteristics, real-time message exchange, and message
encryption. The AES-256 algorithm and CBC block cypher
were chosen as a result. The brute-force key discovery
procedure would be impractical at run time even if the key is
just 256 bits long due to the high computational cost and time
required to find the key. Additionally, the additional layer of
security provided by TLS increases the expense of finding
the key.
The User Datagram Protocol (UDP) and Datagram
Transport Layer Security (DTLS) processes were abandoned
despite having faster performance because they failed to
establish an active connection. As a result, it would be
necessary to implement a specific methodology for
confirming the legitimacy of message senders. A different
option would be to employ a symmetric key for each Client
to confirm the validity of each communication, using
something like HMAC, for instance. The secret password
that would only be known by the Client and the Server. This
key would be created by the Client and transmitted to the
Server using the Client's public key and encryption. Later,
the Server would put it in a key store of symmetric keys that
was just for the Server's usage and was not shared with any
Clients. This key would only be used to distribute the
messages and verify the sender.
Due to the original requirement to keep an active
connection and, thus, fairly assure the authenticity of the
user, without the need for any other supplementary
authentication verification technique, the TLS 1.3 option was
chosen. Encryption would also provide communication
secrecy, and the sent packets would be safeguarded by this
extra degree of security (hindering the sniffing and MITM
processes).
B. Implementation Management and Design
Having defined the factors that would serve as the basis
for the other implementations, the next step refers to the
definition of the application architecture. This definition is
presented below. The application was developed in the Java
programming language, version 15 and consists of three
distinct agents or modules, which are Server, Room, and
Client.
The Server is in charge of organising and managing the
Rooms. As seen in Figure 1, it is also in charge of regulating
access and establishing a connection with the Client, with
whom it communicates via the TLS protocol. The Server is
in charge of routing the user to the chosen Room after the
Client enters a Room.
Figure 2. Communication Representation
A room is a building that resembles a container for clients
and communications. The Room has a key store, a dynamic
structure that is kept in memory for the duration of the
Room's existence and holds all of the clients' public keys.
The cryptosystems for the Room are shared using the public
keys kept in the key store. The Conversation will only be
available for a certain amount of time, therefore messages
can only be sent in real-time or at run time.
The user-side programme is known as the client. Public
and private keys are generated instantly when a client enters
the programme and are the responsibility of each client.
Every client has a trust store of public keys that is an exact
replica of the room key store for every user. Using the
client's public key for encryption, the server securely
distributes the trust store.

Figure 3. Common messages and private message representation
The strategy adopted is the usage of a single key for all
Room users. The key is not controlled by the Server in order
to preserve the end-to-end characteristic; as a result, the
Server is unaware of the key used to encrypt messages in the
Room and, as a result, will not be aware of the messages'
contents. The Server takes part in the key-sharing process,
but only by sending control messages between users; it does
not have access to the key itself. Due to the encryption using
the users' public keys and the fact that only they conduct the
direct message exchanges, only users have access to the key
information. In Figure 2, the two methods for sending
messages in the programme are represented.
To confirm that an authentication process has already
been produced for the Room, each Client sends a control
message to the Server. The user will be in charge of creating
a new key if he would be the first one to enter the Room.
Each user of the Room will share this single key, which is for
the Room alone. Following the creation of the key, the Client
will send a confirmation message to the Server along with its
ID. The Server will then store this data together with a list of
all users who already possess the Room key. When a client
enters after the key has been generated, the client will send a
control message to the server, which will reply with a
message containing the ID details of one randomly selected
client who already has the necessary key information. This
method of generating and sharing the keys is shown in Figure
3.
Figure 4. Representation of key sharing.
For instance, Client A was in charge of making the Room
key. Client B then enters the Room and communicates with
the Server to inquire about the status of the key. The Server
gives Client ID A to Client B since Client A has produced a
key for the Room. The Client ID includes specific identifying
information about the Client that enables private
communication between users. Following then, Client B will
send Client A an encrypted message containing Client A's
ID. When receiving the request, Client A will reply to Client
B using Client B's public key, which can be located in the
trust store using the message's ID. Client B's reply will be an
encrypted message using Client B's public key, with the
symmetric key of the Room as content. As a result, only B
has access to the data, and the Server is still unaware of this
key. Only when there are no more clients in the Room and a
new customer joins the empty Room will the symmetric key
change take place.
Finally, the programme has no data permanence and
simply supports synchronous communication between users.
As a result, only when the Client is linked to the application
can messages be sent and received. Only when there are
people present or while the Room is active can it be accessed
and seen. In this approach, the Room lifespan or the duration
of application activity on the Client side are closely tied to
the information lifetime. As a result, neither the Client side
nor the Server side can access the information in the future.
IV. RESULTS AND DISCUSSIONS
The following components are included in the findings
analysis:
 Descriptive research of the application's innovative
characteristics.
 Analytical investigation of key sharing and message
encryption and decryption times.
It is important to note that since they don't offer information
on how long it takes for messages to travel between the
server and clients, the message exchange times in various
apps won't be compared.
The next sections will adequately handle the criteria
when they have been presented as being employed in the
analysis:
A. Evaluation of the application's quality
Different information security methods were found after
an analysis of the current applications. It was discovered that
unlike the application that was produced, information tends
to survive in applications. As a result, it was unnecessary to
incorporate sophisticated security features like double ratchet
or KDF, which are employed by WhatsApp, Viber, and
Signal.
Users' public keys were stored using a key store
technique similar to what is used in Threema. The method of
sending messages will be handled differently due to the fact
that every user of the Room has the same key. If the Threema
application message sending solution was used, each
message would need to be encrypted n times with various
keys in order to be sent in a group, and each of these
messages would also need to be sent n times, depending on
the overall number of clients in the Room. Due to the
associated expense of delivering messages to Rooms with a
large number of individuals since it would demand a greater
computational cost on the Client's end, it was decided to
disregard this practise.
The produced application, when compared to the other
apps, demonstrated two novel methods for applying security
measures that were not seen in any other programme, Nevertheless, despite the fact that the time had grown
namely: significantly, it was still reasonable given the circumstances.
It's also important to note that the message size affects how
 Given that the server is unaware of both the key and
well the programme performs. In situations when the
the content of the messages, the initial strategy put
majority of the messages were 250 characters or less, it was
forth in the programme was the sharing of a single
clear to see that there was a significant temporal jump.
key among all users, whose key is used for
encoding and decoding messages.
 The absence of data persistence in the application
constitutes its second strategy. There is no way to
obtain the data afterwards; the lifespan and access
are directly correlated with the time of
communication or the lifetime of the room.
In conclusion, the application demonstrated efficiency
in that it had high security and a high index of confidentiality
of the information, which were linked to satisfactory
performance during the exchange of messages. Additionally,
Figure 6. Table and graph related to the sending time of 500 messages.
the Server has no knowledge of the key.
Again, there was little to no variation in the timings for
The key weakness aspect, which would give access to all sending 500 messages, as seen in Figure 5. The timings for
communications exchanged while the Room was operational, the Rooms with all of the clients were similar, unlike the
is the application's biggest drawback. The usage of TLS prior instance, with the exception of messages with 250
rather than DTLS has been recognised as another drawback characters, which saw a significant variance but was still
since, despite the fact that both protocols provide data within the range predicted given the circumstances.
security, DTLS may transmit messages more quickly.
Despite this, DTLS would still require an extra layer of
authentication control from the message sender, whereas
TLS does not require this because Client and Server are
already connected.
B. Evaluation of the application’s quantity
The periods, measured in seconds, required to complete
the encryption of messages and the distribution of keys
among all users were taken into account while evaluating the
built programme quantitatively. The following evaluation
parameters were used: the number of clients present (10, 50,
100, 250), the number of messages transmitted (100, 500,
Figure 7. Table and graph related to the sending time of 1000 messages.
1000), and the character count per message (5, 20, 50, 100,
250). are Finally, the same time pattern was seen again for all
situations of a number of clients per Room in the case of
An individual server-side thread was used to generate all
sending 1000 messages, as shown in Figure 6. Contrary to
test results, and it was in charge of overseeing client
the two prior situations, the most significant difference in
connections and message exchanges. A single server-side
transmission time became apparent when messages were just
thread was used in the worst case scenario for the study,
100 characters long, as opposed to 250 characters in the other
which increased the latency of messages sent and received.
cases. Even though extremely high times were displayed,
These are the computer's specifications: Intel Core i7-8550U
they were reasonable.
1.8GHz, 16GB single-channel RAM, and Windows 10 x64.
The acquired findings are shown in Figures 4, 5, and 6. The results of the testing revealed that the speed of the
application is significantly impacted by the message size and
the number of users per Room. The tests were run to mimic a
simultaneous activity including customer entries and
message exchange. Although the tests do not accurately
reflect what would occur in a typical message exchange, it
was nevertheless feasible to observe how the programme
behaved. The test was conducted with the worst scenarios in
mind. Using messages that may include up to 250 characters,
sending this message all at once in under a second, and
giving the server a massive amount of messages to process.
Due to the excessive number of users and message size
established, even if the time given in certain circumstances is
Figure 5. Table and graph related to the sending time of 100 messages. noticeably high, this case is not compatible with actual use of
No significant difference in timings was seen while the chat programme. It was observed that the programme
sending 100 messages, as shown in Figure 4, regardless of operated effectively even under harsh situations and could be
the number of clients in a Room. The situation of the rooms utilised for the aforementioned tasks, guaranteeing a quick
with 250 clients, when times were offered that were twice as and secure connection.
long as those in the other cases, is where the largest disparity It was discovered that the server, which must handle
was shown. several requests simultaneously and causes a slowdown
issue, is the application's main bottleneck. This has an
immediate effect on how users login to the programme,
exchange keys, and forward messages between users. This
discovery leads to the conclusion that improved control
measures implementation on the server side is required in
order to enable adaptation to a real-world scenario including
different Rooms and users.
V. FUTURE WORK
Since this is the application's initial release, several
potential changes that might be made to add additional
functionality to it were discovered throughout the process.
The following traits were noted in this regard:
 Customer anonymity: Utilization of tools that
increase the user's level of anonymity, such as TOR,
VPNs, or proxies.
 Access sharing: among a variety of dispersed
regions (the shared key would be based on
geographic location).
 Use of DTLS: implementing a second key store,
message signatures, or hash-based message
authentication codes would be necessary (HMAC).
Additionally, it must include a method to ensure
message delivery and another to confirm the
legitimacy of the user.
 Provide several platforms for the software.
 The implementation of a more effective method to
change the symmetric keys that customer’s use,
preventing information access in the event that a
room's symmetric key is compromised. This can
depend on the quantity of messages issued, a certain
time, or the amount of consumers arriving and
exiting.
 Implement a type of timing so that messages may
only be seen at a specified moment, even during run
time.
VI. FUTURE WORK
topically This study described a chat group-based
application that enables secure and private communication
between several users, preventing the Server or an
unauthorized third party (man-in-the-middle attack or
message sniffing) from being able to view the content of the
messages transmitted. To accomplish the goal of message
secrecy, judgments were made on the usage of synchronous
communication, non-persistence of data, and symmetric key
maintained by a user.
The main difficulty was in exchanging keys with others
in a group setting, which adds an inherent complexity to the
process of communicating information covertly.
Nevertheless, a different and, in some ways, creative
approach was used to ensure the security of the information
transferred without sacrificing the amount of time spent
sending messages or the computational expense, providing a
high level of secrecy. The limited lifetime of the Room and
several security features make it difficult to get the Room
key even though sharing it is a straightforward method of
doing so (TLS and encryption). The exchange of messages
would only take place in real-time or while there was active
communication, and there is no data durability. As a result, if
a Client's connection with a Room ends or after the life of the
Room, it won't be able to access the information.
The programme ensures the secrecy and privacy of the
messages' contents while enabling users to exchange
messages in a safe and effective manner. Finally, despite the
complexity involved in managing information security for
groups of users, specifically in aspects related to the
exchange of keys and the efficient sending of messages while
maintaining this confidentiality, it was still possible to
identify an effective and secure solution that adds an
innovation in how it handles key sharing between members.
REFERENCES
[1] W. Stallings and L. Brown, "Computer Security: Principles and
Practice", 3rd ed., Prentice Hall Press, 2014, pp. 13-14.
[2] A. Beimel, "Secure Schemes for Secret Sharing and Key Distribution
PhD thesis", Israel Institute of Technology, Technion, Haifa, Israel,
1996.
[3] N K. Cohn-Gordon, C. Cremers, B. Dowling, L. Garratt and D.
Stebila, "A formal security analysis of the signal messaging protocol",
Journal of Cryptology, Vol. 33.4, 2020, pp. 1914-1983.
[4] V H.Krawczyk, "Cryptographic extraction and key derivation: The
HKDF scheme", Annual Cryptology Conference. Springer, Berlin,
Heidelberg, 2010. pp. 631-648.
[5] L. Chen, "Recommendation for key derivation using pseudorandom
functions", NIST Special Publication 800:108, October 2009.
[6] Perrin, Trevor, and Moxie Marlinspike. "The double ratchet
algorithm." GitHub wiki (2016).
[7] J. Oikarinen and D. Reed. "Internet relay chat protocol", IETF RFC
1459, May 1993.
[8] S. Mansfield-Devine, "Hacktivism: assessing the damage", Network
Security, Volume 2011, Issue 8, 2011, pp. 5-13.
[9] C. Campbell, "Design and specification of cryptographic capabilities",
IEEE Communications Society Magazine, Vol. 16, Issue: 6,
November 1978, pp. 15-19.
[10] D. J. Bernstein, "Extending the Salsa20 nonce." Workshop record of
Symmetric Key Encryption Workshop. Vol. 2011. 2011.
[11] E. Rescorla and T. Dierks, "The transport layer security (TLS)
protocol version 1.3.", IETF RFC 8446, August 2018.
[12] Genkin, D., Shamir, A., & Tromer, E. (2014, August). RSA key
extraction via low-bandwidth acoustic cryptanalysis. In International
Cryptology Conference, pp. 444-461, Springer, Berlin, Heidelberg.
[13] Rajanbabu, D. T., Raj, C. Implementing a reliable cryptography based
security tool for communication networks. In Science Engineering
and Management Research (ICSEMR), 2014 International Conference
on, pp. 1-4, 2014.
[14] Jain, A., Kapoor, V. (2015). Secure Communication using RSA
Algorithm for Network Environment. International Journal of
Computer Applications, 118(7), pp.6-9.