1 Introduction

Since the introduction of Bitcoin in 2008 [1], the concept of blockchain, which dates back to the 1970s [2] has been employed by many developers to provide solutions for their applications. Blockchain technology and cryptocurrencies have sparked concerns related to guaranteeing users’ privacy and security protection due to the deployment of algorithms that can be selected by users (“bring your own algorithm” concept). Blockchain, a public ledger where transactions are stored in blocks, is characterized by immutability, decentralization, anonymity, and auditability [3]. Data are stored in a chain of blocks, where each block is linked to the previous block through its hash. The nodes of the network (miners) are responsible for calculating the hash value [4]. Blockchain blocks are distributed to all users, leading to block immutability. This is because to alter any block, a large number of calculations must be performed. In addition, the consensus process is performed in a decentralized and distributed manner without the intervention of a third party. To guarantee data integrity, blockchain uses cryptographic algorithms such as asymmetric encryption, digital signature, and hash functions. In addition, cryptographic techniques provide the ability to trace transactions and ensure data confidentiality [3]. The following three generations of blockchain exist: blockchain 1.0, blockchain 2.0, and blockchain 3.0. However, a new generation, blockchain 4.0 is currently under development [5]. While blockchain 1.0 is mainly concerned with cryptocurrency applications, blockchain 2.0 concerns whole markets and economies; it stores not only transactions but also smart contracts and applications; an example of this type of application is Ethereum. Blockchain 3.0, which is considered an evolution of blockchain 2.0, extends the technology into more applications in areas such as art, health, science, and government. Artificial intelligence has recently been introduced in blockchain 4.0, to enhance consensus efficiency, scalability, and energy efficiency and to incorporate blockchain technology into real environments. Blockchain is used in many applications, such as banking, financial transactions, supply chain management, healthcare, and education. The security requirements for these applications include confidentiality, integrity, and authentication. Confidentiality is delivered through the encryption of sensitive information. On the other hand, authentication is achieved through digital signatures. Integrity is ensured via two mechanisms. The first is the inclusion of the hash value of the preceding block and the second is the calculation of the root hash of all block transactions. Most blockchain platforms use third-party cryptographic solutions [6]. One of these solutions is the networking and cryptography library (NaCl) [7], which is a public domain library for network communication, encryption, decryption, and signatures. NaCl (pronounced "salt") and its forks (i.e. LibSodium) provide cryptographic algorithms that are utilized in well-known blockchain platforms (e.g. Apache Tuweni, Duniter, Tezos), cryptocurrencies (e.g. Zcash), and cryptocoin wallets (e.g. SilentDragon, SilentDragonLite). NaCl is the chemical abbreviation for sodium chloride, commonly known as salt which is an ionic compound with the chemical formula NaCl. Cryptographic algorithms aim to provide the following four well-known security services: confidentiality, authenticity, integrity, and non-repudiation. As mentioned in [7], the NaCl library ensures confidentiality and integrity; however, it does not provide non-repudiation, which is considered an authentication service. Non-repudiation is the main security requirement that must be fulfilled, especially in the case of disputes. This paper proposes a solution to the aforementioned drawback of the NaCl library. In NaCl, to provide the aforementioned security services, messages are signed and then encrypted. Therefore, the non-repudiation service is not provided. In the present paper, to solve this problem, another signature block is added. Furthermore, the security analysis of both the NaCl library and the proposed improvement is conducted using Burrows, Abadi and Needham (BAN) logic [8, 9]. The analysis demonstrates that the proposed modification fixes the problem. The main contributions of the present paper can be summarized as follows:

  • Examine which security libraries are used in Blockchain applicationsf.

  • Analyze the NaCl library using the BAN logic. The analysis shows that the NaCl library has the following primary drawback, the inability to provide a non-repudiation security service.

  • Propose a solution to this problem and analyze it using BAN logic.

The remainder of this paper is organized as follows. The next section provides a literature review of different security libraries. Subsequently, a description of the NaCl library is provided, followed by a security analysis using BAN logic. The proposed solution is then described in detail and analyzed using (BAN) logic in Sect. 3. In Sect. 4, a performance analysis is illustrated. The final section concludes the paper.

2 Literature review

This section provides a brief description of the different cryptographic libraries used in modern applications. Then, a description of the NaCl library modules is detailed. Subsequently, it proposes critiques of the library and security analysis using BAN logic.

2.1 Cryptographic libraries

Blockchain is an immutable distributed digital ledger that is based on cryptographic algorithms to provide security, and uses consensus mechanism to agree upon the transaction log [10]. Cryptographic libraries are used to perform the cryptographic operations needed to provide trust in using Blockchain technology. Following are examples of cryptographic libraries that are used in literature: wolfCrypt [11], an embedded library for symmetric and asymmetric algorithms, Cifra [12] that is mainly concerned in implementing symmetric algorithms, TinyCrypt [13] and micro-ecc (uECC) [14], Crypto-JS [15], and Relic [16], which contains symmetric and asymmetric cryptographic schemes with particular support for many elliptic curves. A lightweight cryptographic library which is named Bouncy Castle is based on lightweight APIs for TLS (RFC 2246, RFC 4346) and DTLS (RFC 6347/ RFC 4347) [17]. In [18], a comparison among cryptographic libraries utilized for encryption operations performed in Blockchain is conducted. The following libraries are used in Blockchain networks: PBC library [19], Crypto++ library [20], MIRACL library [21], and Hyperledger Ursa [22].

