#
TSKT-ORAM: A Two-Server k-ary Tree Oblivious RAM without Homomorphic Encryption^{ †}

^{1}

^{2}

^{*}

^{†}

## Abstract

**:**

## 1. Introduction

- Communication efficiency: Under a practical scenario, the communication cost per data query is about 22 blocks–46 blocks when ${2}^{16}\le N\le {2}^{34}$ and the block size $B\ge {N}^{\u03f5}$ bits for some constant $0<\u03f5<1$. In practice, this is lower or comparable to constant communication ORAM constructions C-ORAM and CNE-ORAM. Furthermore, in TSKT-ORAM, there is no server-server communication cost incurred.
- Low access delay: Compared to both the C-ORAM and CNE-ORAM schemes with constant client-server communication cost, TSKT-ORAM has a low access latency.
- Small data block size requirement: Compared to C-ORAM and CNE-ORAM, TSKT-ORAM only requires each data block size $B\ge 20$ KB.
- Constant storage at the client: TSKT-ORAM only requires the client storage to store a constant number of data blocks, while each server needs to store $O(N\xb7B)$ data blocks.
- Low failure probability guarantee: TSKT-ORAM is proven to achieve a ${2}^{-80}$ failure probability given system parameter $k\ge 128$.

## 2. Related Work

#### 2.1. Oblivious RAM

#### 2.2. Private Information Retrieval

#### 2.3. Hybrid ORAM-PIR Designs

#### 2.4. Multi-Server ORAMs

## 3. Problem Definition

- private read $D=(read,i)$;
- private write $(write,i,D)$.

- retrieval from a location, denoted as $D=(read,l)$;
- uploading to a location, denoted as $(write,l,D)$.

**Definition**

**1.**

- security parameter λ;
- two arbitrary equal-length sequences of private data access denoted as $\overrightarrow{x}=\langle $ $(o{p}_{x,1},{i}_{x,1},{D}_{x,1})$, $(o{p}_{x,2},{i}_{x,2},{D}_{x,2})$, ⋯〉 and $\overrightarrow{y}=\langle $ $(o{p}_{y,1},{i}_{y,1},{D}_{y,1})$, $(o{p}_{y,2},{i}_{y,2},{D}_{y,2})$, ⋯〉; and
- two sequences of the client’s access to storage locations that correspond to $\overrightarrow{x}$ and $\overrightarrow{y}$, denoted as $A(\overrightarrow{x})=\langle $ $(o{p}_{x,1}^{\prime},{l}_{x,1},{D}_{x,1}^{\prime})$, $(o{p}_{x,2}^{\prime},{l}_{x,2},{D}_{x,2}^{\prime}),\cdots \rangle $ and $A(\overrightarrow{y})=\langle $ $(o{p}_{y,1}^{\prime},{l}_{y,1},{D}_{y,1}^{\prime})$, $(o{p}_{y,2}^{\prime},{l}_{y,2},{D}_{y,2}^{\prime}),\cdots \rangle $.

- $A(\overrightarrow{x})$ and $A(\overrightarrow{y})$ are computationally indistinguishable; and
- the construction fails with a probability no greater than ${2}^{-\lambda}$.

## 4. Preliminary Construction: TSBT-ORAM

#### 4.1. Storage Organization

#### 4.1.1. Server-Side Storage

#### 4.1.2. Client-Side Storage

#### 4.2. Data Query Process

#### 4.2.1. Client’s Launching of Query

- ${\overrightarrow{Q}}_{0}^{l}$ is generated randomly.
- ${\overrightarrow{Q}}_{1}^{l}$ is first made as a copy of ${\overrightarrow{Q}}_{0}^{l}$. Further, if the query target ${D}_{t}$ is in node ${v}_{l}$ (supposing the offset of ${D}_{t}$ in the block is m), bit m of ${\overrightarrow{Q}}_{1}^{l}$ is flipped.

#### 4.2.2. Servers’ Response to Query

**Definition**

**2.**

#### 4.2.3. Client’s Computation of the Query Result

#### 4.3. Data Eviction Process

#### 4.3.1. Basic Idea

- which real data block is evicted from an evicting node should be hidden;
- which one of two child nodes of an evicting node that receives the evicted real data block should be hidden.

