# Potential of Homomorphic Encryption for Cloud Computing Use Cases in Manufacturing
## 3 Encryption for Cloud Computing in Manufacturing
### Experimental Comparison of Classic and Homomorphic Encryption
#### 3.3.1 Experimental Setup  
To pursue the described aim of comparing homomorphic and classic encryption for different scenarios, three different analysis scenarios are defined that could be applicable in manufacturing. These scenarios differ regarding their calculation operation as follows, as summarized in Table 2:  
* _Addition_ (e.g., daily consumption of cooling lubricant on one machine),
* _Multiplication_ (e.g., electricity costs of the manufacturing line in a certain interval),
* _Average_ (e.g., average temperature in a cold store over a certain time interval).  
Depending on the need for partially (only one operator, with unlimited calculations), somewhat (both operators, with limited calculations), or fully homomorphic encryption (both operators, with unlimited calculations), different homomorphic encryption methods were applied, as summarized in Table 2. The Paillier method was used for partially homomorphic encryption, implemented via a Python library. This is a probabilistic asymmetric method whose security is based on the mathematical n-th residual problem. As is usual for asymmetric methods, the cryptosystem consists of an algorithm for key generation and the  
Figure 4: Potential of HE for cloud computing in production.  
encryption and decryption algorithm. The Paillier system has an additive homomorphic property and is used, for example, in electronic voting systems [18, 36, 37]. The Brakerski-Fan-Vercauteren (BFV) method was used for somewhat homomorphic encryption. BFV is a homomorphic encryption scheme that uses the ring learning with error (RLWE) problem and encrypts data in ring polynomial form. The encryption and decryption in this scheme involve high-degree polynomial multiplication [38]. The Cheon-Kim-Kim-Song (CKKS) method was used for fully homomorphic encryption [39]. CKKS is also based on the RLWE assumption and does not require expensive bootstrapping operations. Plaintext messages are encoded and encrypted into vectors, and all computations are vectorized. Both BFV and CKKS were implemented over the Pyfhel Library.  
As classic encryption has no limitation regarding calculation operations, the compared classic encryption technology was the same for each scenario (Symmetric Ferret Procedure, Python Ferret Library).  
All calculations were performed on Linux Debian 64 bit and an AMD Ryzen 7 3700X 8 core 3600 MHz processor. For each scenario, sample datasets with 6048 values were generated and used for the calculations. The used dataset and the GitLab repository are provided in the data availability statement at the end of this paper.  
For the experimental comparison, our main condition was that the data are secure over the whole data lifecycle. As explained in Section 3.2.1, this is given for homomorphic encryption. For classic encryption, however, this is only given if the data are analyzed on premise. Thus, during our experiment, we assumed that the database was downloaded for the calculations to not reveal data in the cloud. This refers to the comparison scenario of Scenario 2 Variant 2, as shown in Figure 3.  
Since all calculation were executed on the same hardware, cloud usage was simulated by setting a latency of 20 ms for each data transfer that would have taken place between the company's on-premise IT and the cloud (this only affects the comparison of data transfer, see Section 3.3.2 and Figure 5).