Researchers have explained that the usability and misuse resistance of application programming interface (API) implementations are critical for practical cryptographic library deployments. Many solid API design guides provide developers with the required knowledge to develop usable and misuse-resistant cryptographic implementations. In the OpenSSL cryptographic library [23], users cannot modify their APIs design because of the backward compatibility issue. Few cryptographic libraries consider fundamental usability. However, more recent libraries, such as the Networking and Cryptography library (NaCl) and its forks, provide high levels of usability and misuse-resistance features of APIs [24, 25]. Improving the usability of API is a fundamental objective of the NaCl library. The NaCl library focuses on the most significant use-cases and manipulates use-cases that are not complex in high-level API. The NaCl cryptographic library and its forks, such as libsodium, are distinguished based on their user-oriented viewpoint and concentration on usability features. Cryptographic researchers and software developers have elaborated on the features of cryptographic libraries (e.g., the usability and misuse resistance of API designs) and their importance, which encompasses making cryptographic libraries bug-free codes. Recent libraries such as NaCl and its forks (i.e., libsodium, sodiumoxide, rust_sodium, PyNaCl, TweetNaCl, PySodium, and Keyczar) offer robust concentrations for achieving a high level of usability and misuse-resistant features of APIs design [26, 27]. The Keyczar cryptographic library allows developers to safely and easily use cryptography. The PyNaCl library binds to the NaCl library using Python. Moreover, PyNaCl was considered to be the libsodium interface using Python. Furthermore, sodium is a potential replacement for PyNaCl. NaCl and its forks are cryptographic libraries that are designed and implemented with a focus on usability (these libraries do not require the designer/developer to select cryptographic details). These libraries provide secure asymmetric and symmetric APIs. The NaCl cryptographic library and its forks (i.e., TweetNaCl and libsodium APIs) were used in the implementation of post-quantum cryptographic algorithms [28]. NaCl and its forks (i.e. LibSodium [29, 30]) provide cryptographic algorithms that are utilized in well-known blockchain platforms (e.g. Apache Tuweni [31], Duniter [32], Tezos [33]), cryptocurrencies (e.g. Zcash [34]), and cryptocoin wallets (e.g. SilentDragon [35], SilentDragonLite). In what follows, we elaborate on some blockchain platforms, cryptocurrencies, and cryptocoin wallets that deploy a fork of the NaCl cryptographic library (i.e. LibSodium). Apache Tuweni [31] is a blockchain platform that consists of a set of libraries (e.g. LibSodium which is a fork of the NaCl cryptographic library), tools that help in the development of blockchain, and decentralized software built in Java and other Java Virtual Machine (JVM) languages (e.g. Java, Kotlin, Scala, Groovy, Clojure, Fantom, Ceylon, Jython, JRuby, Frege, Xtend, Golo, Concurnaas, Yeti.) The Ethereum Virtual Machine (EVM) is implemented using Kotlin code. Duniter [32] (originally uCoin) is a blockchain platform that deploys a fork of the NaCl cryptographic library (i.e. LibSodium). It is a free software that enables users to create a new type of P2P crypto-currency using individuals and universal dividends. The Duniter network is decentralized. It uses blockchain to synchronize the state of money across nodes. In contrast to Bitcoin, Duniter has no power race. In Bitcoin, because of the CPU race, power is provided to those who own more computing power. Duniter is democratic; because every user is identified as a unique human, they can write in the blockchain in turns. When a member writes data in the blockchain, he must wait before being able to write again. This ensures that the blockchain does not end in the hand of a few users and that it does not burn too much energy. To identify users, Duniter chooses a self-regulated system by its members. This is known as the Web of Trust (WoT). Each member can certify new users. When a user receives sufficient certifications, and is not too far away from the existing members in the web of trust, he becomes a member. Bitcoin's blockchain mechanism is important for two main reasons: synchronization and security. Duniter’s blockchain thus benefit from these two features. However, Duniter's blockchain is slightly different: it does not only store transactions, but also stores community activity in order to define the WoT. It also has a different Proof-of-Work (PoW) mechanism that is made possible by the WoT definition, providing a much more energy-efficient mechanism in order to compute the blockchain. Tezos [33] is an open-source blockchain platform that deploys a fork of the NaCl cryptographic library (i.e. LibSodium) and executes peer-to-peer transactions and serve as a platform for deploying smart contracts. The native cryptocurrency for the Tezos blockchain is the Tez (ISO 4217: XTZ; sign: ꜩ). The Tezos network achieves consensus using proof-of-stake. Tezos uses an on-chain governance model that enables the protocol to be amended (when upgraded proposals receive a favorable vote from the community.) Its testnet was launched in June 2018, and its main net went live in September 2018. Tezos, which was first proposed in 2014, was created by Arthur and Kathleen Breitman. Zcash [34] is a cryptocurrency aimed at using cryptography (i.e. deploy a fork of the NaCl cryptographic library (i.e. LibSodium)) to provide enhanced privacy for its users compared to other cryptocurrencies such as Bitcoin. Zcash is based on Bitcoin's codebase. It shares many similarities, such as, a fixed total supply of 21 million units. Transactions can be "transparent" and similar to bitcoin transactions. Zcash affords private transactors, the option of "selective disclosure". This allows a user to prove payment for auditing purposes. One reason to allow private transactors is to comply with anti-money laundering or tax regulations. "Transactions are auditable but disclosure is under the participant's control. While miners receive 80% of a block reward, 20% is given to the "Zcash development fund": 8% to Zcash Open Major Grants, 7% to Electric Coin Co., and 5% to The Zcash Foundation. Silent Dragon (SD) [35] is a compatible wallet (that deploy a fork of the NaCl cryptographic library (i.e. LibSodium)) and a full node that runs on Linux, Windows, and macOS for HUSH. HUSH is the cryptocurrency of the Hush platform. SD is a one-stop solution that offers high-speed messaging and transactions. The next subsection briefly describes the NaCl library.

