Page 116 - Kaleidoscope Academic Conference Proceedings 2024

2024 ITU Kaleidoscope Academic Conference

Table 1 – Performance comparison of different algorithms

Algorithm Secret Key Size Public Key Size Ciphertext Size
Our Algorithm 1053 bytes 965 bytes 8799 bytes
Kyber768 2400 bytes 1184 bytes 1088 bytes
Kyber1024 3168 bytes 1568 bytes 1568 bytes
FRODO 11280 bytes 11296 bytes 11288 bytes
NTRU-scheme 1422 bytes 1140 bytes 1281 bytes

without knowledge of the secret key. The sizes of the keys also
plays a vital role in selecting the parameters. Table I shows the Figure 2 – Time taken (in seconds) for encryption and
performance comparison of different algorithms for different decryption for different sizes of plaintext (in KB)
sizes of the secret key, public key, and ciphertexts. It can be
inferred from Table I that the proposed algorithm uses much client-server model. In which the sender and the receiver have
smaller keys (both public and secret), however, ciphertext size been connected to the devices which are indeed connected
is slightly higher than other algorithms excluding FRODO. with the server that has a database. A new user when comes
We have taken the strings of various sizes in kilobytes (KB) of to the server and registers with the help of the algorithm in
different characters in length and ran our algorithm through the backend will be a unique public key and a private key will
various processors. We took the average after “20 iterations” be generated on the database for each of the users. The public
of each test case and found this mean data. We have taken generated is in the form of of vector of vectors having three
256 randomized integers in our secret key and each time vectors of pk_t, pk, a, working as a seed vector that can able
calculated the encryption and decryption timings. The data to generate the whole matrix A with the help of a and pk.
shown in Table II in seconds and we are expecting much Now, for the generation of the cipher text from a plaintext that
better results after further optimization. These are done on a sender (client 1 in fig.) wants to send to the receiver (client
the Ryzen7 4800h processor. 2 in fig.) the encryption algorithm (Algorithm 2) works in
the backend, firstly, it makes an API call to get the public key
Size of plaintext Encryption Decryption
from the database. Using the public key pk of the receiver
1 KB 0.02 sec 0.003 sec
the senders create the cipher text Enc(pk) to get the cipher
4 KB 0.408 sec 0.06 sec
text and send it back to the server and store it in the database
15 KB 1.757 sec 0.25 sec
as in encrypted format. When the server realises there is
31 KB 3.64 sec 0.518 sec
a change it makes a call back to the receiver’s end and the
59 KB 7.44 sec 1.013 sec
API traces the change and reflects it to the receiver’s side.
118 KB 14.3 sec 1.976 sec
Now, since we got the cipher text and now with the help of
Algorithm 3 (Decryption) the previously stored secret key at
Table 2 – Time taken for encryption and decryption
the receiver’s end comes to use to decrypt this cipher text
using Dec(c, sk, sk_t)
Fig. 2 illustrates how the encryption and decryption time gaps
increase, indicating that the ciphertext computational time is The use of the local storage here is to keep the secret keys in it
a little bit longer since we are doing O(n ) for each bit. To with the help of cookies, we parse the sk and sk_t with cookie
simultaneously minimize the size and temporal complexity, tokens to the local storage. After that, we could access that
we are optimizing this timing and attempting to decrease token form the backend and retrieve the secret keys out of that
it to O(log (n) ). Also, we compress each coefficient of which will able to decrypt the incoming messages and show
us in the chat box. Now, since everything is running smoothly
the equations generated by the random seed so that fewer
there is still an issue of storage of ciphertext since the text
bytes are being used in storage. Since the implementation
size is about 0(nm) where the m denotes the number of bits
of the client-server model requires restrictions on the size
of messages sent at one time. That’s why it’s important to per character generally ’7’. So, it’s approx 1800 integers each
compress the coefficients but accordingly, we have to consider taking approx 8-12 bytes making an overall space of 7.2 KB
the parameters carefully so that security would not be affected. and for 250 such characters which is the current character
limit for our algorithm implementation in the chat server, it
comes to approx 1.8 MB which turns out to be a lot as of now.
6. IMPLEMENTATION
So, to reduce this we are implementing a space size
This section provides complete structure of our model of algorithm which would encrypt multibit at the same time. To
end-to-end (E2E) communication channel via client-server reduce space it would also make the runtime lesser.
model and how we implemented it in the device. Along Further work on user and software interfaces and key
with the reference implementation of the algorithm and the management systems may be necessary for encryption using
required encoding of the algorithm in the PKE system for the QKD devices to guarantee long-term access to encrypted
E2E channel. messages and also asynchronicity. The demand is presently
As shown in Fig. 3, the implementation was done on a not being met by the key rates, particularly when it comes

– 72 –