This work has been accepted at the 10th IEEE International Conference on Cyber Security and Cloud Computing

(CSCloud
2023)

Quarks: A Secure and Decentralized

Blockchain-Based Messaging Network
Mirza K. B. Shuhan1 , Tariqul Islam2 , Enam A. Shuvo3 , Faisal H. Bappy4 , Kamrul Hasan5 , and Carlos Caicedo 6
1
Software Research & Engineering, bKash Limited, Dhaka, Bangladesh
2,4,6
School of Information Studies (iSchool), Syracuse University, Syracuse, NY, USA
3
School of Computing, Asia Pacific University of Technology and Innovation, Kuala Lampur, Malaysia
5
Tennessee State University, Nashville, TN, USA
Email: {[email protected], [email protected], [email protected], [email protected],
[email protected], [email protected]}
arXiv:2308.04452v1 [cs.CR] 5 Aug 2023

Abstract—Over the past two decades, the popularity of mes- Telegram, for example, was banned in Russia in April 2018
saging systems has increased both in enterprise and consumer because it refused to provide the Russian Federal Security
level. Many of these systems used secure protocols like end-to- Service (FSB) with access to encrypted messages, as required
end encryption to ensure strong security features such as “future
secrecy” for one-to-one communication. However, the majority of by anti-terrorism laws [2]. Centralized architectures are more
them rely on centralized servers owned by big IT companies, which likely to pose the biggest threats to privacy and freedom of
allows them to use their users’ personal data. Also it allows the speech, including single point of failure, data leakage, and
government to track and regulate their citizens’ activities, which control over private conversations [3]. Therefore, the current
poses significant threats to “digital freedom”. Also, these systems Web 2 foundation cannot guarantee privacy or freedom of
have failed to achieve security attributes like confidentiality,
integrity, privacy, and future secrecy for group communications. In expression.
this paper, we present a novel blockchain-based secure messaging To tackle mass surveillance of conversations by government
system named Quarks that overcomes the security pitfalls of agencies and large corporations, all major messaging applica-
the existing systems and eliminates the centralized control. We tions are integrating end-to-end encryption to their protocols,
have analyzed our design of the system with security models and
definitions from existing literature to demonstrate the system’s re-
such as Signal [4], WhatsApp [5], Threema [6], Google Allo
liability and usability. We have developed a Proof of Concept (PoC) [7], and Facebook Messenger [8]. End-to-end encryption has
of the Quarks system leveraging Distributed Ledger Technology been proven [9] to be an outstanding way to implement secure
(DLT), and conducted load testing on that. We noticed that our messaging protocol that ensures additional security properties
PoC system achieves all the desired attributes that are prevalent like future secrecy [10]. However, we have seen these messaging
in a traditional centralized messaging scheme despite the limited
capacity of the development and testing environment. Therefore,
systems are vulnerable to malicious attacks due to the improper
this assures us the applicability of such systems in near future if implementations and imbalance between “usability first” or
scaled up properly. “privacy first”. These attacks include server-based attacks, such
Index Terms—instant messaging, blockchain, group communi- as vulnerability of Apple’s iMessage [11] and Signal Protocol
cation, system security. [12]. Moreover, researchers have been able to decipher the
message database at end-users’ devices of major messaging
I. I NTRODUCTION apps like WhatsApp, WeChat and Viber [13], [14], [15], [16].
The popularity of Messaging Systems has been increasing for Conventional models of data security rely on creating harder
its prompt response time, convenient user experience, and ease and harder walls– adding multiple factors of authentication
of multi-tasking in both informal and formal communication to ensure access control and emphasizing stronger encryption.
and collaboration. Despite it’s uprising popularity, there is With Blockchain, there exists the potential to scatter the stack,
also some concerns about the resiliency of these services and rendering the cost of any one breach or combination of breaches
users’ control over data. Because all popular messaging systems much lower. Combined with strong encryption methods and
leverage central servers to route text messages [1]. This gives zero knowledge proofs, Blockchain-based messaging systems
more control to big tech companies and government to provision can be a much more secure method of storing, accessing, and
the user activities. transmitting data; enhancing the ability of data managers to
The Internet’s provision of digital freedom is not a new thing. protect critical information.
It started with the use of metadata by big tech companies for Research Questions. The following research questions
profit-making opportunities. Centralized systems provide more (RQs) intrigued us to investigate existing messaging systems
control over user personal data, which can be sold to third and conduct this research. RQ1 : Can blockchain-based messag-
parties or used for targeted marketing. Moreover, centralized ing systems be utilized to ensure digital freedom and eliminate
systems are frequently monitored by governments in order control over user data? RQ2 : Is it possible to build a blockchain-
to keep track of their citizens’ activities, and some countries based messaging system that includes all the features of a
impose regulatory laws that potentially jeopardize user privacy. traditional messaging system? and RQ3 : Can blockchain-based
(decentralized) messaging systems overcome the security flaws system prone to single-point of failure, although it provides
of existing centralized messaging models? the service-provider with fine-grained control over the system.
In this paper, we try to address the above-mentioned re- Many companies, namely Signal [4], WhatsApp [5], Threema
search questions by proposing Quarks, a novel application of [6], Google Allo [7], and Facebook Messenger [8], have servers
Blockchain in decentralized messaging system which has not that are maintained by the service providers and they have full
been explored before. Quarks eliminates central control over access to the sensitive conversation data which raises privacy
data and ensures true decentralization, security, privacy, and concerns. Furthermore, researchers have been able to intercept
trust. The following are the major contributions of the paper. sensitive information from WhatsApp [22], [23], [24], which
• We developed a PoC of Quarks system that ensures has over two billion users worldwide. Rösler et al. [25] have
“Message Integrity” and “Trust in Federation” using Dis- analyzed the group communication of Whatsapp, Threema,
tributed Ledger Technology (DLT). and Signal. Their analysis disclosed that the communication
• Quarks ensures digital freedom, future secrecy, and guar- integrity and the groups’ closeness are not end-to-end protected.
antees no single point of failure. In addition, they proved that Signal protocol can not maintain
• We conducted performance and security analysis, which strong security properties like future secrecy in group commu-
demonstrate that our PoC meets all intended features of a nication.
truly decentralized messaging system. III. BACKGROUND AND S YSTEM A RCHITECTURE
The rest of the paper is organized as follows. In Section II, we
In this section, we first review some preliminaries and then
discuss some related work on the existing messaging systems.
present our system architecture.
The architecture of the Quarks is presented in Section III.
In Section IV, we describe the protocol flow of our Quarks A. Background
system. We present implementation, system performance, and Blockchain. Blockchain is a smartly engineered distributed
informal security analysis of Quarks in Section V. Finally, we system featuring an immutable ledger of transactions shared and
conclude the paper in Section VI. validated by a number of distributed Peer-to-Peer (P2P) nodes
II. R ELATED W ORKS [26]. The ledger is an ordered data structure consisting of many
blocks chained together by cryptographic mechanisms.
Sarıtekin et al. [17] and Mirzaei et al. [18] propose communi- Smart Contract (SC). Smart Contracts are computer pro-
cation applications named ‘CrypTouch’ and ‘Simorgh’ respec- grams deployed on top of the respective blockchain [27]. Being
tively, where both the schemes used IPFS (InterPlanetary File part of the ledger makes SC and their executions immutable
System) to store the messages off-chain. However, details about and irreversible, a sought-after property having a wide range of
their network structure and protocol flow was not presented in applications in different domains.
the paper. Also, IPFS is suitable only for storing large files. In Future Secrecy. Future secrecy is a prime feature of key
case of messaging systems, storing the messages in IPFS will agreement protocols in messaging systems which prevents an
add extra overhead as most of the messages are smaller in size. adversary (i.e., who compromises the message keys of a target
And it will require extra resources for each nodes to store and user) from decrypting any future messages in the conversation
maintain the whole messaging system. to some extent. This is achieved by a unique technique called
A chat application using Ethereum’s Whisper protocol is “ratcheting” in which session keys are updated with every
proposed by Abdulaziz et al. [19]. This protocol is designed message sent [28].
to “communicate darkness” (i.e., the content of the message is
inaccessible to those who intercepts the messages, and that com- B. Quarks Components
municating nodes cannot be easily identified) at high cost. It is a The following four are the key components and participants
off-chain protocol in which every message is sent to every node, of our proposed Quarks System. i. User: Users are the actors
and every node tries to decrypt the message. Consequently, the who use the system to communicate with their acquaintances;
protocol has high traffic, high processor and memory usages. ii. Quarks Channel: A channel is a message thread between
Hence, this is not an efficient protocol for chatting applications. two or more users; iii. Quarks Node: A Quarks node
Menegay et al. [20] attempt to implement a communication independently hosts multiples users and their messages and iv.
application using ‘Steem’, which is commonly referred as Quarks Network: A Quarks Network consists of multiple
the “social blockchain”, designed to power blockchain-based Quarks nodes where users from different nodes interact with
blogging and social media platforms. However, “Steem” is a each other.
public content platform which is not suitable for implementing
communication application. A blockchain-based secure commu- C. High Level View of Quarks System
nication framework for community interaction is proposed by The high level semantics of the proposed system is illustrated
Sharma et al. [21]. Their scheme manages identity of network’s in Fig. 1, where we can see that, our decentralized network
user through third party centralized service (Google) and all can consist of multiple nodes that are hosted independently. A
communication data are kept in centralized database. person can register as a user of a node. A user can: (a) create a
Currently, in most of the popular messaging systems, text channel, (b) invite other users to a channel, (c) join a channel
messages are routed through central servers [1]. It makes the upon invitation, (d) send messages to a channel, and (e) read
 A B C A B D User