2.2 NaCl library

The NaCl library was first published in 2008. The first version of NaCl was released in 2009. Subsequently, the library has undergone several enhancements, such as the inclusion of both the C +  + NaCl API and digital signatures. The most recent version of the NaCl library was released in 2017. The NaCl library aims to ensure strong confidentiality, integrity, and availability [7], as shown in Fig. 1. Confidentiality is provided only for the packet content. Therefore, users must incorporate anti-traffic analysis tools in their systems to hide packet lengths and timings. The library consisted of six main functions: crypto_box, crypto_box_open, crypto_box_keypair, crypto_sign, crypto_sign_open, and crypto_sign_keypair. The following paragraphs provide descriptions of these functions.

Fig. 1
figure 1

NaCl library structure

Full size image

The crypto_box: This function provides public key authenticated encryption. The first step is to sign a message “m” using the sender’s secret key “sk1”. This step provides authenticity and integrity. The signed message is then encrypted using the receiver’s public key “pk2” to produce the ciphertext “c”. This step provides confidentiality. To ensure message freshness, a nonce “n” is used. The following equation represents the encryption function.

$$ c = {\text{crypto}}\_{\text{box}}\left( {{\text{m}},{\text{n}},{\text{pk}}2,{\text{sk}}1} \right) $$
(1)

The function input consists of the sender's secret key sk1, the receiver’s public key pk2, plain packet m, and nonce n, and it outputs an authenticated ciphertext c. The crypto_box function automatically handles all necessary conversions and initializations.

crypto_box_open: Upon receiving the message, the recipient uses its secret key "sk2" to decrypt the signature. It then uses the public key of the sender "pk1" to authenticate the message, as represented in the following function:

$$ {\text{m}} = {\text{crypto}}\_{\text{box}}\_{\text{open}}\left( {{\text{c}},{\text{n}},{\text{pk}}1,{\text{sk}}2} \right) $$
(2)

The function input consists of the sender's public key pk1, the receiver’s secret key sk2, ciphertext c, and nonce n, and outputs plaintext m. The crypto_box function automatically handles all necessary conversions and initializations.

crypto_box_keypair: This is used to generate the public keys. It takes the secret key (sk) as input and outputs the public key (pk), as shown below.

$$ {\text{pk}} = {\text{crypto}}\_{\text{box}}\_{\text{keypair}}\left( {{\text{sk}}} \right) $$
(3)

crypto_sign: In some cases, confidentiality is not required. For example, a sender may broadcast a message to many people. Therefore, the library requires only public-key signatures. The sender signs the message “m” using its secret key “sk” to produce the signature “sm,” as follows:

$$ {\text{sm}} = {\text{crypto}}\_{\text{sign}}\left( {{\text{m}},{\text{sk}}} \right) $$
(4)

crypto_sign_open: Upon receiving the message, the receiver authenticates the message using the sender’s public key “pk” and the signature “sm” as shown below:

$$ {\text{m}} = {\text{crypto}}\_{\text{sign}}\_{\text{open}}\left( {{\text{sm}},{\text{pk}}} \right) $$
(5)

crypto_sign_keypair: This works as crypto_box_keypair and is used to generate public key pairs. It takes the secret key (sk) as input and outputs the public key (pk), as shown below.

$$ {\text{pk}} = {\text{crypto}}\_{\text{sign}}\_{\text{keypair}}\left( {{\text{sk}}} \right) $$
(6)

For more information about NaCl, the reader can refer to [36, 37] and for more information about blockchain technology, the reader can refer to [38,39,40,41,42]. As stated in [7], the library does not provide non-repudiation, which is the primary requirement for authentication. Therefore, the next section introduces a solution to address this problem.

2.3 Attack on NaCl library and its security analysis

In the following paragraphs, a scenario attack concerning NaCl is described and the security analysis using BAN logic is conducted. First, the scenario attack is described as follows. Assume that Alice sends the message “M” to Bob after it is signed using the secret key of Alice “skalice,” and then encrypted using the public key of Bob “pkBob”. The message sent to Bob is as follows:

$$ {\text{C}}1 = \left\{ {\left\{ {\text{M}} \right\}{\text{sk}}_{{{\text{alice}}}} } \right\}{\text{pk}}_{{{\text{Bob}}}} $$
(7)

After receiving the message, Bob decrypts the message using his private key and then the public key of Alice. However, Bob can re-encrypt the signed part using Eve’s public key to produce the ciphertext to be sent to Eve:

$$ {\text{C}}2 = \left\{ {\text{M}} \right\}{\text{sk}}_{{{\text{alice}}}} \} {\text{pk}}_{{{\text{Eve}}}} $$
(8)

Finally, Bob sends the ciphertext to Eve as if it comes from Alice. This represents a violation of the nonrepudiation property. To confirm this scenario threat, the analysis is conducted by applying BAN logic to the NaCl library.