- For each evicting node (e.g., ${v}_{l,x}$), the position where the evicted data block resides should be hidden from any server.
- For each receiving node (e.g., ${v}_{l+1,2x}$), each position that can be used to receive the evicted data block should be selected with an equal probability. In other words, each position of the receiving node should have an equal probability to be written during data eviction. This way, the behavior of a receiving node is independent of whether it receives a real or dummy block.

#### 4.3.2. Oblivious Retrieval of Evicted Data Block

#### 4.3.3. Oblivious Receiving of Evicted Data Block

- Case I: D is a real data block.Without loss of generality, suppose D needs to be evicted to ${v}_{l+1,2x}$; meanwhile, a dummy block ${D}^{\prime}$ needs to be evicted to ${v}_{l+1,2x+1}$ to achieve obliviousness. To reduce the communication cost, D is treated also as the dummy data block ${D}^{\prime}$ when evicted to ${v}_{l+1,2x+1}$.
- Case II: D is a dummy data block. In this case, D is evicted to both ${v}_{l+1,2x}$ and ${v}_{l+1,2x+1}$ as a dummy data block.

- ${P}_{1}$: This part is used by the node to store the latest $clogN$ evicted data blocks, which could be dummy or real, from its parent.
- ${P}_{2}$: This part is used to store each real data block that still remains in the node after more than $clogN$ (dummy or real) blocks have been evicted to the node since the arrival of this real block. Since the number of real data blocks stored in any node is at most $clogN$, this part may contain dummy blocks.
- ${P}_{3}$: This is the storage space other than ${P}_{1}$ and ${P}_{2}$ in the node. This part contains only dummy data blocks.

- If D should be evicted to ${v}_{l+1,2x}$ (i.e., D is assigned to the path passing ${v}_{l+1,2x}$), one position in partition ${P}_{3}$ of node ${v}_{l+1,2x}$ is randomly picked to receive D, and meanwhile, one position in partition ${P}_{2}$ or ${P}_{3}$ of node ${v}_{l+1,2x+1}$ is randomly picked to receive a dummy block.
- Otherwise (i.e., D should be evicted to ${v}_{l+1,2x+1}$), one position in partition ${P}_{3}$ of ${v}_{l+1,2x+1}$ is randomly picked to receive D, while one position in partition ${P}_{2}$ or ${P}_{3}$ of ${v}_{l+1,2x}$ is randomly picked to receive a dummy block.

## 5. Final Construction: TSKT-ORAM

#### 5.1. Storage Organization

- Data array (DA): a data container that stores $3c(k-1)$ data blocks, where c is a system parameter. As c gets larger, the failure probability of the scheme gets smaller, and meanwhile, more storage space gets consumed; hence, an appropriate value should be picked for c. As demonstrated by the security analysis presented later, when $c=4$, the failure probability can be upper-bounded by ${2}^{-\lambda}$. Therefore, we use four as the default value of c.
- Encrypted index table (EI): a table of $3c(k-1)$ entries recording the information for each block stored in the DA. Specifically, each entry is a tuple of format $(ID,lID,bnID)$, which records the following information of each block:
- −
- $ID$: ID of the block;
- −
- $lID$: ID of the leaf k-node to which the block is mapped;
- −
- $bnID$: ID of the b-node (within ${u}_{l,i}$) to which the block logically belongs.

In addition, the EI has a ts field, which stores a time stamp indicating when this k-node was accessed the last time.

#### 5.2. Client-Side Storage

#### 5.3. System Initialization

#### 5.4. Data Query

#### 5.5. Data Eviction

#### 5.5.1. Overview

#### 5.5.2. The Algorithm