TABLE II: User Registration Protocol
D E
node_1 node_2
F H
Quarks node
M1 AQ1 → Q1 : [N1 , U NA , KA , {N1 , U NA }K −1 ]
Ledger
A https
Q1
M2 Q1 → AQ1 : [N1 , CA ]https
C D A B D
node_3 node_4
F G I F G H
TABLE III: Channel Creation Protocol
Q1
[N1 , CA , {SKH }KA ,
Fig. 1: High level view of Quarks System M3 AQ 1 → Q1 : CNH , {N1 , CNH }K −1 ]https
A
M4 Q1 → AQ1 : [N1 ]https
TABLE I: Notations for Protocol Flow
Notations Description
Qi A Quarks node in the network channel through a https request. The request includes the
Q1
CNH Channel Name of Channel H name of the new channel (CNH ), certificate (CA ), signature,
SKH Symmetric Secret Key of Channel H and the channel secret key encrypted with the user’s public
JQi A user registered in node Qi
UNJ Username of JQi key ({SKH }KA ). The secret key will be generated by the user
AdrsQi Domain address of Qi creating the channel.
Q1
AdrsJ Qi Domain address of Qi where JQi has registered M4 . The node (Q1 ) validates the user’s certificate (CA ),
WJ Wallet of JQi digital signature, and then creates a new ledger for this
Q
CU i Certificate of JQi issued by Qi channel. Furthermore, the node sets up the smart contract
KJ Public key of JQi
KJ−1 Private key of JQi
for this channel and initiates the ledger for messaging. At
Ni A fresh nonce initiation, the smart contract stores the encrypted secret key
{}K Encryption operation using a public key K (SKH ) for this channel.
{}K −1 Signature using a private key K −1
H(.) A hash function 3. Node Addition Phase. [Table IV and Algorithm-1 (lines
[]https Communication over an HTTPS channel 8-14)]
msg A text message M5 . A member (AQ1 ) of the channel sends a request to
msgi ith msg in list of all textual messages the node (Q1 ) for federating with a new node (Q2 ) for the
M sgL List of text messages
M sgLK Every element is encrypted using K in this list
channel. The request includes member’s certificate, signature,
ts A timestamp in nanoseconds name of the channel, and the domain address of the new node.
QB Quarks Blockchain Network M6 . The node (Q1 ) validates the request, fetches the
SCH Smart Contract in Channel H certificate, and invokes smart contract function for adding the
LdgrH Ledger of Channel H
node (Q2 ) in the channel. The node (Q1 ) then sends it’s own
Q1 Q2
certificate (CA ) and the new node’s certificate (CA ).
messages from a channel. Each node creates a blockchain ledger M7 . The smart contract function validates the request and
for every channel and hosts the messages of that channel in that add the new node’s certificate (Algorithm 1, lines 9-10) in the
ledger. A node hosts only the ledgers of which it’s users are authorized list of nodes and sends back a response (N2 ) to the
part of. node (Q1 ).
IV. Q U A R K S P ROTOCOL F LOW M8 . After receiving the success response from the smart
contract function, the node asks the new node to join the
In this section, we present the protocol flow between different
channel, synchronizes the ledger (LdgrH ), and the smart
components of our proposed system. The mathematical nota-
contract (SCH ). The message contains the encrypted ledger
tions and symbols used to describe this protocol flow are listed
and the smart contract.
in Table I. The protocol has seven phases: i) user registration;
M9 . The new node (Q2 ) validates the request, creates a
ii) channel creation; iii) node addition; iv) channel member
replica of the ledger, and sets up the smart contract in the
addition; v) channel secret key retrieval; vi) message sending
ledger. Finally, the new node starts synchronizing the ledger
and vii) receiving.
and the smart contract with all the participating nodes of the
1. User Registration Phase. [Table II]
channel and sends back a nonce (N3 ) to the node(Q1 ).
M1 . Firstly, the user (AQ1 ) generates a pair of public and
−1 M10 . Upon successful addition of a new node (Q2 ) in the
private keys (KA , KA ). Next, the user sends it’s username,
channel, the node (Q1 ) sends back a “success message” to the
public key, and digital signature to the Quarks node (Q1 )
the requesting member (AQ1 ) of the channel.
through a https request.
M2 . The node (Q1 ) validates the signature, generates a digital 4. Channel Member Addition Phase. [Table V and
Q1
certificate (CA ) for the user, and makes an entry in the off- Algorithm-1 (lines 15-19)]
chain database. Finally, the node returns the certificate and M11 . At first, a member (AQ1 ) of the channel sends a request
the nonce (N1 ) to the user. A fresh nonce is used in every to the node (Q1 ) to add a user (U NB ) to the channel. The
Q1
transmission to combat replay attacks. request contains certificate of the member (CA ), the signature
2. Channel Creation Phase. [Table III] of the member, new username (U NB ), and the node’s address
M3 . The user (AQ1 ) requests the node (Q1 ) to create a new (AdrsBQ1 ) of the user.
 TABLE IV: Node Addition Protocol TABLE V: Add Member Protocol