NaCl is typically used in blockchain applications. Authentication protocols are fundamental components of the blockchain, and it is necessary to ensure the correctness of these protocols. BAN logic uses logic to define authentication protocols. They convert each message into a logical description in a flawless form. For an effective confirmation of correctness, the certainty (belief) of the sender (signer) and receiver (verifier) should fulfill the procedure objectives. They assume that the verification step of the authentication is accomplished among the signer (Alice) and the receiver (Bob) if there is a message "X" that the receiver Bob is convinced that it has been sent by the sender, Alice. Therefore, the authentication process between Alice and Bob is accomplished if Bob \({|} \equiv\) Alice \({|} \equiv\) X and Bob \({|} \equiv\) X, where the representation \({|} \equiv\) means to believe (or be convinced by) [8]. The fundamental rules of BAN logic are as follows:

The interpretation rule

$$ \frac{Bob| \equiv (Alice|\sim (X,Y))}{{Bob| \equiv (Alice|\sim X),Bob| \equiv (Alice|\sim Y)}} $$
(9)

This rule states that if Bob believes (convinced by the protocol) that Alice generates a message containing both X and Y, he believes that Alice generates each message distinctly.

Message Meaning Rule

$$ \frac{{Bob| \equiv \mathop{\longrightarrow}\limits^{Q - Alice}Alice,Bob \triangleleft [X]_{S - Alice} }}{Bob| \equiv Alice|\sim X},Alice \ne Bob $$
(10)

This rule states that if Bob believes (convinced by the protocol) that QAlice is the public key of Alice and Bob obtains a statement X that is signed by Alice’s secret key SAlice, this indicates that Bob believes that Alice once generated X.

Nonce Verification Rule