- Phase I, selecting b-nodes for inter-k-node eviction: In this phase, the client randomly selects two b-nodes from each layer ${l}^{\prime}\in \{logk-1,2logk-1,\dots ,(\lceil \frac{logN+1}{logk}\rceil -1)\xb7logk-1\}$ on the binary tree; that is, each selected b-node must be on the bottom layer of the binary subtree within a certain non-leaf k-node. Each selected b-node needs to evict a data block to its child nodes, which are in other k-nodes. Hence, the eviction has to be an inter k-node eviction and should be conducted immediately.
- Phase II, conducting delayed intra-k-node evictions: Each inter-k-node eviction planned in the previous phase involves three k-nodes: the k-node that contains the evicting b-node and the two other k-nodes that contain the child b-nodes of the evicting b-node. Before the inter-k-node eviction is executed, we need to make sure that the three involved k-nodes have completed all delayed evictions within them, and this is the purpose of this phase.More specifically, the following three steps should be taken for each k-node, denoted as ${u}_{l,j}$, which is involved in an inter-k-node eviction planned in the previous phase. Note that, here, l denotes the layer of the k-node on the k-ary tree.
- The client downloads the EI of ${u}_{l,i}$, decrypts it and extracts the value of field $ts$.
- The client computes $r=\mathcal{C}-ts$. Note that, $\mathcal{C}$ counts the number of queries issued by the client, which is also the number of eviction processes that have been launched, and $ts$ is the discrete timestamp for the latest access of ${u}_{i,j}$. Hence, r is the number of eviction processes for which ${u}_{l,i}$ may have delayed its intra-k-node evictions.
- The client simulates the r eviction processes to find out and execute the delayed intra-k-node evictions. In particular, for each of the eviction processes:
- (a)
- The client randomly selects two b-nodes from each binary-tree layer ${l}^{\prime}\in \{l\xb7logk,l\xb7logk+1,\dots ,(l+1)\xb7logk-2\}$. Note that layer ${l}^{\prime}$ is not a leaf binary-tree layer within a k-node, and therefore, any b-node selecting from the layer only has child nodes within the same k-node; in other words, the eviction from the selected b-node must be an intra-k-node eviction.
- (b)
- For each previously selected b-node that is within k-node ${u}_{l,i}$, one data block is picked from it, and the $lbID$ field of the block is updated to one of its child nodes that the block can be evicted to; this way, the delayed eviction from the selected b-node is executed.

- After the previous step completes, all the delayed evictions within k-node ${u}_{l,i}$ have been executed. Therefore, the $ts$ field in the EI of ${u}_{l,j}$ is updated to $\mathcal{C}$.

- Phase III, conducting inter-k-node evictions: For each inter-k-node eviction planned in the first phase, its involved k-nodes should have conducted all of their delayed evictions in the second phase. Hence, the planned inter-k-node eviction can be conducted now. Essentially, each selected evicting b-node should evict one of its data blocks from the DA space of its k-node to the DA space of the k-node containing the child b-node that accepts the block, and the eviction should be oblivious. The detail is similar to the oblivious data eviction process in TSBT-ORAM that is elaborated in Section 4.3 and therefore is skipped here.

## 6. Security Analysis

**Lemma**

**1.**

- $3c(k-1)$ data blocks are stored in each DA;
- $k\ge 1.36\lambda +6.44$;
- $c=4$; and
- $\lambda >logN+10$.

**Proof.**

**Lemma**

**2.**

**Proof.**

**Lemma**

**3.**

**Proof.**

**Lemma**

**4.**

**Proof.**

**Theorem**

**1.**

**Proof.**

- According to the query and eviction algorithms, sequences $A(\overrightarrow{x})$ and $A(\overrightarrow{y})$ should have the same format; that is, they contain the same number of observable accesses, and each pair of corresponding accesses has the same access type.
- According to Lemma 2, the sequence of locations (i.e., k-nodes) accessed by each query process is uniformly random and thus independent of the client’s private data request.
- According to Lemma 3, the sequence of locations (i.e., k-nodes) accessed by each eviction process after a query process is also independent of the client’s private data request.

## 7. Comparisons

#### 7.1. Asymptotic Comparisons

#### 7.2. Practical Comparisons

#### 7.2.1. Communication Cost

#### 7.2.2. Computational Cost

#### 7.2.3. Access Delay Comparison

#### 7.2.4. Storage Cost

## 8. Conclusions

## Author Contributions

## Conflicts of Interest

## References