Q1 Q1
[N1 , CA , [N1 , CA , U NB , AdrsB
Q1
M5 AQ1 → Q1 : AdrsQ2 , CNH , {N1 , CNH }K −1 ]https M11 AQ1 → Q1 : CNH , {N1 , CNH }K −1 ]https
A A
M6 Q1 → SCH : [N2 , CQ1 , CQ2 ]https M12 Q1 → AQ1 : [N1 , KB ]https
M7 SCH → Q1 : [N2 ]https M13 AQ1 → Q1 : [N2 , {SKH }KB ]https
[N3 , CQ1 , LdgrH , SCH ]https Q1
M8 Q1 → Q2 : [N3 , CQ1 , CA ,
M14 Q1 → SCH : Q1
M9 Q2 → Q1 : [N3 ]https CB , {SKH }KB ]https
M10 Q1 → AQ1 : [N1 , success msg]https M15 SCH → Q1 : [N3 ]https
M16 Q1 → AQ1 : [N2 , success msg]https

Algorithm 1: Smart Contract

M14 . The node invokes the smart contract of the channel to
1 Input: req ▷ function name and parameters
2 Output: resp ▷ output of function store the encrypted channel secret key. The node then sends
3 Start the certificate of itself, the requesting member’s certificate, the
4 ChN odes ← GetChNodeCerts() new user’s certificate, and the encrypted channel secret key.
5 ▷ get certificate list of the nodes of the channel M15 . The smart contract function (Algorithm 1, line 17)
6 ChU sers ← GetChUsersCerts() stores the encrypted secret key in the ledger. As the key was
7 ▷ get certificate list of the users of the channel
8 fn addNode(N2 , CQ1 , CQ2 ) encrypted using user’s public key, only the entity having the
9 if CQ1 ∈ ChN odes then private key will be able to decrypt this secret key.
10 ChN odes ← ChN odes ∪ CQ2 M16 . Finally, after successfully invoking add member
11 ▷ add the new certificate to the set function of the smart contract, the node sends the requesting
12 PutChNodeCerts(ChN odes) member a success message.
13 ▷ put the updated list in the ledger
14 return N2 5. Channel Secret Key Retrieval Phase. [Table VI and
Q1 Q1
15 fn addMember(N3 , CQ1 , CA , CB , {SKH }KB ) Algorithm-1 (lines 20-24)]
Q1
16 if CQ1 ∈ ChN odes ∧ CA ∈ ChU sers then M17 . The user requests the node to get the encrypted
Q1
17 PutSK(CB , {SKH }KB ) channel secret key. The request includes name of the channel,
18 ▷ put encrypted secret key in the ledger
19 return N3 user’s certificate, and the digital signature.
20 fn getChannelSK(N2 , CQ1 , CA Q1
) M18 . The node validates the user’s request and checks if the
21
Q1
if CQ1 ∈ ChN odes ∧ CA ∈ ChU sers then channel exists. If the channel is found, the node invokes smart
22 {SKH }KA ← GetSK(CA Q1
) contract function (Algorithm 1, lines 21-22) for retrieving the
23 ▷ get encrypted secret key from ledger encrypted secret key (SKH ) of the channel.
24 return N2 , {SKH }KA M19 . Upon validating the parameters, smart contract
Q1
25 fn sendMsg(N2 , CQ1 , CA , {msg}SKH ) retrieves the encrypted secret key from the ledger and sends
Q1
26 if CQ1 ∈ ChN odes ∧ CA ∈ ChU sers then back the encrypted key to the node.
27 ts ← GetTs()
28 ▷ get current timestamp in nanoseconds
M20 . The node (Q1 ) responds to user’s request by sending
29 PutState(ts, {msg}SKH ) back the encrypted key. The user (AQ1 ) will be able to
30 ▷ store encrypted message in the ledger decipher the key (SKH ) using it’s private key (K −1 ).
31 return N2
Q1
32 fn readMsg(N2 , CQ1 , CA , ts) TABLE VI: Get Channel Secret Key Protocol
Q1
33 if CQ1 ∈ ChN odes ∧ CA ∈ ChU sers then Q1
34 tsf ← ts [N1 , CA ,
M17 AQ1 → Q1 : CNH , {N1 , CNH }K −1 ]https
35 tst ← GetTs() A
Q1
36 ▷ get current timestamp in nanoseconds M18 Q1 → SCH : [N2 , CQ1 , CA ]https
37 M sgLSKH ← GetStateByRange(tsf , tst ) M19 SC H → Q1 : [N2 , {SKH }KA ]https
38 ▷ get messages sent between tsf and tst M20 Q1 → AQ1 : [N1 , {SKH }KA ]https
39 return N2 , MsgLSKH
6. Message Sending Phase. [Table VII and Algorithm-1
(lines 25-31)]
M21 . The user (AQ1 ) sends, the message encrypted with the
M12 . After request validation, the node fetches the user’s channel secret key, user’s certificate, name of the channel, and
certificate using user’s node address and username. If the new the signature to the node (Q1 ).
member was registered on the same node, the node will be M22 . The node (Q1 ) validates the request, invokes the smart
able to fetch it from it’s local database. Otherwise, the node contract function (Algorithm 1, line 25) for sending messages
has to request the user’s node to share the certificate of the in the channel.
user. Next, the node sends the requesting member (AQ1 ) the M23 . The smart contract (SCH ) function validates the user’s
public key (KB ) of the user. membership in the channel (Algorithm 1, line 26) and if
M13 . The member (AQ1 ) now encrypts the channel’s secret succeeds, puts the encrypted message in the ledger.
key (SKH ) using the received public key (KB ) and send it to M24 . Finally, the node (Q1 ) sends back a success message
the node (Q1 ). to the user (AQ1 ) after a successful smart contract invocation.
 TABLE VII: Send message protocol [32] is opened for every quarks channel. We built a backend
