Abstract

Quantum computers have the potential to solve some difficult mathematical problems efficiently and thus will inevitably exert a more significant impact on the traditional asymmetric cryptography. The National Institute of Standards and Technology (NIST) has opened a formal call for the submission of proposals of quantum-resistant public-key cryptographic algorithms to set the next-generation cryptography standards. Compared to powerful machines with ample amount of hardware resources such as racks of servers and IoT devices, including the massive number of microcontrollers, smart terminals, and sensor nodes with limited computing capacity, should also have some postquantum cryptography features for security and privacy. To ensure the correct execution of encryption algorithms on any platforms, the portability of implementation becomes more important. As distinguished from C/C++, JavaScript is a popular cross-platform language that can be used for the web applications and some hardware platforms directly, and it could be one of the solutions of portability. Therefore, we investigate and implement several recent lattice-based encryption schemes and public-key exchange protocols including Lizard, ring-Lizard, Kyber, Frodo, and NewHope in JavaScript, which are the active candidates of postquantum cryptography due to their applicabilities and efficiencies. We show and compare the performance of our JavaScript implementation on web browsers, embedded device Tessel2, Android phone, and several JavaScript-enabled platforms on PC and Mac. Our work shows that implementing lattice-based cryptography on JavaScript-enabled platforms is achievable and results in desirable portability.

1. Introduction

The rapid development of quantum computing coupled with Shor’s algorithm [1] brings a significant threat to widely used RSA and elliptic curve cryptography (ECC) based on the integer factorization and the discrete logarithm problems. Hence, postquantum cryptography (PQC) has generated a lot of attention among researchers. In the IoT era, tons of things or devices will get connected to the Internet, and they require efficient quantum-resistant approaches to protect the security and privacy. IoT software should work correctly on any architecture; therefore, the portability of software becomes more important. Besides, web browsers serve as an essential platform for web applications and should also have postquantum cryptographic features. As a favorite cross-platform/browser language, JavaScript is one of the solutions of the portability because its performance has improved considerably over the past few years.

Lattice-based cryptography, which is thought to be secure against attacks by quantum computers [2], has gained wide attention and deep researches from academia to industry due to its efficiency and applicability. In recent years, some derivatives of encryption schemes and key exchange protocols of lattice-based cryptography were presented, such as [37]. Implementations of those cryptosystems have been reported in some literature [812]. However, as of now, there is very little research on lattice-based cryptography in JavaScript [13, 14]. Therefore, we would like to investigate the performance of several recent lattice-based cryptosystems on modern computing platforms with JavaScript implementation. We hope to contribute to the practical implementation of PQC.

We implemented and tested five recent lattice-based encryption schemes and public-key exchange protocols on four web browsers, a microcontroller Tessel2, an Android phone Xperia XZ, and other JavaScript-enabled platforms on PC and Mac. We chose an encryption scheme “Lizard” which is based on the learning with errors (LWE) and the learning with rounding (LWR) problems and its ring variant “ring-Lizard” [15], a modulo-LWE based encryption scheme “Kyber” [16], and two quantum secure key exchange protocols “Frodo” [17] and “NewHope” [18], which are based on the LWE problem and the ring-LWE problem, respectively. All the cryptosystems above were implemented in JavaScript. The source code of our implementationcan be found at https://github.com/FuKyuToTo/lattice-based-cryptography.