- Islam, M.S.; Kuzu, M.; Kantarcioglu, M.K. Access pattern disclosure on searchable encryption: Ramification, attack and mitigation. In Proceedings of the NDSS Symposium, San Diego, CA, USA, 5–8 February 2012. [Google Scholar]
- Chor, B.; Goldreich, O.; Kushilevitz, E.; Sudan, M. Private information retrieval. In Proceedings of the 36th FOCS 1995, Milwaukee, WI, USA, 23–25 October 1995. [Google Scholar]
- Beimel, A.; Ishai, Y.; Kushilevitz, E.; Raymond, J.F. Breaking the $O({n}^{\frac{1}{2k-1}})$ barrier for information-theoretic private information retrieval. In Proceedings of the 43rd FOCS 2002, Vancouver, BC, Canada, 16–19 November 2002. [Google Scholar]
- Chor, B.; Gilboa, N. Computationally private information retrieval. In Proceedings of the Twenty-Ninth Annual ACM Symposium on Theory of Computing, El Paso, TX, USA, 4–6 May 1997. [Google Scholar]
- Gertner, Y.; Ishai, Y.; Kushilevitz, E.; Malkin, T. Protecting data privacy in private information retrieval schemes. In Proceedings of the 30th Annual ACM Symposium on Theory of Computing, Dallas, TX, USA, 24–26 May 1998. [Google Scholar]
- Goldberg, I. Improving the robustness of private information retrieval. In Proceedings of the IEEE Symposium on Security and Privacy, Berkeley, CA, USA, 20–23 May 2007. [Google Scholar]
- Kushilevitz, E.; Ostrovsky, R. Replication is not needed: Single database, computationally-private information retrieval (extended abstract). In Proceedings of the FOCS 1997, Miami, FL, USA, 19–22 October 1997. [Google Scholar]
- Cachin, C.; Micali, S.; Stadler, M. Computationally private information retrieval with polylogarithmic communication. In Proceedings of the Eurocrypt 1999, Prague, Czech Republic, 2–6 May 1999. [Google Scholar]
- Lipmaa, H. An oblivious transfer protocol with log-squared communication. In Proceedings of the ISC 2005, Berlin, Germany, 9–11 June 2005. [Google Scholar]
- Trostle, J.; Parrish, A. Efficient computationally private information retrieval from anonymity or trapdoor groups. In Information Security; Springer: Heidelberg, Germany, 2011; Volume 6531, pp. 114–128. [Google Scholar]
- Hoffstein, J.; Pipher, J.; Silverman, J.H. NTRU: A ring-based public key cryptosystem. In Algorithmic Number Theory; Springer: Heidelberg, Germany, 1998; Volume 1423, pp. 267–288. [Google Scholar]
- Goldreich, O.; Ostrovsky, R. Software protection and simulation on oblivious RAMs. J. ACM
**1996**, 43, 431–473. [Google Scholar] [CrossRef] - Goodrich, M.T.; Mitzenmacher, M. Mapreduce parallel cuckoo hashing and oblivious RAM simulations. arXiv, 2010; arXiv:1007.1259. [Google Scholar]
- Goodrich, M.T.; Mitzenmacher, M.; Ohrimenko, O.; Tamassia, R. Privacy-preserving group data access via stateless oblivious RAM simulation. In Proceedings of the SODA 2012, Kyoto, Japan, 17–19 January 2012. [Google Scholar]
- Goodrich, M.T.; Mitzenmacher, M. Privacy-preserving access of outsourced data via oblivious RAM simulation. In Proceedings of the ICALP 2011, Zurich, Switzerland, 4–8 July 2011. [Google Scholar]
- Goodrich, M.T.; Mitzenmacher, M.; Ohrimenko, O.; Tamassia, R. Oblivious RAM simulation with efficient worst-case access overhead. In Proceedings of the CCSW 2011, Chicago, IL, USA, 21 October 2011. [Google Scholar]
- Kushilevitz, E.; Lu, S.; Ostrovsky, R. On the (in)security of hash-based oblivious RAM and a new balancing scheme. In Proceedings of the Twenty-Third Annual ACM-SIAM Symposium on Discrete Algorithms, Kyoto, Japan, 17–19 January 2012. [Google Scholar]
- Pinkas, B.; Reinman, T. Oblivious RAM revisited. In Proceedings of the CRYPTO 2010, Santa Barbara, CA, USA, 15–19 August 2010. [Google Scholar]
- Williams, P.; Sion, R. Building castles out of mud: Practical access pattern privacy and correctness on untrusted storage. In Proceedings of the CCS 2008, Alexandria, VA, USA, 27–31 October 2008. [Google Scholar]
- Williams, P.; Sion, R.; Tomescu, A. PrivateFS: A parallel oblivious file system. In Proceedings of the CCS 2012, Releigh, NC, USA, 16–18 October 2012. [Google Scholar]
- Williams, P.; Sion, R.; Tomescu, A. Single round access privacy on outsourced storage. In Proceedings of the CCS 2012, Releigh, NC, USA, 16–18 October 2012. [Google Scholar]
- Shi, E.; Chan, T.H.H.; Stefanov, E.; Li, M. Oblivious RAM with O((logN)
^{3}) worst-case cost. In Proceedings of the ASIACRYPT 2011, Seoul, Korea, 4–8 December 2011. [Google Scholar] - Stefanov, E.; van Dijk, M.; Shi, E.; Fletcher, C.; Ren, L.; Yu, X.; Devadas, S. Path ORAM: An extremely simple oblivious RAM protocol. In Proceedings of the CCS 2013, Berlin, Germany, 4–8 November 2013. [Google Scholar]
- Stefanov, E.; Shi, E. ObliviStore: High performance oblivious cloud storage. In Proceedings of the IEEE Symposium on Security and Privacy, San Francisco, CA, USA, 19–23 May 2013. [Google Scholar]
- Stefanov, E.; Shi, E.; Song, D. Towards practical oblivious RAM. In Proceedings of the NDSS 2011, San Diego, CA, USA, 6–9 February 2011. [Google Scholar]
- Gentry, C.; Goldman, K.; Halevi, S.; Julta, C.; Raykova, M.; Wichs, D. Optimizing ORAM and using it efficiently for secure computation. In Proceedings of the PETS 2013, Bloomington, IN, USA, 10–23 July 2013. [Google Scholar]
- Stefanov, E.; Shi, E. Multi-Cloud Oblivious Storage. In Proceedings of the CCS 2013, Berlin, Germany, 4–8 November 2013. [Google Scholar]
- Wang, X.; Huang, Y.; Chan, T.H.H.; Shelat, A.; Shi, E. SCORAM: Oblivious RAM for secure computations. In Proceedings of the CCS 2014, Scotsdale, AZ, USA, 3–7 November 2014. [Google Scholar]
- Moataz, T.; Mayberry, T.; Blass, E.O. Constant communication ORAM with small blocksize. In Proceedings of the CCS 2015, Denver, CO, USA, 12–16 October 2015. [Google Scholar]
- Moataz, T.; Blass, E.O.; Mayberry, T. Constant Communication ORAM without Encryption. In IACR Cryptology ePrint Archive; International Association for Cryptologic Research: Rüschlikon, Switzerland, 2015. [Google Scholar]
- Lipmaa, H.; Zhang, B. Two new efficient PIR-writing protocols. In Proceedings of the ACNS 2010, Beijing, China, 22–25 June 2010. [Google Scholar]
- Mayberry, T.; Blass, E.O.; Chan, A.H. Efficient private file retrieval by combining ORAM and PIR. In Proceedings of the NDSS 2014, San Diego, CA, USA, 23–26 February 2014. [Google Scholar]
- Lu, S.; Ostrovsky, R. Distributed Oblivious RAM for Secure Two-Party Computation. In IACR Cryptology ePrint Archive 2011/384; International Association for Cryptologic Research: Rüschlikon, Switzerland, 2011. [Google Scholar]
- Freier, A.; Karlton, P.; Kocher, P. The Secure Sockets Layer (SSL) Protocol Version 3.0; RFC 6101; Internet Engineering Task Force (IETF): Fremont, CA, USA, 2011. [Google Scholar]