Q1
[N1 , CA , {msg}SKH service using NodeJs [33] so that our clients can interact with
M21 AQ1 → Q1 : CNH , {N1 , CNH }K −1 ]https the blockchain. We used ReactJS [34] for our Frontend and
A
[N2 , CQ1 , CAQ1
, MongoDB [35] for the off-chain database.
M21 Q1 → SC H :
{msg}SKH ]https
M23 SC H → Q1 : [N2 ]https
M24 Q1 → AQ1 : [N1 , success msg]https B. Performance Analysis
For testing the performance of our PoC, we have set up
a controlled simulation environment targeting a maximum of
7. Message Reading Phase. [Table VIII and Algorithm-1 100 users. Figure 2 shows the structure of our environment. It
(lines 32-39)] contains a Locust and 2 Ubuntu servers containing 3 nodes of
M25 . The user (AQ1 ) asks the node (Q1 ) to fetch all messages the Quarks system. The simulation is carried out in a series
in a period of time. The request includes the channel’s name, of cycles that vary depending on the number of users. First, we
certificate, signature, and a timestamp (in nanoseconds). start with 20 users and add 20 more users in each cycle till 100
M26 . After validating the request, the node invokes the smart users. Each cycle contains the following three steps: i) each
contract function (Algorithm 1, lines 32) to read the contents simulated user sends and reads messages from the Quarks
of the channel. The node passes the timestamp along with the using a REST API; ii) for each API request, the response time
certificates of the node and the user as function parameters. is measured (in ms); and iii) on the Locust end, the throughput
M27 . Once the validation of parameters is done, the smart is measured by calculating the number of requests served per
contract queries the encrypted messages from the ledger and second.
sends back the message list (M sgLSKH ) to the node. After simulating for 100 users, we also performed a stress test
M28 . The node (Q1 ) sends back the message list to the on our environment. We added 50 additional users in 5 more
user (AQ1 ). Finally, the user will be able to read the message cycles to check if the system can handle excessive loads. Figure
contents by decrypting the messages using channel secret key. 3(a) and 3(b) shows the median response time for all our test
cycles. For usual test cycles (20-100 users), the response time
TABLE VIII: Read message protocol is decent considering the decentralized architecture. It increases
Q1
[N1 , CA , ts linearly as the number of users increases. And for stress testing
M25 AQ1 → Q1 : CNH , {N1 , CNH }K −1 ]https cycles, the response time is respectively higher. However, our
A
Q1
[N2 , CQ1 , CA , system can handle all requests of up to 150 users with its limited
M26 Q1 → SC H :
ts]https capacity. In figure 3(c), the system’s throughput increases with
M27 SC H → Q1 : [N2 , M sgLSKH ]https the number of users in usual test cycles. As the number of users
M28 Q1 → AQ1 : [N1 , M sgLSKH ]https
grows, so does the number of requests per second (throughput).
However, in stress test cycles figure 3(d), the throughput reaches
ubuntu_server_two
a saturated level. This indicates that our PoC has reached its
ubuntu_load_tester quarks_two maximum capacity.
hyperledger fabric