$$ \frac{Bob| \equiv \# (X),Bob| \equiv Alice\sim X}{{Bob| \equiv Alice| \equiv X}} $$
(11)

This rule states that if Bob believes (convinced by the protocol) that X is a new statement and Alice once generated X, it believes that Alice believes in X.

Jurisdiction Rule

$$ \frac{Bob| \equiv Alice \Rightarrow X,Bob| \equiv Alice| \equiv X}{{Bob| \equiv X}} $$
(12)

This rule states that if Bob believes (convinced by the protocol) that Alice has jurisdiction (authority) over X and Bob believes that Alice believes in X, Bob believes in X.

Freshness Rule

$$ \frac{{Bob{|} \equiv \# (X)}}{{Bob{|} \equiv \# (X,Y)}} $$
(13)

This rule states that if Bob believes (is convinced by the protocol) in the freshness of X and Y, He believes in the freshness of each message. This study assumes that the statement is transmitted between the sender, Alice, and the receiver, Bob.

Authentication is accomplished between Alice and Bob if the following goals are accomplished:

$$ {\text{Goal}}\,1{:}\quad Bob| \equiv Alice| \equiv M_{i} $$
(14)
$$ {\text{Goal}}\,2{:}\quad Bob| \equiv M_{i} $$
(15)

where Mi characterizes the statement that is sent by Alice

  • Alice first signs the statement (message) “Mi” using the encryption secret key. The result is then encrypted by making use of Bob’s public-key of encryption in order to generate “C1”.

  • Alice transmits C1 = {{{Mi, n}skea}pkeb to Bob, where n is the nonce produced by Alice.

The analysis is completed by assuming the following:

$$ Alice| \equiv \mathop{\longrightarrow}\limits^{pkeb}Bob $$
(16)
$$ Alice| \equiv \mathop{\longrightarrow}\limits^{pkea}Alice $$
(17)
$$ Bob| \equiv \mathop{\longrightarrow}\limits^{pkeb}Bob $$
(18)
$$ Bob| \equiv \mathop{\longrightarrow}\limits^{pkea}Alice $$
(19)
$$ Bob| \equiv Alice \Rightarrow M_{i} $$
(20)
$$ Alice| \equiv \# n $$
(21)
$$ Bob| \equiv \# n $$
(22)

Equation (16) shows that Alice is convinced that pkeb is the public key for encryption. Equation (17) shows that Alice is convinced that pkea is the public key for encryption. Equation (18) indicates that Bob is convinced that pkeb is his public key for encryption: Eq. (19) shows that Bob is convinced that pkea is Alice’s public key for encryption. Subsequently, Eq. (20) shows that Bob is convinced that Alice has (authority) jurisdiction over the sent statement (message). Finally, Eqs. (21) and (22) show that Alice and Bob are convinced that “n” is fresh (n changes every message). Given these assumptions, the messages transmitted during the initial phase were converted into a logical description. Finally, the basic rules of BAN logic were applied to the logical formulas. For more information about the BAN logic, refer to [8, 9]. Using the message C1 = {{{Mi,n}skea}pkeb, Eq. (19) and the message meaning rule (Eq. (10)):

$$ Bob| \equiv Alice|\sim ({\text{m}},M_{i} ) $$
(23)

However, Alice and Bob are convinced that n is fresh (Eqs. (21) and (22)). Thus, by applying the nonce verification rule (Eq. 11), the following equation is obtained:

$$ Bob| \equiv Alice| \equiv M_{i} $$
(24)

According to the jurisdiction rule (Eq. (12)) using Eq. (20), the following result is obtained:

$$ Bob| \equiv M_{i} $$
(25)

The above analysis assumes that Bob is honest. However, as previously mentioned, Bob can re-encrypt the part signed by Alice to produce C2 (Eq. (8)). The following assumptions were made in the logical analysis:

$$ Eve| \equiv \mathop{\longrightarrow}\limits^{pkea}Alice $$
(26)
$$ Eve| \equiv Alice \Rightarrow M_{i} $$
(27)
$$ Alice| \equiv \# n $$
(28)
$$ Eve| \equiv \# n $$
(29)

Using message C2 = {{{Mi,n}skea}pkEve, Eq. (26) and the message meaning rule (Eq. (10)):

$$ Eve| \equiv Alice|\sim ({\text{m}},M_{i} ) $$
(30)

However, Alice and Eve are convinced that n is fresh (Eqs. (28) and (29)). Thus, by applying the nonce verification rule (Eq. 11), the following equation is obtained:

$$ Eve| \equiv Alice| \equiv M_{i} $$
(31)

According to the jurisdiction rule (Eq. (12)) using Eq. (27), the following result is obtained:

$$ Eve| \equiv M_{i} $$
(32)

The resulting goal is not supposed to have been achieved by Alice. Thus, in the case of a dispute, Alice denies sending this message to Eve. The above attack is considered a violation of the authentication service, particularly the non-repudiation service. In the following section, a detailed description of the proposed modification is illustrated to mitigate the aforementioned security attacks.

3 Proposed modification to NaCl library

In the proposed modification, the main focus is on crypto_box and crypto_box_open functions. As mentioned in [7], the NaCl library does not achieve non-repudiation; therefore, these functions must be fixed. To avoid the attack that is described in the previous section, the message after encryption is signed. Thus, Alice sends the following message to Bob: {{{M}skalice}pkBob} skalice. This is illustrated in Fig. 2.

Fig. 2
figure 2

The proposed modification to the NaCl library

Full size image

In the following subsections, a detailed description of the proposed modification is provided, followed by a BAN logic analysis.

3.1 The proposed mitigation

The proposed solution consists of three modules: gen_keypairs, crypto_authenc_sign, and crypto_dec_ver.

gen_keypairs is used to generate public and private keys for Bob to be used to verify the messages received from Alice. In addition, it is used to generate two key pairs for Alice. The first key pair is used in signature, and the latter is used for encryption. The reason separate key pairs are used for signature and encryption is to provide more security. When a private key is compromised for encryption, the attacker can decrypt the transferred messages but cannot use it for signatures. First, genkeypairs generate the signature key pairs of Alice by using crypto_sign_keypair in the NaCl library. It, then, generates Alice’s key pairs for encryption using the crypto_box_keypair in the NaCl library. The last step is to generate the Bob key pairs used for encryption. The pseudocode for this function (gen_keypairs) is depicted in Fig. 3. A flowchart of the gen_keypairs is shown in Fig. 4.

Fig. 3
figure 3

Pseudocode of gen_keypairs function

Full size image
Fig. 4
figure 4

Flowchart of gen_keypairs function

Full size image

In Fig. 3, pksa is the public key for Alice’s signature, sksa is the secret key for Alice’s signature, pkea is the public key for Alice’s encryption, skea is the secret key for Alice’s encryption, pkeb is the public key for Bob’s encryption, and skeb is the secret key for Bob’s encryption.

crypto_authenc_sign is used to perform the cryptographic operations at the sender. First, the sender (Alice) signs the message “M” using her secret key for encryption “skea,” and encrypts the output using the public key for encryption of the receiver (Bob) “pkeb” to produce the output ciphertext “c”. This is performed using crypto_box in the NaCl library. To provide non-repudiation, a second step is performed. In this step, Alice signs the output ciphertext to produce “sm” using its secret signature key “sksa”. This is performed using the crypto_sign function of the NaCl library. The pseudocode for this function (crypto_auth_sign) is depicted in Fig. 5.

crypto_dec_ver is used to perform cryptographic operations at the receiver. First, the receiver (Bob) verifies Alice’s signature using the public key of the signature of Alice “pksa”. This is performed using the crypto_sign_open function of the NaCl library. To retrieve M, Bob decrypts the output using its secret key of encryption “skeb,” and then verifies Alice’s signature using the public key of encryption of Alice “pkea”. This is performed using the crypto_box_open function of the NaCl library. The pseudocode for this function (crypto_dec_ver) is depicted in Fig. 6. A flowchart of both crypto_authen_sign and crypto_dec_ver functions are shown in Figs.7 and 8.

Fig. 5
figure 5

Pseudocode of crypto_authenc_sign function

Full size image
Fig. 6
figure 6

Pseudocode of crypto_dec_ver function

Full size image
Fig. 7
figure 7

Flowchart of crypto_authenc_sign function

Full size image
Fig. 8
figure 8

Flowchart of crypto_dec_ver function

Full size image

3.2 Implementation of the modified NaCl library

The modified NaCl library is implemented using the C programming language and NaCl libraries. The code shown in Fig. 9 is used to compute the secret and public keys of the sender (Alice) for the encryption and signature. In addition, it generates the secret and public keys of the receiver (Bob) for encryption. The program output is as follows:

Fig. 9
figure 9

The C code used in the implementation of gen_keypairs function

Full size image

Step 1 (Fig. 4): Alice’s secret key for encryption:

0x7b,0x31,0x5b,0x94,0xfc,0xa6,0x66,0x85,0x15,0x3d,0xb1,0x5b,0x58,0x89,0xc6,0xa6,0xc,0xa4,0xef,0x5e,0x42,0xb1,0xc7,0xe0,0x78,0xd1,0xd2,0xd4,0x52,0x08,0xa2,0x46

Alice’s public key for encryption:

0xd4,0x12,0x0d,0x05,0x52,0x6d,0x68,0xe4,0xb5,0xb1,0xe6,0x8a,0x9e,0x65,0x76,0x17,0x50,0xb4,0x1d,0x46,0xa9,0x10,0xb8,0xc7,0x15,0x0c,0x9e,0xd8,0xdd,0xed,0xef,0x00

Step 2 (Fig. 4): Alice’s public key for signature:

0x9c,0x75,0xd8,0xb9,0xbe,0x75,0xf9,0x5e,0x91,0xcd,0x2d,0x9b,0x12,0xc8,0x54,0xc7,0x30,0x77,0xb8,0x6f,0x9f,0xca,0x8f,0xf3,0x05,0xe6,0x54,0x33,0xf0,0x78,0xc4,0xc8

Alice’s secret key for signature:

0x08,0x5d,0xbb,0x34,0x00,0xba,0x8c,0x36,0x61,0xb8,0xa9,0x70,0x5c,0xc4,0x7b,0x91,0x6e,0x4c,0x52,0x70,0xf8,0x2a,0x2a,0x52,0x7b,0x1b,0xfd,0x26,0x80,0x41,0x19,0x69,0xb4,0xc9,0xcf,0x43,0x61,0x89,0x30,0xbb,0x60,0x69,0x26,0x86,0xe4,0x1a,0x90,0xfe,0x39,0xd9,0xdb,0xfb,0x8d,0x03,0x92,0xe7,0x9d,0x76,0x52,0x00,0x59,0x8c,0x9a,0xd0

Step 3 (Fig. 4): Bob’s secret key for encryption:

0x51,0x65,0xca,0x35,0x22,0x34,0x6b,0x26,0xee,0xc7,0x64,0xce,0xaa,0x4f,0x2b,0x10,0x21,0x65,0x50,0x3c,0x93,0xcd,0x1f,0x3f,0x7f,0x90,0x8b,0x26,0x1b,0x0e,0x43,0xf9

Bob’s public key for encryption:

0xff,0xca,0x3c,0x2c,0xee,0x6b,0x3e,0x60,0xc6,0x78,0x1c,0x6d,0x30,0xb7,0xe1,0xad,0x0c,0xce,0x12,0x9e,0xb7,0xeb,0x7c,0x2c,0x32,0xa4,0x70,0xf0,0x03,0x71,0x22,0x5a

The code shown in Fig. 10 is used to implement the crypto_authenc_sign function. This function is used by the sender (Alice) to sign the message using its secret key for encryption and then encrypts the output using the public key of encryption of the receiver. Finally, it signs an authenticated message using its secret key for the signature before sending the output to Bob. The generated random message before encryption and signing is as follows:

Fig. 10
figure 10

The C code used in the implementation of crypto_authenc_sign function

Full size image

0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0xe2,0xc3,0x2e,0x3d,0xbd,0x31,0xcc,0x7d,0x4c,0x63

The output is as follows after applying crypto_authenc_sign function:

0xce,0xd8,0x39,0x39,0x1b,0xee,0xb4,0xf2,0xc2,0xd0,0x9d,0xc8,0xa8,0x5d,0xa9,0x70,0x45,0x0f,0xc9,0xbf,0x06,0x1e,0x03,0x27,0x5b,0xc7,0x9c,0xc6,0xed,0x91,0x71,0x15,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x54,0xcc,0x4b,0x48,0x6b,0xaf,0x66,0x8a,0x02,0xe5,0xc0,0x46,0xd4,0x7e,0xfa,0xdd,0x18,0x35,0x0a,0x6a,0x54,0x3e,0x3e,0xad,0xdb,0xca,0x15,0x9a,0x17,0xa8,0x64,0x1b,0x24,0x16,0xd7,0x64,0x4d,0x92,0x37,0xd4,0xbe,0x4a,0xb8,0xfd,0x9d,0xa9,0xe8,0xb6,0xc0,0x93,0x1f,0xe3,0x1c,0xcb,0x23,0xe0,0xfc,0x05

The code shown in Fig. 11 is used to implement the crypto_dec_ver function. This function is used by the receiver (Bob) to verify and retrieve the original message. The program output is as follows after verification and decryption:

Fig. 11
figure 11

The C code used in the implementation of crypto_dec_ver function

Full size image

0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0xe2,0xc3,0x2e,0x3d,0xbd,0x31,0xcc,0x7d,0x4c,0x63

3.3 Logical analysis of the modified NaCl library using BAN logic

In this subsection, the logical analysis of the modified NaCl library is, first, introduced. Burrows et al. [8] introduced a logic analysis method called BAN logic which analyzes the authentication protocols, all primitives' shared keys, and public keys are formalized. BAN logic consists of a set of rules. These rules describe and investigate information exchange protocols. Specifically, BAN logic enables users to define the dependability and security of transmitted information. BAN logic begins with the notion that transmitted information is unprotected and subject to tampering and public observation. BAN logic enables one to simply reason cryptographic protocols using a formal methodology. The foundation of BAN logic is the certainty (belief) of a contended party in the certainty of a formalized prescription. A formalized prescription is incorrect in the general sense of certainty [9]. As mentioned above, authentication protocols are essential components in the blockchain, and it is necessary to ensure the correctness of these protocols. BAN logic uses logic to define authentication protocols. The steps applied to the initial NaCl library were performed for the modified proposal. First, each message was converted into a logical description. For an effective confirmation of correctness, the certainty (belief) of the sender (signer) and receiver (verifier) should fulfill the procedure objectives. BAN logic assumes that the verification step of the authentication is accomplished among the signer (Alice) and the receiver (Bob) if there is a message “X” such that the receiver Bob is convinced that it has been sent by the sender, Alice. Therefore, the authentication process between Alice and Bob is accomplished if Bob \({|} \equiv\) Alice \({|} \equiv\) X and Bob \({|} \equiv\) X, where the representation \({|} \equiv\) means to believe (or be convinced by). Authentication is accomplished between Alice and Bob if the following goals are accomplished:

$$ {\text{Goal}}\,1{:}\quad Bob| \equiv Alice| \equiv M_{i} $$
(33)
$$ {\text{Goal}}\,2{:}\quad Bob| \equiv M_{i} $$
(34)

where Mi characterizes the statement that is sent by Alice

  • Alice first signs the statement (message) “Mi” using the encryption secret-key. Then, the result is encrypted by making use of Bob’s public-key of encryption to generate “c”. Subsequently, c is signed using Alice’s secret signature key.

  • Alice transmits {{{Mi, n}skea}pkeb}sksa to Bob, where n is a nonce produced by Alice.

The analysis is completed by assuming the following:

$$ Alice| \equiv \mathop{\longrightarrow}\limits^{pkeb}Bob $$
(35)
$$ Alice| \equiv \mathop{\longrightarrow}\limits^{pkea}Alice $$
(36)
$$ Alice| \equiv \mathop{\longrightarrow}\limits^{pksa}Alice $$
(37)
$$ Bob| \equiv \mathop{\longrightarrow}\limits^{pkeb}Bob $$
(38)
$$ Bob| \equiv \mathop{\longrightarrow}\limits^{pkea}Alice $$
(39)
$$ Bob| \equiv \mathop{\longrightarrow}\limits^{pksa}Alice $$
(40)
$$ Bob| \equiv Alice \Rightarrow M_{i} $$
(41)
$$ Alice| \equiv \# n $$
(42)
$$ Bob| \equiv \# n $$
(43)

Equation (35) shows that Alice is convinced that pkeb is the public key for encryption. Equation (36) indicates that Alice is convinced that pkea is the public key for encryption. Equation (37) shows that Alice is convinced that pksa is the public key for the signature. Equation (38) demonstrates that Bob is convinced that pkeb is his public key for encryption: Eq. (39) shows that Bob is convinced that pkea is Alice’s public key for encryption. Equation (40) shows that Bob is convinced that pksa is Alice’s public signature key. Subsequently, Eq. (41) shows that Bob is convinced that Alice has (authority) jurisdiction over the sent statement (message). Finally, Eqs. (42) and (43) show that Alice and Bob are convinced that “n” is fresh (n changes with every message). Given these assumptions, the messages transmitted during the initial phase were converted into a logical description. Finally, the basic rules of BAN logic were applied to the logical formulas. For more information about the BAN logic, refer to [8, 9]. Using the message {{{Mi,n}skea}pkeb}sksa, Eq. (40) and the message meaning rule

$$ Bob| \equiv Alice|\sim ({\text{n}},M_{i} ) $$
(44)

However, Alice and Bob are convinced that n is fresh (Eqs. (42) and (43)). Thus, by applying the nonce verification rule, the following is obtained.

$$ Bob| \equiv Alice| \equiv M_{i} $$
(45)

According to the jurisdiction rule using Eq. (41), the following result is obtained:

$$ Bob| \equiv M_{i} $$
(46)

From Eqs. (45) and (46), it is proven that the proposed modification to the NaCl library achieves the objectives of authentication (non-repudiation property) without pitfalls. This is due to the fact that Bob will not be able to re-sign the message rather than Alice. The use of BAN logic proves that the initial NaCl library cannot resist nonrepudiation attacks. On the other hand, the proposed modification fixes this issue and is proven by logical analysis.

4 Performance analysis

In this section, Fig. 12 and Table 1 provide a comparison of the execution times for both communicating parties (sender and receiver) in the case of the original NaCl and modified NaCl. The test environment consists of the following (the processor: 1.6 GHz Dual-Core Intel Core i5, Memory: 8 GB 1600 MHz DDR3, Development language: C, The IDE: Eclipse, the calculated time is in milliseconds (ms), and the calculated message length is in bytes). The modified NaCl consumes more time which is expected as adding a new block of signature will increase the execution time by a range of 50% since the time is calculated for three blocks instead of two. However, the modified NaCl library achieves the non-repudiation security goal, as shown in Table 2. In Table 1, the total time represents the sum of time needed for the cryptographic operations at both the sender and the receiver.

Fig. 12
figure 12

Total computing time at sender and receiver

Full size image
Table 1 Total computing time at sender and receiver
Full size table
Table 2 Security goals in original NaCl and modified NaCl
Full size table

Example of the running code while the message length is 10 bytes:

Alice’s private key for encryption:

0x0b,0xc7,0x3e,0xae,0xfb,0xd5,0x40,0xc2,0x48,0x9f,0xa3,0x62,0xe2,0xb2,0xaa,0xb7,0xc6,0x73,0x42,0xd7,0xd3,0xd3,0xfd,0x12,0x24,0x47,0x64,0xee,0x30,0x7b,0x57,0xbb

 

Alice’s public key for encryption:

0x97,0x69,0x63,0x32,0xa7,0x7c,0xd6,0x4e,0xe4,0xd5,0x4c,0x8c,0xd1,0x2f,0x8d,0x6f,0x8c,0x50,0xd0,0x16,0xd2,0x3c,0xe0,0x7e,0x42,0x33,0xa1,0xf7,0x98,0x25,0x5c,0x47

 

Bob’s private key for decryption:

0xba,0xb3,0x3e,0xdc,0x5f,0x96,0x62,0x88,0xaf,0x07,0xaf,0xa5,0xd3,0x92,0x79,0x0e,0xb6,0x2d,0x7b,0xee,0xa0,0x41,0xc0,0x5b,0x1a,0x0e,0x5f,0x2f,0x76,0x5f,0x2c,0x53

 

Bob’s public key for decryption:

0x25,0x3c,0x87,0x2d,0x02,0x1d,0xd1,0x3c,0x7e,0x0b,0x56,0x30,0xee,0x30,0xe9,0x17,0xce,0xeb,0xa8,0x2c,0x80,0x03,0x30,0x99,0xb2,0xc2,0x53,0x52,0xaa,0xd9,0xd7,0x4d

 

Alice’s public key for signature:

0xdb,0x73,0x6a,0x22,0xf0,0xb1,0xbd,0xad,0xf8,0x8c,0x14,0xe7,0x85,0x85,0x79,0x59,0x57,0xa4,0x45,0x7f,0x7a,0x81,0x0b,0xed,0xc3,0x66,0x1c,0x59,0x94,0x45,0xdd,0xd8

 

Alice’s private key for signature:

0x68,0x17,0xb2,0xcb,0xae,0x41,0xdb,0x57,0xf3,0x64,0x97,0x9b,0x17,0xc0,0x44,0x54,0xe7,0x57,0xc8,0x37,0x79,0x88,0x20,0x00,0xf9,0x08,0x02,0x0b,0x41,0x87,0xc9,0x76,0xf0,0x96,0x14,0x05,0x09,0xbf,0x12,0x61,0x70,0xac,0xfa,0x17,0x7d,0x86,0x1f,0xa9,0xe2,0xf0,0xc9,0x92,0x25,0x5e,0x87,0x5c,0xe2,0x8f,0xe3,0x58,0xad,0xac,0x5a,0x64

 

The generated random message before encryption and signing:

0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x96,0x45,0x46,0xf8,0x7d,0x1c,0xd6,0x3a,0x00

 

At the sender, the consumed time for signing a message (of length 10 bytes) using Alice’s secret key of encryption followed by encryption using Bob’s public key of encryption is 0.115 ms. Then, the time of signing the message using Alice’s secret key of signature is 1.992 ms. The sent message is as follows:

0x82,0x8c,0x49,0x27,0xbe,0xe5,0x59,0xe3,0xca,0xf6,0xc3,0x0c,0x84,0xf6,0x0d,0x19,0xfd,0x49,0xff,0x1e,0x7d,0xcf,0xfc,0xe9,0xa7,0xa5,0xe5,0xf6,0x28,0xae,0x16,0x2c,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0xb0,0x26,0x3b,0xc3,0x69,0x51,0x71,0x8a,0xf1,0x39,0x2f,0xee,0x76,0x2c,0x20,0x6a,0x40,0xe2,0xef,0x52,0x95,0xc1,0xbe,0x4a,0xfc,0xf9,0x1e,0xd6,0x64,0xd3,0xbb,0x7c,0x09,0xb1,0xce,0x3c,0xfd,0x8c,0x1f,0x13,0x75,0xe7,0xd1,0x92,0xf8,0xe2,0x5a,0x5a,0xfd,0x7c,0x12,0x38,0x67,0xda,0xa5,0xb0,0x74,0x08

 

At the receiver, the consumed time for verifying the received message using Alice’s public key of signature is 0.1189 ms. Then, the time of decrypting the message using Bob’s private key and verifying using Alice’s public key of encryption is 5.963000 ms. The output message is:

0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x96,0x45,0x46,0xf8,0x7d,0x1c,0xd6,0x3a,0x00

 

Therefore, the total consumed-time for a message of length 10 bytes at both the sender and the receiver sides is 8.462000 ms.

5 Conclusion and future work

Blockchain provides solutions for several applications. Blockchain has the ability to provide the following characteristics: decentralization, anonymity, privacy, trust, and immutability. This makes it a solution for most inventions in the information and communication technology industry. It is a pillar of the fourth industrial revolution and it is a cryptographically demanding technology that is regarded as one of the most influential topics in academia. The security services that need to be delivered to design a secure application are confidentiality, integrity, authentication, and non-repudiation. These security services are provided using cryptographic algorithms that are the base of Blockchain functionality. Many blockchain platforms currently utilize third-party cryptographic libraries that offer many cryptographic primitives in order to ensure users' protection against cyber-attacks. NaCl and its forks are the most widely used cryptographic libraries. NaCl is known to be one of the best libraries that provide usability property. While NaCl is easy to use and guarantees: confidentiality, integrity, and authenticity, it fails to provide a non-repudiation service. In this paper, an improvement to the blockchain platforms is proposed by enhancing the NaCl library to achieve the non-repudiation property that is widely used in the Blockchain platform. In order to provide the aforementioned security services, NaCl operation is based on signing and encrypting the messages. Therefore, the non-repudiation service is not provided as proved by applying the BAN logic rules to the library. To deliver the non-repudiation property, we propose a solution that is based on adding a signature block. The modified library is analyzed using the BAN logic that proves the correctness of the proposed solution. The analysis suggests that the proposed solution fixes the aforementioned problem. Adding non-repudiation to a blockchain platform keeps law and order when it comes to technology misuse. In this paper, we introduce the modification that adds non-repudiation to blockchain platforms that are built on the NaCl library and its forks and rely on developers to revisit these forks in order to implement the suggested modification. Adding a signature block increases the execution time of the proposed modification since the time is calculated for three blocks instead of two. In order to improve the performance of the implementation of the modified NaCl library, parallelization and pipelining techniques are suggested to be deployed in future work.