**Figure 1.**TSBT-oblivious RAM (ORAM)’s server-side storage structure. Circled nodes represent the ones accessed by the client during a query process when the target data block is mapped to leaf node ${v}_{5,10}$.

**Figure 3.**An example TSKT-ORAM scheme with a quaternary-tree storage structure. Each k-node in the physical view (

**a**) corresponds to a two-tier binary subtree shown in the logical view (

**b**). Bold boxes represent the k-nodes accessed when a client queries a target data block stored at k-node ${u}_{3,21}$; that is, nodes ${u}_{0,0}$, ${u}_{1,1}$, ${u}_{2,5}$ and ${u}_{3,21}$ need to be accessed. (

**a**) Quaternary tree: physical view of the server storage; (

**b**) binary tree: logical view of the server storage.

**Figure 4.**An example data eviction process in TSKT-ORAM with a quaternary-tree storage structure. In the logical view (i.e., binary-tree view) of the tree, the root b-node and two b-nodes from each layer, which are circled in the figure, are selected to evict data blocks to their child nodes; thus, the k-nodes that contain these selected b-nodes or their child nodes are also involved in the eviction. With the delay eviction mechanism, not all of these evictions have to be performed immediately. Instead, the evictions that occur within the same k-node, for example, the evictions from ${v}_{4,3}$ to its child nodes and from ${v}_{4,11}$ to its child nodes, occur in k-nodes ${u}_{2,3}$ and ${u}_{2,11}$, respectively, which are highlighted with bold boundaries, can be delayed to reduce the eviction overhead.