peer
LOCUST back-end CA Though we tested our PoC in a small simulation environment,
orderer
front-end
off-chain db
ledger it showed 100% availability and decent performance in sending
ubuntu_server_one
quarks_one quarks_three and reading messages. We believe that with proper resources,
hyperledger fabric
hyperledger fabric

peer peer

back-end CA back-end CA Quarks could be scaled to use as a decentralized messaging

orderer orderer
front-end front-end
off-chain db
ledger
off-chain db
ledger system. Also, in the upcoming era of 5G and the increasing
popularity of DApps (Decentralized Applications), Quarks
Fig. 2: Proof-of-Concept of Quarks System will be more feasible to use and can be integrated with other
decentralized systems for secured message sharing.

V. I MPLEMENTATION C. Informal Security analysis of Quarks

We have implemented a proof-of-concept and analyzed it’s Confidentiality. Every message in the ledger in Quarks is
performance. We have recorded the throughput and latency encrypted with a secret key unique to a channel. This channel’s
of (a) Send Message and (b) Read Message; simulating with secret key is only known to the members of the channel. This
increasing loads using an open source load testing tool named guarantees protection against potential data breaches.
Locust [29]. Integrity. In Quarks all the messages are stored on-chain.
That means it is impossible to delete or tamper the previous
A. Proof of Concept (PoC) messages.
We leveraged Hyperledger Fabric [30] to implement the Non-Repudiation. As every message-write is digitally signed
blockchain network. Here, every Quarks node have their by the members and signatures are being verified by smart
own Certificate Authority (CA), an Orderer, and multiple contract, Quarks diminishes repudiation attempts.
peers. We developed fabric chaincode using golang [31] for Authentication and Authorization. Users interact with the
implementing Smart Contract. For Ledger, a fabric-channel Quarks by authenticating with their private keys which enables
 Fig. 3: Performance evaluation of Quarks (Median Response Time and Throughput)