To provide a fair comparison, we selected the parameters which have 128 bits of postquantum security from the estimation of Jung Hee Cheon et al. [15], Joppe Bos et al. [16, 17], and Erdem Alkim et al. [18], summarized in Table 1. However, there are many different models to estimate the secure parameters of lattice-based cryptography [19]. The analysis of the concrete quantum security levels of those parameters is beyond the scope of this paper, more detailed security estimation algorithms can be found in [2022]. Our parameters should be rescaled after finalizing the secure parameters in NIST PQC standardization project (NIST Postquantum Cryptography Standardization. https://csrc.nist.gov/Projects/Post-Quantum-Cryptography).

The primary reason we chose those five cryptosystems is that they cover a majority of the variants of the LWE-based cryptography, which we will introduce in Section 2. In addition, the parameters and key sizes of those cryptosystems above are not too large and suitable for implementing on web browsers and small devices using JavaScript.

Contributions of this paper can be summarized as follows:(i)We first implement the five lattice-based encryption schemes and key exchange protocols mentioned above using JavaScript. We observe running time of our implementation and find that the performance of the ring-LWE based cryptosystems is much higher than that of others. For example, on the web browsers, the entire calculation process of Kyber and NewHope can be accomplished within milliseconds; even the IoT device Tessel2 is fast enough to perform all of those operations in merely two seconds. Our implementation will be improved further for the NIST PQC standardization project in a future work.(ii)We refactor our implementation to accelerate polynomial operations for ring-LWE based cryptographic algorithms. By implementing the improved number-theoretic transform (NTT) and inverse NTT (see [23, 24]) and reducing the memory overhead of creating temporary instances, we vastly improve the efficiency of polynomial operations compared with our previous work (see [13]).(iii)Our implementation has good portability and scalability. Our JavaScript code can be directly executed on any JavaScript runtime environment without modification. More importantly, by comparing and analyzing these performance difference, we can further improve our implementation for particular platforms.

The rest of this paper is organized as follows. We will explain the notation, give a brief introduction of the mathematical background, and introduce the implemented cryptosystems in Section 2. We will introduce our experimental platforms in Section 3 and describe our implementation techniques in Section 4. We will then present the performance reports on web browsers in Section 5 and on IoT device Tessel2, Android phone, and other platforms in Section 6. Finally, we conclude this paper in Section 7. The appendix section contains an example of the usage of our source code.

2. Lattice-Based Cryptography

In this section, we introduce the relevant mathematical background for the LWE, ring-LWE, and LWR problems and summarize the postquantum cryptographic schemes based on those problems.

2.1. Notation

Let be positive integers; we denote as the set of integers and , as the polynomial rings. Polynomials are denoted by bold italic letters such as , while vectors are denoted by bold small letters such as and matrices and bold large letters such as . For an integer , we define the modulo operation in the range .

2.2. LWE, Ring-LWE, and LWR Problems

Regev proposed the original LWE problem [3] using integer matrix in 2005. Let be positive integers; the search LWE problem is required to find a secret vector by inputting a pair of matrices . The decision LWE problem is to distinguish between a uniformly distributed random vector from and a noisy inner product . Usually, the elements of are randomly selected from , and the so-called error vector is sampled from a target probability distribution . The cryptography based on the LWE problem uses an unusual structure lattice which is called -ary lattice:all the elements of the -ary lattice are obtained using an integer modulo of .

The ring-LWE problem (see [5]) is a variant of Regev’s original LWE problem. is an ideal lattice if each polynomial over has a bijective mapping to an ideal . Given polynomials , , the search version of the ring-LWE problem is to recover the secret , where is chosen uniformly and with an “error’’ sampled from a target probability distribution . The decision ring-LWE problem is similar to the decision LWE problem: given , , we distinguish whether is also chosen uniformly, or there exists a polynomial such that . If there were not any error adding, the LWE and ring-LWE problems would be the simple linear algebra computation and easy to solve. In the worst-case, such LWE and ring-LWE problems can be reduced to the approximate versions of NP-hard shortest vector problem (-SVP) on ideal lattices.

Given a matrix and an inner product with rounding , the LWR problem (see [25]) is to find the vector , where . The information hiding technique or so-called derandomization technique of LWR is different from LWE: each value of the inner product times a rounded value over , instead of adding a random error value; therefore, the error in LWR is deterministic.

2.3. Discrete Gaussian Sampling

For a real , the Gaussian distribution evaluated at is defined by , where the Gaussian parameter . A discrete version of Gaussian distribution over is defined by . In order to find out where to drop the negligible probability of far samples, a tail-cut factor is set to determine the range of sampled values. Choosing a suitable length of the tail-cut factor for a target discrete Gaussian distribution is necessary; otherwise, no sampling algorithm could cover it. The tail-bound is closely related to the maximum statistical distance allowed by the security discrete Gaussian parameters [26, 27]. Note that sampling values from the discrete Gaussian distribution are different to sampling from a normal distribution [28]. We implement modified Knuth-Yao algorithm [27, 29] and modified discrete Ziggurat algorithm [30] to perform such a sampling. The sampling methods will be discussed in Section 4.1.

2.4. Binomial Distribution

The binomial distribution is a discrete probability distribution of the successful number in Bernoulli trials. In this paper, we follow the definition in [16, 18] and denote as the centered binomial distribution for a positive integer :Input: a binary string Output: an integer

For the convenience of calculations, we only sample and compute integers over .

2.5. Lizard and Ring-Lizard

Lizard encryption scheme [15] is parameterized by positive integers and an error rate , where the moduli satisfy . For a real number , we sample values from the distribution such that each value is chosen satisfying and . For an integer , we sample the values from the distribution such that it has exactly nonzero entries in those values.

In key generation, we choose a matrix by sampling column vectors independently from the distribution . Input a matrix whose elements are chosen uniformly from ; then we can compute the matrix , where the error matrix is chosen according to . The secret key is and the public key is the pair . In encryption, by choosing a random vector from the distribution , we compute a pair . Given a message , the cipher text is the pair where and . Lastly, we output the vector in decryption.

Ring-Lizard encryption scheme [15] is a variant of Lizard and based on the hardness of the ring-LWE and the ring-LWR problems. It exploits better key sizes and delivers faster speed of encryption and decryption compared with Lizard. The following procedures define the ring-lizard scheme.

Key Generation. Sample ; choose a “small” random polynomial from and a uniformly random polynomial ; then output the public key and the secret key .

Encryption. Choose a random polynomial from ; given a plaintext , then compute and . The ciphertext is the pair ().

Decryption. Output .

2.6. Kyber

Kyber [16] is a recent module-LWE [31, 32] based CPA- (Chosen Plaintext Attack-) secure encryption scheme and can be applied to build CCA- (Chosen Ciphertext Attack-) secure key encapsulation mechanism (KEM). In this paper, we focus on the former, implementing the Kyber’s public-key encryption scheme. For positive integers and modulus , Kyber needs to generate matrices with small dimension, and each matrix contains several polynomials with coefficients in as its elements. The compression and decompression functions of Kyber are defined as follows:

In key generation, a binary string is chosen uniformly at random from . The matrix can be pregenerated by method SHAKE-128(), and two vectors are sampled from . We compute . The secret key is and the public key is the pair . In encryption, we generate vectors and . Then we obtain the vector from by method . Given a message , the cipher text is the pair , where and . In decryption, we compute and and then output the result .

2.7. Frodo

Frodo [17], the key-exchange protocol based on the LWE problem, has parameters and a real number . The matrix is generated from via a pseudorandom generating function .

In this paper, we focus on the main computation process in Figure 1: we skip the generating function and precompute the matrix . Let , for a matrix , the function and the function are defined as follows, respectively:The reconciliation function is defined in [33]. The output is the closest element to such that or . Alice and Bob can obtain the same shared key via this reconciliation mechanism.

2.8. NewHope

Compared with another ring-LWE based key exchange protocol BCNS [7], NewHope [18] achieves some improvement in the parameters selecting, errors sampling, and reconciliation mechanism. NewHope is a famous ring-LWE based key exchange protocol due to its experiment which is taking place in Google Canary channel; the result shows that NewHope operates well for Google’s postquantum TLS experiment while still being computationally inexpensive (https://security.googleblog.com/2016/07/experimenting-with-post-quantum.html). We would like to know its performance on web browsers or other IoT devices in JavaScript.

Let , , and the modular be positive integers; as with the definition of polynomial ring in Kyber, the keys and errors are all over . A is a component of the exchange and generated from a binary string. It is designed to output a polynomial by SHAKE-128 method. NewHope also needs to sample random values from a binomial distribution . For reconciliation mechanism, we follow the method in [18] and may use non-floating-point arithmetic [34] in our future work. The overview of NewHope is described in Figure 2.

3. Experimental Runtime Environments

3.1. Web Browsers

Implementing postquantum cryptographic primitives on web browsers is necessary and urgent because web browsers are one of the essential platforms for NIST PQC standardization project. In this paper, we choose Mozilla Firefox 57.0.2 as our benchmark platform and propose an open-source project Alea (available URL: https://github.com/nquinlan/better-random-numbers-for-javascript-mirror) to be our secure pseudorandom number generator (PRNG). For comparison, we execute same programs on Google Chrome 63.0.3239.108, Opera 53.0.2907.68, and Microsoft Edge 42.17134.1.0. What we want to see is the performance difference between those web browsers. We will show the running time of several lattice-based cryptosystems on web browsers in Section 5.

3.2. Tessel2

Similar to its old model, Tessel2 is a JavaScript-enabled embedded system with on-board WiFi capabilities designed for IoT developers. Tessel2 features a 580 MHz Mediatek MT7620n router-on-a-chip + 48MHz Atmel SAMD21 coprocessor, running Linux built on OpenWRT with 64MB of DDR2 RAM, and 32MB of Flash memory. Tessel2 is compatible with Node.js and runs JavaScript programs directly for controlling a wide variety IoT modules; it allows developers to easily control modules via a pair of multipurpose ports. Tessel2 is also programmable in other programming languages; however, a part of browser-side JavaScript libraries or objects is not supported.

3.3. Android WebView, PC, and Mac

Android has a built-in browser-like activity which is called WebView. It can be used to display web pages or HTML files as a part of UI. Developers can build a WebView activity to show online content or user data within applications. Android 4.4 has replaced the rendering engine of WebView with Chromium’s V8 engine to deliver improved JavaScript performance. We chose WebView in Android 4.4 (KitKat) to benchmark our JavaScript implementation and ran our implementation on an Android phone Xperia XZ SOV34 (Android version 8.0.0 (Oreo)).

Some operating systems also provide tools to execute plain text files within a shell/script. The Microsoft Windows Script Host (WSH) is described as an administration tool to provide a scripting environment for batch files. The Active Scripting language engines of WSH can interpret and run script files such as JScript or VBScript. Similarly, Mac users can run JavaScript files by using osascript command, which works with AppleScripts or other Open Scripting Architecture (OSA) language scripts on macOS.

In addition, some nonbrowser software such as Node.js or Pacifista also provide JavaScript runtime environment. Like Google Chrome and Android WebView, Node.js is also built on the Google V8 JavaScript engine and offers a rich variety of JavaScript modules which will be of benefit to development. Pacifista is a simple Java-based open-source project that builds a Linux environment and can upgrade OpenSSL using JavaScript; it can be downloaded at https://github.com/ukiuni/pacifista.

Our implementation is measured on a test PC and a MacBook Pro. The test PC has the following specification: CPU: Intel(R) Core(TM) i5-8250U @1.6GHz; 8GB DDR3 RAM; 256GB SSD; Windows 10 build 17134 Home x64. The MacBook Pro (15-inch, 2017 model) features quad-core Intel(R) Core(TM) i7 @2.8GHz, 16GB 2133MHz LPDDR3 memory, and 512GB SSD with macOS High Sierra 10.13.5. Node.js 8.11.2 and Pacifista 0.0.30 are installed on the test PC and MacBook Pro, respectively. We tested our implementation on the four JavaScript run-time environments above. We ran the code on WSH and Node.js for PC and ran on osascript and Pacifista for Mac (see Appendix for the commands).

4. Efficient Algorithms for JavaScript Implementation

4.1. Discrete Gaussian Sampling

Let be the precision of binary expansion of the probabilities and ; there are binary probabilities . A probability matrix is composed of all the computed probabilities, and each column stores one probability. Let be all the rows of ; hence, can be stored as a one-dimensional array for Algorithm 1.

Input: , a probability array
Output: Sample value
1 Let , , ;
2  while  true  do
3 uniformly at random;
4;
5for   down to 0 by 1  do
6;
7if    then
8 if    then   uniformly at random;
9else
10 uniformly at random;
11return  ;
12endif
13if    then return  ;
14else
15;
16 uniformly at random;
17;
18;
19continue
20endif
21endif
22endfor
23;
24 endwhile

With limited computing capacity, the computation of probabilities would become a time-consuming operation for some programming languages or platforms. In general, discrete Gaussian sampling requires a high-precision floating-point operation or large storage requirement [35] to ensure the security level. Inspired by the idea of implementing Knuth-Yao algorithm in FPGAs [27], we modify and implement the algorithm in JavaScript. Moreover, discrete Ziggurat algorithm [30] which allows for a time-memory trade-off has been changed to be portable in chosen platforms. In this case, Knuth-Yao algorithm shows better performance than modified discrete Ziggurat algorithm. In fact, with different features, the performance of those two sampling algorithms varies on different platforms. Therefore, we choose Knuth-Yao algorithm to speed up discrete Gaussian sampling.

4.2. Number Theoretic Transform

NTT is an efficient approach of generalization of fast Fourier transforms (FFT) doing a transform over the finite field instead of the complex number field . It has lower asymptotic complexity for multiplying polynomials with higher degrees.

For being a power of 2 and a prime number with , accepts a polynomial , whose coefficients are in the standard order as input, and outputs another polynomial . can be defined as , where is a -th primitive root of unity in . Similarly, we denote the inverse NTT as that , where , such that the output of satisfies .

We have implemented iterative forward NTT [11, 36] algorithm in our previous works [12, 13]. Both Kyber and NewHope are required to perform polynomial multiplication, and some literature such as [23, 24] provided efficient polynomial multiplication methods to combine bit reversal with computation; hence, in this paper, we follow the state-of-the-art and implement optimized / as shown in Algorithms 2 and 3.

Input: Polynomial , and a LUT in bit-reversed order
Output: Polynomial
1 ;
2  for    to   by   do
3;
4for    to    do
5;
6;
7;
8for    to    do
9;
10;
11;
12;
13endfor
14endfor
15 endfor
16 return  .
Input: Polynomial , and a LUT in bit-reversed order
Output: Polynomial
1  ;
2  for  to by do
3;
4for    to    do
5;
6;
7for    to    do
8;
9;
10;
11;
12endfor
13;
14endfor
15;
16 endfor
17 for    to    do
18;
 19 endfor
20 return  .

Let be a primitive -th root of unity such that . We write two polynomials and . To compute the polynomial multiplication , first we precompute all powers of and and then store powers of and with bit-reversed order in look-up tables , , respectively. So the bit-reverse operation for input polynomial can be merged into precomputation. Then we obtain the negative wrapped convolution , where denotes the point-wise multiplication.

5. Performance on Web Browsers

We implemented three encryption schemes: Lizard, ring-Lizard [15], Kyber [16], and two key exchange protocols: Frodo [17] and NewHope [18] in JavaScript. Again, it should be noted that we mainly focus on the computation process and discrete Gaussian sampling in this paper. Hence, we omitted some steps about the generation, encoding/decoding functions for uniformly chosen public key component or binary seeds. We will go into detail of our implementation performance in this section. The simple usage of our implementation is described in the Appendix.

For comparison, we implemented those five lattice-based cryptosystems corresponding to about 128-bit postquantum security level (see Table 1). Figure 3 shows the performance results of our implementation executed on the Firefox browser. As we expected, the ring-LWE based cryptosystems including Kyber and NewHope are apparently very efficient. The key size of Kyber is smaller than that of Lizard, although Kyber has large moduli. Key generation of Kyber runs over 400 times faster than that of Lizard, but decryption of Lizard is the fastest. Key generation and encryption of ring-Lizard are over 60 and 4 times faster than that of Lizard; however, Kyber is still much more efficient than ring-Lizard. Compared with Frodo, both Alice’s and Bob’s sides of NewHope run over 8 times and 13 times faster, respectively.

For Lizard, we stored the matrices in two-dimensional arrays, to reduce the running time of matrix multiplication due to the row-major order matrix convention in JavaScript. Specifically, we computed the product of a vector with a matrix transpose instead of calculating the matrix-vector product. In addition, the elements of in key generation and in encryption only contain the values from the set ; hence, we could replace integer multiplication with addition and subtraction if multiplicand equals . For ring-Lizard, we computed polynomial multiplication by using Karatsuba algorithm because the moduli of ring-Lizard are powers of 2.

For Kyber, we skipped the generation of binary seeds and polynomials. In key generation and encryption, we precomputed and and sampled the error vectors from a binomial distribution . Each element of matrices and vectors in Kyber is a polynomial over with degree equal to (); hence, NTT can be applied to Kyber to effectively compute polynomial multiplication. Let be positive integers; we assume a matrix is in NTT domain, and the coefficients of each element are in bit-reversed order. In key generation, we performed on error vectors such that the component of public key , only 6 calls of NTT and 3 calls of are necessary if . Similarly, we computed and by invoking 10 times and 4 times in encryption and outputted by invoking 4 times and 1 time in decryption.

For Frodo, we skipped the generation of the from a binary string and precomputed the matrix on both Alice’s and Bob’s sides. There is no problem to perform floating-point arithmetic on the JavaScript-enabled platforms, but we replace floating point arithmetic to integer arithmetic in the rounding/cross-rounding and reconciliation functions considering our follow-up development on memory-constrained devices. To sample the error matrices, we performed our modified Knuth-Yao algorithm as shown in Algorithm 1.

For NewHope, we also performed to speed up the polynomial multiplication which is a bottleneck for ring-LWE based cryptography in JavaScript (e.g., see [13, 14]). In this case, we implemented NewHope following [18] (Section 7.1, Protocol 3) but skipped SHAKE-128 method, hash function SHA3-256, and key encoding/decoding functions. We precomputed the polynomial on both Alice’s and Bob’s sides and sent polynomials directly. Comparing our implementation with the approach in [24], we only computed on Bob’s side so that the computation of has been omitted.

Figure 4 shows the decomposition of computation time of our implementation. Although each implementation technique and performance is different, polynomial and matrix multiplication are still the most time-consuming computation. In Lizard and Frodo, matrix multiplication accounts for at least 70%. In Kyber and NewHope, more than 50% of the running time is spent in . Except for ring-Lizard, the error elements generation including discrete Gaussian sampling and binomial sampling costs little running time in the calculations, accounting about 20% for Frodo and about 10% in Lizard, Kyber, and NewHope; discrete Gaussian sampling accounts for about 50% in key-generation of ring-Lizard.

We executed the same JavaScript programs on other desktop PC browsers including Google Chrome, Opera, and Edge. Taking Kyber and NewHope as examples, Figure 5 shows the running time on those web browsers. It appears that the performance of our implementation executed on both Chrome and Opera is quite similar, and Firefox delivers the better performance than Edge.

6. Performance on Other JavaScript-Enabled Platforms

In this section, we present the implementation performance comparison on IoT device Tessel2, Android phone, Windows, and macOS. Our implementation is designed to be portable and can be executed on those experimental platforms directly without modification. In this case, we precomputed random values generation and discrete Gaussian sampling because of the difficulty of implementing cryptographic secure PRNG in JavaScript on microcontrollers such as Tessel2 (see [13]).

6.1. Tessel2

Figure 6 shows the performance of our implementation executed on Tessel2 (for Lizard, the sizes of keys are too large to be generated on Tessel2). Note that the running time is measured in . We have implemented the ring-LWE based encryption scheme [5] on the old model of Tessel (see [13]). As in our previous work, the performance results achieved on Tessel2 are several orders of magnitude slower than that on web browsers. However, Tessel2 has upgraded hardware specification with better computing capacity. For example, encryption and decryption of Kyber are over 1000 times slower than that of running on Firefox. But the performance of Kyber and NewHope is still unexpectedly high, and the calculation process can be completed within 1 or 2 seconds. Even though the computation of Kyber/NewHope is more complicated than [5], noticeable effects can be achieved in hardware performance and memory costs with our improved implementation.

6.2. Android Phone

WebView is an extension of Android’s View class to display web pages and applications. It provides different performance from other web browsers on Android framework. We ran our implementation on Android phone Xperia XZ au SOV34, which is equipped with Qualcomm Snapdragon 820 MSM8996/2.2GHz DualCore + 1.6GHz DualCore and 3GB RAM. We created an HTML file that includes our JavaScript code and loaded it as a local file into WebView.

Table 2 shows the running time of our implementation on Android phone. From the performance results, it is clear that the performance of ring-LWE based cryptosystems is also acceptable. For encryption schemes, Kyber runs about 3 times faster than ring-Lizard, as well as over 4 times faster than Lizard. For key-exchange protocols, Frodo runs about 10 times slower than NewHope; matrix multiplication accounts for about 80% in Alice’s side and 90% in Bod’s side; the ratio is higher than that of on Firefox. Overall, the running speed achieved on Xperia XZ au SOV34 is at least 5 times slower than that on Firefox.

6.3. Other JavaScript Run-Time Environments on Windows and macOS

For comparison, we investigated the performance of our JavaScript implementation on PC and Mac. It is not difficult to execute our code on other JavaScript run-time environments directly since our implementation has excellent portability. Those environments rely on specific platforms or OS for scripting. For example, JavaScript files (.js type) can be run in GUI mode via WScript.exe and Windows Command Prompt by calling CScript.exe; running Pacifista requires the installation of Java Runtime Environment (JRE). As of now, the performance of postquantum cryptography in JavaScript on those platforms has rarely been studied. To the best of our knowledge, this work is the first. In this case, we used WSH and Node.js on Windows 10 Home and used osascript and Pacifista on macOS High Sierra.

From Tables 3, 4, 5, and 6, we can see that there is a huge performance gap in running the JavaScript code on WSH with other platforms. The running speed of WSH is the slowest; e.g., key generation of Lizard on WSH is about 100 times slower than that on osascript, encryption is over 250 times slower, and decryption is over 150 times slower. Running NewHope on WSH is about 15 times slower than that on Firefox (without consideration of the cost of random values generation).

Node.js delivers almost the best performance for ring-LWE based cryptosystems. For example, Kyber runs about 2 times faster than that on osascript, and ring-Lizard runs over 10 times faster than that on Pacifista. The performance of Node.js is almost the same as on Google Chrome, which also uses Google’s V8 JavaScript engine.

Osascript is also an effective platform for macOS; e.g., running Frodo on osascript is slightly faster than that on Firefox; encryption of ring-Lizard is about 3 times and 5000 times faster than that on Xperia XZ au SOV34 and Tessel2, respectively.

The running speed of Pacifista is less than Node.js and osascript, but still higher than WSH and can be comparable to Android WebView; hence, its performance is acceptable to the developers. The exception for all three encryption schemes is that the running time of key generation is longer than that of encryption.

7. Conclusions

We first implemented five new lattice-based encryption schemes (Lizard, ring-Lizard, Kyber) and key exchange protocols (Frodo, NewHope) in JavaScript and tested their performances on web browsers, Tessel2, Android phone, and other platforms on PC and Mac. Our code can be executed on any JavaScript-enabled platforms since it has good portability. We used NTT to improve the speed of polynomial multiplication and modified Knuth-Yao algorithm for discrete Gaussian sampling. We reported the performance results of our implementation on multiple JavaScript-enabled platforms; by contrast, the ring-LWE based cryptosystems show better performance than others. Our proof-of-concept implementation demonstrates that some of the lattice-based cryptosystems can be implemented efficiently in JavaScript. Hence, our work could be a good reference for lattice-based cryptography in the standardization process of NIST. In our future work, we expect to improve the implementation for particular platforms and investigate more lattice-based public-key encryption schemes and KEM on more platforms for the NIST PQC standardization project.

Appendix

Simple Usage of Our Implementation

We take Lizard as an example for explaining how to use our source code.

Execution

Web Browsers. To run Lizard on web browsers, we create an HTML file which containing necessary contents as in Pseudocode 1.

<!– – lizard.html – –>
<!DOCTYPE html>
<html>
<head><title>Lizard</title>
<meta charset="UTF-8">
<script type="text/javascript"
src="../Utils/prng.js"></script>
<script type="text/javascript"
src="lizard_random_values.js"></script>
<script type="text/javascript"
src="lizard.js"></script>
</head>
<body></body>
</html>

prng.js is our main number generator which includes a fast PRNG algorithm. If Lizard is executed on Opera, we can also use the standard function of ECMAScript Math.random() which is implemented securely (See https://lists.w3.org/Archives/Public/public-webcrypto/2013Jan/0063.html). lizard_random_values.js contains the pregenerated random numbers for testing. The main function of Lizard is testlizard() in lizard.js (see Pseudocode 2).

// the parameters can be changed
var m = 960, n = 608, l = 256, t = 2, p = 256, q = 1024; // h,r,...
function testlizard() //main function
  //...
  randomPlaintext();
  keyGeneration(l,m,n,q);
  encrypt(l,n,p,q);
  decrypt(l,q,t);
  //...
testlizard(); // invoke the main function

Android Phone. We create the Android application package (APK) file using Eclipse Kepler Service Release 2 and Android Development Toolkit (ADT, Version: 23.0.7.2120684). We copy the necessary code from those .js files and paste it into an HTML file for use in our project. This HTML file is placed within the assets folder as a local file. Then we modify the onCreate() function in MainActivity.java (see Pseudocode 3).

//...
import android.app.Activity;
import android.os.Bundle;
import android.webkit.WebView;
public class MainActivity extends Activity
private WebView webview;
@Override
protected void onCreat (Bundle savedInstanceState)
  super.onCreate(savedInstanceState);
  webview = new WebView(this);
  webview.getSettings()
   .setJavaScriptEnabled(true);
  webview.loadUrl
   ("file:///android_asset/lizard.html");
setContentView(webview);
//...

We can export the created .apk file from the bin folder and install it on the Android phone.

Other Platforms. We copy the necessary code and paste it into a .js file. The program can be executed in a command shell; for example, as follows.

Tessel2. It needs to import the interface to Tessel hardware at the top of the .js file:var tessel = require(tessel);//functions

In the command line, enterC:∖tesel2-code>t2 run new_lizard.js

to run Lizard in Tessel2’s RAM.

WSHC:∖new_folder∖Lizard>cscript new_lizard.jsC:∖new_folder∖Lizard>wscript new_lizard.js

Node.jsC:∖new_folder∖Lizard>node new_lizard.js

osascript$ osascript new_lizard.js

Pacifista$ bin/pacifista scripts/new_lizard.js

Display. To measure the running time, we can invoke Date.now() function or new Date().getTime() function, but WSH only supports the latter.

console.log() writes a message to the console. If the code is executed on WSH, we should invoke WScript.Echo() to display the message:function print(message) //WScript.Echo(message);console.log(message);

The result will be outputted as follows (the binary plaintext is generated randomly) (see Pseudocode 4).

Test Lizard:
Input:
m = 960
n = 608
l = 256
t = 2
p = 256
q = 1024
//...
Output:
plaintext =
0,0,1,0,1,0,0,1,1,1,0,0,1,0,0,1,0,1,1,1,1,//…
result =
0,0,1,0,1,0,0,1,1,1,0,0,1,0,0,1,0,1,1,1,1,//…
Success!

Data Availability

The relevant test data used to support the findings of this study are included in the article.

Disclosure

A preliminary version of this paper was presented at the 2018 Symposium on Cryptography and Information Security (SCIS2018) held in Niigata, Japan, on January 25, 2018 [14].

Conflicts of Interest

The authors declare that they have no conflicts of interest.