**Table 1.**Asymptotic comparisons in terms of client-server communication cost, server-server communication cost, client storage cost, server storage cost and the minimum number of non-colluding servers required. N is the total number of data blocks and B is the size of each block in the unit of bits. $B=O({N}^{\u03f5})$ for some $0<\u03f5<1$. For TSKT-ORAM, $k=O({N}^{\u03f5})$ where $0<\u03f5<1$ and $c=4$. For all tree structure ORAMs, the index table is outsourced to the server with $O(1)$ recursion depth. A scheme marked with the asterisk symbol requires homomorphic encryption.

ORAM | C-SComm.Cost | S-SComm. Cost | Client Stor.Cost | Server Stor. Cost | # of Servers |
---|---|---|---|---|---|

T-ORAM [22] | $O({log}^{2}N\xb7B)$ | N.A. | $O(B)$ | $O(NlogN\xb7B)$ | 1 |

Path ORAM [23] | $O(logN\xb7B)$ | N.A. | $O(logN\xb7B)\xb7\omega (1)$ | $O(N\xb7B)$ | 1 |

* P-PIR [32] | $O(logN\xb7B)$ | N.A. | $O(B)$ | $O(NlogN\xb7B)$ | 1 |

* C-ORAM [29] | $O(B)$ | N.A. | $O(B)$ | $O(N\xb7B)$ | 1 |

MS-ORAM [33] | $O(logN\xb7B)$ | $O({log}^{3}N\xb7B)$ | $O(B)$ | $O(NlogN\xb7B)$ | 2 |

MSS-ORAM [27] | $O(B)$ | $O(logN\xb7B)$ | $O(\sqrt{N}\xb7B)$ | $O(N\xb7B)$ | 2 |

CNE-ORAM [30] | $O(B)$ | N.A. | $O(B)$ | $O(N\xb7B)$ | 4 |

TSKT-ORAM | $O(B)$ | N.A. | $O(B)$ | $O(N\xb7B)$ | 2 |

**Table 2.**Practical comparisons (${2}^{16}\le N\le {2}^{34}$, $B=1$ MB). The communication cost in the table is the client-server communication cost per query. The computational cost is the number of XOR operations needed on the server side.

CNE-ORAM | TSKT-ORAM | |
---|---|---|

Communication Cost | $>40\xb7B$ | $22\xb7B$~$46\xb7B$ |

Computational Cost | $>10(\lambda -10)\xb7logN$ | $18(\lceil \frac{logN+1}{logk}\rceil -1)(k-1)$ |

© 2017 by the authors. Licensee MDPI, Basel, Switzerland. This article is an open access article distributed under the terms and conditions of the Creative Commons Attribution (CC BY) license (http://creativecommons.org/licenses/by/4.0/).

## Share and Cite

**MDPI and ACS Style**

Zhang, J.; Ma, Q.; Zhang, W.; Qiao, D. TSKT-ORAM: A Two-Server *k*-ary Tree Oblivious RAM without Homomorphic Encryption. *Future Internet* **2017**, *9*, 57.
https://doi.org/10.3390/fi9040057

**AMA Style**

Zhang J, Ma Q, Zhang W, Qiao D. TSKT-ORAM: A Two-Server *k*-ary Tree Oblivious RAM without Homomorphic Encryption. *Future Internet*. 2017; 9(4):57.
https://doi.org/10.3390/fi9040057

**Chicago/Turabian Style**

Zhang, Jinsheng, Qiumao Ma, Wensheng Zhang, and Daji Qiao. 2017. "TSKT-ORAM: A Two-Server *k*-ary Tree Oblivious RAM without Homomorphic Encryption" *Future Internet* 9, no. 4: 57.
https://doi.org/10.3390/fi9040057