the Quarks nodes to prevent unauthorized access to the users’ [13] K. Rathi, U. Karabiyik, T. Aderibigbe, and H. Chi, “Forensic analysis
data. of encrypted instant messaging applications on android,” in 2018 6th
international symposium on digital forensic and security (ISDFS). IEEE,
Resilient to DDoS Attacks. DDoS attackers may successfully 2018, pp. 1–6.
make a single node unavailable for some time; however, the [14] L. P. Gudipaty and K. Y. Jhala, “Whatsapp forensics: decryption of
decentralized nature of the Quarks network will keep the encrypted whatsapp databases on non rooted android devices,” Journal
Information Technology & Software Engineering, vol. 5, p. 2, 2015.
service intact. [15] J. Grover, “Android forensics: Automated data collection and reporting
from a mobile device,” Digital Investigation, vol. 10, pp. S12–S20, 2013.
VI. C ONCLUSION [16] S. Wu, Y. Zhang, X. Wang, X. Xiong, and L. Du, “Forensic analysis of
wechat on android smartphones,” Digital investigation, vol. 21, pp. 3–10,
To ensure private and secure communication over a decen- 2017.
tralized network, we have designed and developed a messaging [17] R. A. Sarıtekin, E. Karabacak, Z. Durgay, and E. Karaarslan, “Blockchain
based secure communication application proposal: Cryptouch,” in 2018
system leveraging distributed ledger technology. Going forward, 6th International Symposium on Digital Forensic and Security (ISDFS).
we believe that our design will empower individuals to set-up Ieee, 2018, pp. 1–4.
nodes and communicate with their peer nodes securely. Our [18] E. Mirzaei and M. Hadian Dehkordi, “Simorgh, a fully decentralized
blockchain-based secure communication system,” Journal of Ambient
implemented PoC assured us of the feasibility of such systems. Intelligence and Humanized Computing, pp. 1–19, 2022.
We envision that, our novel approach to solve the current secu- [19] M. Abdulaziz, D. Çulha, and A. Yazici, “A decentralized application
rity issues of the existing messaging systems will open up new for secure messaging in a trustless environment,” in 2018 International
Congress on Big Data, Deep Learning and Fighting Cyber Terrorism
school of thoughts and pioneer the next generation messaging (IBIGDELFT). IEEE, 2018, pp. 1–5.
services that we would be using for secure communication and [20] P. Menegay, J. Salyers, and G. College, “Secure communications using
collaboration. blockchain technology,” in MILCOM 2018-2018 IEEE Military Commu-
nications Conference (MILCOM). IEEE, 2018, pp. 599–604.
[21] R. Sharma, M. Wazid, and P. Gope, “A blockchain based secure commu-
R EFERENCES nication framework for community interaction,” Journal of Information
Security and Applications, vol. 58, p. 102790, 2021.
[1] Z. Xiao, L. Guo, and J. Tracey, “Understanding instant messaging [22] F. Karpisek, I. Baggili, and F. Breitinger, “Whatsapp network forensics:
traffic characteristics,” in 27th International Conference on Distributed Decrypting and understanding the whatsapp call signaling messages,”
Computing Systems (ICDCS’07). IEEE, 2007, pp. 51–51. Digital Investigation, vol. 15, pp. 110–118, 2015.
[2] M. Wijermars, “Selling internet control: the framing of the russian ban [23] D. Wijnberg and N. Le-Khac, “Identifying interception possibilities for
of messaging app telegram,” Information, Communication & Society, pp. whatsapp communication,” Forensic Science International: Digital Inves-
1–17, 2021. tigation, vol. 38, p. 301132, 2021.
[3] K. E. F. Musiani et al., “Concealing for freedom: The making of [24] R. Cents and N. Le-Khac, “Towards a new approach to identify whatsapp
encryption, secure messaging and digital liberties,” 2022. messages,” in 2020 IEEE 19th International Conference on Trust, Security
[4] “Signal,” https://signal.org/, accessed: 2022-02-02. and Privacy in Computing and Communications (TrustCom). IEEE,
[5] “Whatsapp security,” https://www.whatsapp.com/security/, accessed: 2020, pp. 1895–1902.
2022-02-02. [25] P. Rösler, C. Mainka, and J. Schwenk, “More is less: On the end-to-end
[6] “Threema security,” https://threema.ch/en/security, accessed: 2022-02-02. security of group chats in signal, whatsapp, and threema,” in 2018 IEEE
[7] “Open whisper systems partners with google on end-to-end encryption European Symposium on Security and Privacy (EuroS&P). IEEE, 2018,
for allo,” https://whispersystems.org/blog/allo/, accessed: 2022-02-02. pp. 415–429.
[8] “Facebook messenger deploys signal protocol for end to end encryption,” [26] M. J. M. Chowdhury, M. S. Ferdous, K. Biswas, N. Chowdhury, A. Kayes,
https://whispersystems.org/blog/facebook-messenger/, accessed: 2022-02- M. Alazab, and P. Watters, “A comparative analysis of distributed ledger
02. technology platforms,” IEEE Access, vol. 7, pp. 167 930–167 943, 2019.
[9] K. Cohn-Gordon, C. Cremers, B. Dowling, L. Garratt, and D. Stebila, [27] M. S. Ferdous, F. Chowdhury, and M. Alassafi, “In search of self-
“A formal security analysis of the signal messaging protocol,” Journal of sovereign identity leveraging blockchain technology,” IEEE Access, vol. 7,
Cryptology, vol. 33, no. 4, pp. 1914–1983, 2020. pp. 103 059–103 079, 2019.
[10] “Advanced cryptographic ratcheting,” https://signal.org/blog/ [28] K. Cohn-Gordon, C. Cremers, B. Dowling, L. Garratt, and D. Stebila, “A
advanced-ratcheting/, accessed: 2022-02-02. formal security analysis of the signal messaging protocol,” J. Cryptol.,
[11] C. Garman, M. Green, G. Kaptchuk, I. Miers, and M. Rushanan, “Dancing vol. 33, no. 4, pp. 1914–1983, 2020.
on the lip of the volcano: Chosen ciphertext attacks on apple {iMessage},” [29] “Locust,” https://locust.io/, accessed: 2022-02-06.
in 25th USENIX Security Symposium (USENIX Security 16), 2016, pp. [30] “Hyperledger Fabric,” https://www.hyperledger.org/use/fabric.
655–672. [31] Google, “Go: Build fast, reliable, and efficient software at scale,” https:
[12] N. Kobeissi, K. Bhargavan, and B. Blanchet, “Automated verification for //go.dev/, accessed: 2022-02-06.
secure messaging protocols and their implementations: A symbolic and [32] “Channels,” https://hyperledger-fabric.readthedocs.io/, accessed: 2022-02-
computational approach,” in 2017 IEEE European symposium on security 06.
and privacy (EuroS&P). IEEE, 2017, pp. 435–450. [33] O. Foundation, “Nodejs,” https://nodejs.org/en/, accessed: 2022-02-06.
[34] F. O. Source, “Reactjs,” https://reactjs.org/, accessed: 2022-02-06.
[35] M. Inc., “Mongodb,” https://www.mongodb.com/, accessed: 2022-02-06.