Data Encryption Impact on Performance in Oracle and Database Storage by Student’s Name Abstract As the volume of data and information received and sent electronically grows in different small and medium-sized businesses, corporations and organisations, the use of the Cloud Database as a service is becoming increasingly common in the global business world. The operating … Continue reading “Performance in Oracle and Database Storage | My Assignment Tutor”
Data Encryption Impact on Performance in Oracle and Database Storage by Student’s Name Abstract As the volume of data and information received and sent electronically grows in different small and medium-sized businesses, corporations and organisations, the use of the Cloud Database as a service is becoming increasingly common in the global business world. The operating responsibility faced by Transactional Database Systems (TDS) users, such as deployment, provisioning, performance tuning, scalability, safety and protection, backup and access control, is passed to the service provider/operator by the Database as a service provider. Which provides lower hardware and technological costs, remote internet connections to databases and stable applications. Today, data security is a necessity with more security standards and regulations in ensuring data safety and ensuring privacy. With enhanced unauthorized access to sensitive data in the cloud, this paper introduces encryption strategies that offer strong protection against threats using Straightforward Data Encryption (TDE). To secure the integrity of the cloud servers, TDE is used to transparently encrypt and protect data on rest, hard disk, transit and backup media. TDE is reliable, fast and offers a high degree of security for columns, tables and tables for data that need protection. This research compares and show the performance of an oracle database with TDE and that without TDE. Keywords: Database encryption, Administrative Key Management, Performance Overhead, Transparent Data Encryption (TDE), TDE Tablespace Table of Contents Chapter 1 – Introduction. 4 1.1 Introduction. 4 1.2 Problem Statement. 6 1.3 Research Gaps and Related Work. 6 Chapter 2 – Literature Review.. 8 2.1 Introduction. 8 2.2 Oracle Database Encryption. 10 2.3 Chapter Summary. 15 Chapter 3 – Methodology. 17 3.1 Introduction. 17 3.2 Methods. 17 3.3 Encrypting the Oracle Database Engine. 17 3.4 Results. 19 3.5 Discussion. 24 Reference List 29 Data Encryption Impact on Performance in Oracle and Database Storage Chapter 1 – Introduction 1.1 Introduction The goal of this paper is to build a theoretical framework that will be used for benchmarking Transparent Data Encryption (TDE) systems. The current chapter discusses the idea of TDE and how this technology is of critical significance today. This is done by briefly introducing the relevant literature, which contributes to the recognition of the research void that the current research effort aims to solve. Finally, the contribution of the present analysis, along with the constraints imposed, is briefly addressed. Data encryption is the translation of data into another form or code so that the user that has access to a secret key or a password can read the data. In most cases, the encrypted data is often referred to as ciphertext while the unencrypted data are known as plain text. At present, encryption is considered one of the most popular and effective data security method that is used by various organizations. At current, there is a rapid increase in available information and data. This increment of data has given rise to the need for data storage. Storing the data is one of the primary concerns which every user must be aware of. The users can privately store their data on local storage or can use various online cloud providers to store their data. However, there is risk or threat while storing the data as hackers and third parties can easily hack or steal this data. As mentioned by Zhang et al., 2019, the data may contain personal and secret information related to the users like their name, home address, bank details, medication status, and some other vital information that should be kept secret. One of the basic methods of attack upon the encryption is brute force or trying random keys till the main one is found. The length of the key often determines the available keys and mostly affects the plausibility of the attacks. The encryption strength is directly related or proportional to the key size. With the increment of key size, the resource requirement also increases that are to be used for computation. An alternate method for breaking down the cypher is side-channel attacks and certain cryptanalysis. It is to be noted that these attacks mostly succeed if an error is present or available in the system design during the execution. To prevent or reduce this data theft, the user needs to make use of certain encryption techniques that can be used in enhancing data security. With the data encryption, the user should be able to translate their data in some form of code. These codes can be deciphered or retranslated back to their original form only through the usage of a secret key or a password to which only the user has access. From its nomenclature, the secret key is the only “key” that translates the encoded cipher text into plain text. Any user without the secret key cannot be able to decode the encrypted data files. The stored information can only be revealed to users with the secret key. The user can share this password and the private key with the ones they trust. Through this way unauthorized persons or third parties will be unable to get access to the personal information and the data security of the original user will enhance dramatically (Wiese et al. 2020). Database users such as DB Admins, Parametric End Users like Data Clerks should be informed of the about the idea of encrypting data to enhance data security. Uninformed database users can be a form of vulnerability to an organization’s database since they can be lured to expose passwords and secret keys. This can possibly give chance to attackers to compromise with the organization’s data. It is to be noted that organizations or companies are not fully immune to security breaches. The proper implementation of the data encryption techniques is possibly the safest way for protecting the confidential and secret information related to the organizations and their client base (Rafique et al. 2017). This is one of the main or primary reasons why all the documents which the users send or receive over the internet must be encrypted. The sensitive data must be protected at all costs. It can be achieved if a proper data implementation technique is implemented which can be used in protecting the sensitive data that is utilized over the internet. In this project, I am going to analyze the data encryption technique and display this encryption in oracle. 1.2 Problem Statement Security has been a top priority for organizations today. Encryption at rest is a part of the solution, but not a large part of it. Network encryption is another piece, but this is just a little piece. These and other components do not work well together; they need to unencrypt and encrypt data while passing across layers, leaving transparent copies that cause complicated technical problems to track and identify an intrusion. The state-of-the-art best-practice technology paradigm is end-to-end encryption architecture. The program deploys the application-driven encryption services in the main memory. These services allow end-to-end encryption, from the database to middleware, locally and across networks, and private and hybrid clouds. Oracle and others are proposing such options. This research is focused on benchmarks developed and run by Oracle. 1.3 Research Gaps and Related Work As discussed above, we are living in the information age. Data is distributed and processed in different means that expand the surface of the attack for future hackers. The security of information records is thus of vital significance. The relevance of the field has gained the interest of both academia and business. Several field research papers are briefly listed in this section. TDE is a technology with a range of modifications and implementations. Owing to the restricted time available to the current research study, a range of restrictions need to be implemented. The most important of this is that the methodology developed focuses only on the efficiency of TDE systems and the additional computational pressure added. However, protection is a key feature of such systems, and its power, along with the possible weaknesses of TDE implementations, is a significant concern that requires further study. Despite this, the security strength of the TDE systems is not beyond the scope of the current project and is left to future work. Chapter 2 – Literature Review 2.1 Although there exists ample literature, scholarly articles and varied information sources corresponding technologies on cloud databases security and data encryption few focus on making deep aesthetic examination of the performance such technologies. Many researchers are inclined towards analysis of cryptographic algorithms, cloud systems architecture and overview of emerging cloud security technologies. There is therefore limited literature sources which study the performance of such cryptographic security technologies in a practical setting. There are few scholarly works that detail on the performance of such enterprise technologies as Oracle’s Transparent Data Encryption. Apparently, this paper takes advantage of the void and goes explicit at assessing from the richness of works associated with DBMSs, cloud systems security, cloud data encryption, Oracle cloud systems and Oracle TDE to converge the information towards establishing and finally accomplishing its study of the impact of encryption on the performance of Oracle Database. In establishing the appropriate material for this literature review, the author of this paper applied the snowball approach. Initially the sampling began with more than 40 sources. These sources a collection of course books, scholarly articles, tech summit publications (i.e IEEE, ACM, ISI, Scopus) and Oracle Documents. The next level of snowballing eliminated some of the sources to remain with those that would be relevant to the topic in research. This was done through selection and filtering to determine the most informative sources. At this point, this presentation finds it fitting to applaud and recommend snowballing as an ideal method of resources selections. This review begins from a broadened revelation and narrows to the main discussion as the flow processes. 2.2 Introduction Organizations rely on distributed information systems to enhance their efficiency and productivity. However, due to the ever-growing technology, organizations become more prone to security threats. Database systems are the distributed information system’s integral component, which allows the whole system to function. Many organizations implement database systems as a powerful technology for managing data for daily operation and decision making. Since the data in the database get shared among multiple users, it is vital to ensure the safety of the stored data despite unauthorized access or system crushes. The data stored might be sensitive and confidential, thus the need for these organizations to improve their security. Encryption is one of the most effective techniques for securing the database. Since the upsurge of networks and especially the cloud technology, various cryptographic solutions have been built for the security of cloud systems. Transparent Data Encryption is one of the most notable encryption technology built specially for cloud data systems. TDE is a technology born to secure data maintained in databases. The concept behind it, which also describes the keyword “Transparent,” is to protect data stored without the user being aware of the security processes involved (Mattsson, 2017). Therefore, to gain data security, they need to be encrypted while they remain in the archive. Also, the encryption keys must be handled by the TDE framework to make the whole operation visible to the data user. Last but not least, the TDE device has to execute real-time I/O data encryption, as well as database log files, otherwise, the operation will be detectable by the user. TDE transparently encrypts the rest data in Oracle Databases. Stops unwanted attempts by the operating system to access database data contained in archives, without changing how programs access SQL data. TDE is capable of encrypting whole program tablespaces or unique critical columns. Tablespace encryption is helpful when you want to encrypt all data, regardless of the column. With tablespace encryption, you do not need to remember the features of columns, such as indexes and limitations. Column encryption is helpful in situations when only several critical columns have to be encrypted (Mattsson, 2017). The next section of this report implements database encryption using TDE in Oracle 12c Database and evaluates its performance as well as some database encryption trade-offs. TDE is completely implemented in the Oracle database. Encrypted data stays encrypted in the database, whether it’s in tablespace storage archives, temporary tablespaces, tablespaces, or other files that Oracle Database 12c depends on, for example, re-encrypted logs. TDE can also encrypt complete archive copies and export storage pumps. Oracle Recovery Manager (RMAN) and Data Pump Export/Import both combine TDE encryption to move through previously encrypted data (Oracle Database, 2016). TDE is a cryptographic method in the Oracle database used to encrypt data contained in a table column or table field. It preserves data contained in database files (DBF) by encrypting it in case the file is compromised or hacked. Transparent Data Encryption Tablespace Encryption has no overhead associated efficiency. The real effect of performance on applications can differ. TDE column encryption only impacts efficiency when data is extracted from or placed into an encrypted column. There is no drop in efficiency for operations involving unencrypted columns, except though these columns are in a table containing encrypted columns. Accessing data in encrypted columns requires no overhead efficiency, and the exact overhead you observe can differ. Total overhead efficiency depends on the number of encrypted columns and their frequency of entry (Oracle Database, 2016). For Oracle Database 12c systems with modern hardware, the overhead efficiency of TDE is usually very low and not visible to end-users. Oracle databases are exposed to significant cybersecurity risks, which pose threats to unauthorized disclosure, modification, or loss of data. Transparent data encryption in Oracle databases creates a 2 – 4% performance overhead (Moulianitakis and Asimakopoulos, 2019). Although the performance impact of encryption appears negligible, it is more significant on other system operations relative to the acquired level of protection. Transparent data encryption in Oracle databases protects only the stored data hence leaving the data held in memory exposed to lose and damage threats. SQL servers are designed to automatically reference data that is accessed regularly in the buffer pool hence provisioning an Oracle database with adequate buffer memory minimizes the need to access the disk hence minimizing the performance impacts of encryption (Moulianitakis and Asimakopoulos, 2019). However, queries that have not been accessed for a while would require data retrieval from the database hence increasing performance overhead from encryption. Performance overheads due to encryption are also experienced in the transactions recorded in the logfile, index rebuild operations, and backup processes depending on the interactions between the database application and data (Gottel et al., 2018). If a certain system application performs more write than reading operations in a database, data encryption results in higher performance overhead. Data encryption is a highly CPU intensive process as it occurs at the database level and performed as an Input/Output operation. High Input/Output and CPU load on Oracle database servers impact performance by up to 28% compared to servers with low CPU load and I/O (Gottel et al., 2018). Data encryption takes place at the file level as encryption pads transaction logs and not database files. As a result, the performance impact of encryption on server optimization is 20% higher compared to when there is no encryption (Gottel et al., 2018). Data encryption negatively affects query optimizer functionality in Oracle databases due to changes in the column values to varbinary and converted back to the original value after decryption. An increase in the CPU load and reduction in the I/O writes significantly slows down transaction throughput. When data is encrypted, oracle servers process an average of 81 transactions per second, which is significantly lower compared to 121 transactions per second when data is unencrypted (Elovici et al., 2018). Encryption also compresses data hence creating the need for fewer disk writes and more CPU cycles. User CPU in Oracle databases increases to 80 from 46 when the data is encrypted (Elovici et al., 2018). The following table shows the performance impacts of encryption in Oracle databases; Oracle TDEOracle PlainLocal Oracle TDELocal Oracle PlainFile SystemVxFSVxFSNTFSNTFSCache Hit %77.5769.4742.2333.79No. of Threads858544Execution Time (Seconds)372249380245Transactions Per Second811210.531.22Total transactions30,00030,000200200CPU u/s/i %80/5/1546/10/444322Data DatafileRead23,52024,030 Write27,72051,300 Blocks853,8601,402,110 Index DatafileRead27,72034,020 Write64,26077,220 Blocks1,743,8401,980,720 Oracle IORead4,695,0394,803,706 Write107,460171,687 The results for the first three columns were obtained from :Table Source: http://www.dba-oracle.com/t_benchmark_tde_transparent_data_encryption.htm Given that the local database 18c Express was analyzed on an environment that was not controlled, it was not possible to get some tests. However, the tests that were investigated shown similar trend and consistency with the table columns that were obtained from an online source. Only 200 records were used to perform the tests rather than 30,000 records that the author used. 2.2 Oracle Database Encryption The performance impacts of encryption on Oracle databases vary with the applications used to retrieve data. When an Oracle database is encrypted using the Transparent Data Encryption (TDE) method, a decline in performance occurs when a retrieval or insertion transaction is performed on an encrypted column (Hue, 2017). Database performance in unencrypted TDE columns is not affected even when located in the same table with encrypted columns, which exhibit performance overhead. The degree of performance overhead in encrypted columns in Oracle databases varies with factors such as the access frequency and the number of encrypted columns, the volume of encrypted data, and the frequency of updating the encrypted values. Performance overhead in Oracle databases can be addressed by encrypting only columns that contain sensitive data. Additionally, database performance can be increased by assigning each table with encrypted data decryption keys to optimizing response time during the transaction (Hue, 2017). Encryption in an Oracle database creates performance overhead by making some tables temporarily inaccessible when a query command is executed. Enabling encryption on large tables in a database necessitates increasing the redo log size to optimize the performance of the search, indexing, and updating operations. The performance impact of encryption on Oracle databases varies with the mode of encryption. For instance, TDE column encryption results in storage overhead while TDE tablespace encryption does not cause storage overhead in Oracle databases. Encrypted data columns in a database require more storage space in addition to plaintext data. Transparent data encryption amplifies the encrypted data multiplying by 16 bytes such that encrypting a 9-byte credit card number would require additional 7 bytes (Natarajan and Shaik, 2020). Additionally, each encrypted value in a data set are subjected to a 20-byte security check hence every encrypted value has a maximum of 52 bytes in storage (Natarajan and Shaik, 2020). This results in a disruption of database functions such as merging datasets, indexing, and search due to the limited storage memory to process the functions. There are three significant encryption dimensions designed with the substantial objective of protecting databases. According to Mattsson (2005), one of these dimensions is the granularity of the data expected to be either encrypted or decrypted. This dimension has three powerful alternatives, which are the page, the row, and the field. Mattsson (2005) further explains that this field is the best alternative of the three since it can minimize encrypted data. However, he argues that implementing this alternative will require embedding encryption within database servers or relational servers, which may sometimes be challenging. The hardware and software level of implementing encryption algorithms is the second dimension of data encryption. Mattsson (2005) asserts that this choice significantly impacts performance. Encryption based on hardware level of encryption algorithm implementation within relational databases consists of a substantial encryption operation’s startup cost. Each model has distinct encryption offloading abilities, tuning prospects, and operational performance. Encryption service location is the third dimension of database encryption w entails attached network service, remote procedure network or service, and local service. This dimension determines both the work needed to be accomplished from an integration perspective and substantially impacts the overall security model. The less time it takes to encrypt the data, the more it gets secured from unauthorized access and another related attack. Data security is associated with four significant attributes: data integrity, confidentiality, non-repudiation, and authentication. According to Freeman and Miller (1999), confidentiality is critical every time the data is stored or transmitted to protect it from unauthorized access. There are two subtotal forms of data encryption schemes used to enhance data confidentiality: secret and public-key cryptography. Standard algorithms used in secret-key cryptography are RC5, IDEA, TDES, DES, and AES-256/AES-512, and users need to share the private key. Secret-key cryptography is also easy and fast to perform and only uses one key to encrypt and decrypt the data. Public-key cryptography uses different keys while encrypting the data and a distinct key for decrypting the data. The most common algorithm used in this type of cryptography is RSA. Freeman and Miller (1999) argue that although public-key cryptography is essential in enhancing data confidentiality, it is complicated and slow in its performance. A database needs to have user authentication to restrict who access the stored data. Freeman and Miller (1999) claim that using a digital signature or a keyed-hash provides strong user authentication. Data integrity is essential, especially during the transmission of data via cloud computing services. Using a digital signature or a keyed hash that authenticates the user ensures the stored and transmitted data is not tampered with. When the confirmation receipt and transmission of information are required, Non-repudiation becomes essential. For example, in Electronic stock trading, if the stock price drops, an individual initiating the trade may attempt to deny performing the transaction. If they do not make the trade, the broker may try to reject the transaction. Non-repudiation uses a two-way transaction. One user has to send some information secured by a digital signature, and then the receiver has to return a sighed receipt of the data transmitted. However, it does not use the keyed-hash authentication pattern; instead, it uses the cryptographic signature via the private key. There are three substantial levels of encryption. According to Bouganim and Guo (2009) and Mattsson (2005), these levels are database encryption level, storage encryption level, and application encryption level. The storage encryption level entails encrypting data present in a storage sub-system, and as a result, the stored data gets protected from vulnerabilities such as storage media theft. Bouganim and Guo (2009) delineate that this type of encryption level is best compatible with encrypting entire directories or files in the context of an operating system. From a database point of view, this encryption level has the benefit of transparency, and as a result, any alteration from the existing application gets restricted. It implies that an individual without the privilege to change the existing application cannot alter them. However, the storage system is not aware of database structures and objects, and as a result, it makes it impossible to relate user privileges with the encryption strategy (Freeman & Miller, 1999; Bouganim & Guo, 2009). For example, specific users using a distinct encryption key. The database level of encryption enhances the security of data when inserting or retrieving it from the database. At this encryption level, the encryption stratagem makes a significant portion of designing the database and interrelates with user treats and the data’s sensitivity (Bouganim & Guo, 2009). This encryption level enables selective encryption at innumerable granularities such as rows, columns, and tables. However, it can degrade the DBMS performance despite its functionalities since encryption restricts using the index on encrypted data. Indexing encrypted data is ineffective unless using the precise mode of operations or encryption algorithms. Application encryption level moves the process of encryption and decryption to the application responsible for generating the data. For this reason, the data is encrypted when storing and retrieving it. Solutions offered by the databases encryption gets categorized based on three essential conditions. Elovici, Gudes, Shmueli, and Vaisenberg (2014) reveal the three conditions: the level of encryption granularity, the database server trust, and the layer in which the encryption occurs. The database server’s trust level ranges from full mistrust and partial trust to complete belief (Retinger, 2019). When the database level of trust is complete, it implies that it can perform all its operations and functionalities without being vulnerable to any existing threat. When the database server gets trusted partially, the DBMS software and database server get trusted except for its secondary storage. The most popular encryption granularities level entails table, page, record, and cell. Finer encryption granularities have various benefits compared to coarser ones (Yan, 2019). It enables an individual to encrypt only the most sensitive data and leave the insensitive ones unencrypted. While performing query encryption, only the most sensitive data is encrypted or decrypted. It also allows using a different key to encrypt some parts of the data. However, Elovici et al. (2014) affirm that failure to implement fine encryption granularities wisely leads to unauthorized modification vulnerabilities and information leakage compared to coarse encryption granularities. For instance, if a company does not adhere to all the rules and procedures of using fine encryption granularities to secure its databases, its data may get jeopardized and vulnerable to leaking. 2.3 Chapter Summary In summing up this section, the review has presented the background, meaning, importance and basic logic of encryption; an approach used to employ security to modern Database Management Systems. With the evolution of information technology, data and information has become a very vital component in companies, organizations and enterprises operating in the modern-day setting. Companies hold personal information which require high-level security to block unauthorized access to such important and fragile data. Due to this cause, operators in the tech industry have been developing generic technologies to secure data and information both at rest and in motion. The idea of encoding data into a form that can only be deciphered to the intended people has been applied widely to secure databases. One of the iconic technologies developed to secure data in cloud systems as reviewed above is Transparent Data Encryption. Oracle applied this technology to their DBMS as from Oracle12c release. This review established that it is important to identify and consider the effect of encrypting data on the overall performance of a database. Determining the effect of encryption on performance of database systems can help to optimize encryption algorithms and developing compatible hardware to produce high-level and efficient data security technologies. Sources referred to in this review uniformly reveal that implementation of encryption reduces the performance of a database. Ferretti, L. et. al., (2014) discloses that encryption leads to increased processes involved in individual database transactions. These processes often require more CPU and memory allocation. These effects cause a performance overhead. This gives reason for this study to go further and collect relevant and conduct its own tests to affirm the current theory. Chapter 3 – Research Methodology and Design This chapter introduces and describes the design, procedure, approach and methods employed to collect and analyse data particularly for developing an affirmation of the grounded theory. It details on the strategies an activities involved in identification and development of evidence to support the research. 3.1 Approach It is definitely apparent that the research presented herein is deeply based on science since the work not only seeks to point out the existence of an impact in performance of DBMS due to implementation of encryption technologies but also explain the cause of the performance overhead. By being specific, this is a computer science research. As with most science based research works, this study seeks to affirm an existing phenomenon in a computational process. According to Saunders, M., Lewis, P., & Thornhill, A. (2007) classification of philosophical themes, this research being based on science can be placed under “epistemology” of Saunders research onion. An “epistemological” research inspires positivism, realism and interpretivism which combine together to drive a researcher towards performing experiments and tests to describe an existing phenomenon. Of the three philosophical paradigms (i.e positivism, realism and interpretivism) the overall experimentation of this study is pivoted towards logical positivism. Logical positivism is a philosophical system that supports use of logic to describe a fact. In this case, the current experimentation observes the logic that lies under the process of encryption of data files to reveal how the overall impact on performance comes about. As it will be described in the next chapter, various ways were used to monitor processes that ran in a single instance of an encrypted database transaction and compared to those that ran in a single instance of an unencrypted database transaction to a granulated level. The logic that can be observed from such a test is the difference in the number of activities. A database transaction that involves more activities takes more CPU allocation, memory space and more computer resources. Experimentation the modest way used to identify the variation in CPU and Memory occupation when different database transactions were run. Such results form a logical ground to explain the overall effect on a DBMS. This being a positivist research, it also takes the deductive approach. According to (Saunders et al., 2007), a deductive approach seeks to advance or confirm a pre-existing theory. This research does not create its own hypothesis. It just backs up an existing one. In a practical setting when one observes the performance of DBMSs set under the same platforms (i.e, similar microprocessors, operating system, memory, generation or technology of the memory and other hardware), it is possible to notice that DBMSs that do not apply any encryption mechanisms perform faster than those with encryption application. This is an existing theory. A description by Kothari, (2004) explains, a deductive approach typically involves picking up existing general knowledge then narrowing inside to prove a particular phenomenon. In the same way this work draws its origin from routine observations and experiences which occur to average database users. Several times DB clerks have whispered to their colleagues at the next desk like – “hey guy, have you realized that this application is slower than the other one?” or “man this thing is quick today. I performed 10 sorts in just 2 minutes. My ledger is ok now.” The general knowledge of “an application performing faster or slower” is identified as the performance of DBMS. However performance expressed in this way can be influenced by multiple factors such as the microprocessor speed, hardware capability, memory technology (DDR4s are incredibly faster than DDR3s) etc. By lowering down to studying the technology used to store and retrieve data in the DBMS and then further to analyzing the effect of data encryption, this research employs a deductive approach. 3.2 Strategy of the Research This research was primary concerned with investigating the tradeoff of database performance before and after database encryption, with an experiment done on the Oracle database. This means the research tests a theory. In this case, the impact on performance in a database environment with focus on the Oracle database as the next chapter presents. The theory is that database performance reduces after encrypting the entire database system. Moreover, this research design is more focused on what of the research rather than the why of the study subject (Sendłak, 2018). In this research the author used experimentation as the research approach. This means this research is based on quantitative data. Based on the research topic the research must be conducted in a controlled environment to yield the desired results. There are always two research approaches, qualitative and quantitative research approach which focuses on numerical data or data that can be quantified. According to Jervis and Drake (2014), quantitative data is data about quantity, and thus quantities, and qualitative data is subjective and applies to a concept that can be detected but not measured, such as language (Sendłak, 2018). Quantitative researchers seek to develop general behavioral and phenomenal laws through various settings/contexts (Howie and Bagnall, 2016) by comparing “numbers”. In a brief, the following are some of the values necessary for the analysis: Time taken to complete a single SQL transaction and CPU allocation for each process. These values are subjected to more mathematical or computational operations to form more abstract values that can be used for a simpler and easily interpretable comparisons. In a unified expression this is majorly a quantitative analysis. 3.4 Sample Sampling is the process in which a portion of observations is selected from a bigger or a whole population for the purpose of analysis (Wilson, 2011; Bryman and Bell, 2011; Saunders et al, 2012; Bryman, 2012). The sampling method used in this study was purposive or a non-probability sampling, whereby the researcher’s preference of sample selection is favored. A substantial sample size in qualitative research requires fullness of information (Strauss and Corbin, 1998). This research was sensitive enough to meet the Strauss and Corbin requirement. Multiple tests were run at different times and computer platforms. The conclusion reached was out of cumulative results obtained from the tests. 3.5 Data Collection The nature of this research together with the complexities of the theories chaperoning this study requires much attention the precision of the test results. Hence, this section employed high-level monitoring applications to record the presented results. All the tests were performed on the Oracle12c cloud DB. SQL Monitor 10.0 release and oracle 18c Express. Speed results were read from the SQL Oracle DB internal console and Linux GNU terminal. The appropriateness of these applications emanates from the fact that they method are fitting to print the most accurate results to the best precision. 3.6 Data Analysis The data presented in this section was analyzed using several GUI and command based tools from different providers. Oracle SQL Developer was used for writing and testing most of the SQL code presented in this paper. Other applications used in data analysis were: o GNU Terminal o SQL monitor o Microsoft Excel o Oracle Command Line The following chapter presents the experiments and results found from the tests. Chapter 4 – Experiment, Results and Discussion 4.1 Oracle Database Encryption Encryption may offer good protection for data at rest, but certain considerations must be considered in designing a database encryption strategy. Organizations must reconcile the need for protection with the need for outstanding results. Database-level encryption versus device level and file level has proven to be the optimal approach for protecting confidential data and providing results. There is a multitude of architectures and techniques for optimizing performance: solutions fall into two broad groups – alternative topologies for minimizing overhead encryption and techniques for restricting the number of encryption operations (Moulianitakis and Asimakopoulos, 2019). Any company must protect confidential data or experience future statutory, regulatory, legal and trademark implications. Adequate security is not established by relying on perimeter security and database access control. 4.2 Encrypting the Oracle Database Engine This section is will demonstrate how to encrypt an Oracle database engine. 1. First, begin by creating a user and granting DBA privileges to complete the process as shown below 2. For this step, it will demonstrate how to create a password protected KeyStore directory 3. Next is creating an auto-login software KeyStore from the KeyStore created in the previous step 4. Password protect the created KeyStore 5. Configuring the KeyStore backup and master key for the instance The following screenshot demonstrates how to build a master key that will be used to execute the necessary encryption tasks. The next step is implementing the encryption and testing the database performance. 4.3 Experiment Results Oracle Database Enterprise Admin provides to Oracle Database. The most advanced encryption and secure data editing software are important for controlling access to sensitive data. Transparent Data Protection and Data Redaction prevent unauthorized access to device levels, operating systems, backup media, and database sources. The Oracle Enhanced Security feature completely serves the multi-tenant environment and is aligned with Oracle’s unmatched efficiency systems. Data safety includes a layered defence approach that incorporates detection, recognition and interference. Figure 1. Tablespace Configurations 1. Creating tables in unencrypted mode 2. Creating tables in encrypted mode 3. Creating a column encrypted table in the encrypted tablespace without salt 4. Creating a column encrypted table in the encrypted tablespace with salt 5. Creating a column encrypted table in the default tablespace with and without salt In this section, the database engine was encrypted and tables created in both encrypted and unencrypted mode. The next section will investigate this project’s aim/objective – data encryption impact on performance in oracle and Database storage. Results The apparent grounded theoretical framework upholds the supposition that implementation of data encryption on a Database Management System affects the performance of the database. However, the validation of this supposition is determined by the outcome of the tests performed in the experiments as described in the earlier sections. The tests performed adhere to this study’s visible research question “how actually does Transparent Data Encryption affect the performance of a database?” by comparing the tradeoff that exists between encrypted and unencrypted database transactions. The coordinated tests were resolute and logically consistent to the current study in order to largely contribute to its hypothesis. The test scripts (otherwise referred to as SQL scrips) presented herein were run to equate the degree of efficiency between normal unencrypted and encrypted database operations by comparing time taken to run various SQL scripts. Each action is repeated 1000 times, with timings recorded in 100th of a second. The scripts were all applied on Oracle’s Transparent Database Encryption tablespace. Creation of this tablespace is illustrated earlier in the Experiments section. The unified SQL script. –TEST SET SERVEROUTPUT ON SIZE UNLIMITED DECLARE l_loops NUMBER := 1000; l_accno NUMBER; l_salary NUMBER(6); l_start NUMBER; BEGIN EXECUTE IMMEDIATE ‘TRUNCATE TABLE employee_ENC_TS’; EXECUTE IMMEDIATE ‘TRUNCATE TABLE employee_DEF_TS’; EXECUTE IMMEDIATE ‘TRUNCATE TABLE COLUMN_ENC_EMP_ENC_TS’; EXECUTE IMMEDIATE ‘TRUNCATE TABLE COLUMN_ENC_SALT_EMP_ENC_TS’; EXECUTE IMMEDIATE ‘TRUNCATE TABLE COLUMN_ENC_EMP_TS’; EXECUTE IMMEDIATE ‘TRUNCATE TABLE COLUMN_ENC_SALT_EMP_TS’; l_start := DBMS_UTILITY.get_time; FOR i IN 1 .. l_loops LOOP INSERT INTO employee_DEF_TS (empID, accNo,salary) VALUES (i, 1000*1,250*1); END LOOP; DBMS_OUTPUT.put_line(‘Normal Insert Default Tablespace : ‘ || (DBMS_UTILITY.get_time – l_start)); l_start := DBMS_UTILITY.get_time; FOR i IN 1 .. l_loops LOOP INSERT INTO employee_ENC_TS (empID, accNo,salary) VALUES (i, 1000*1,250*1); END LOOP; DBMS_OUTPUT.put_line(‘Normal Insert Encrypted Tablespace: ‘ || (DBMS_UTILITY.get_time – l_start)); l_start := DBMS_UTILITY.get_time; FOR i IN 1 .. l_loops LOOP INSERT INTO COLUMN_ENC_EMP_TS (empID, accNo,salary) VALUES (i, 1000*1,250*1); END LOOP; DBMS_OUTPUT.put_line(‘Encrypted Insert Default Tablespace : ‘ || (DBMS_UTILITY.get_time – l_start)); l_start := DBMS_UTILITY.get_time; FOR i IN 1 .. l_loops LOOP INSERT INTO COLUMN_ENC_EMP_ENC_TS (empID, accNo,salary) VALUES (i, 1000*1,250*1); END LOOP; DBMS_OUTPUT.put_line(‘Encrypted Insert Encrypted Tablespace: ‘ || (DBMS_UTILITY.get_time – l_start)); l_start := DBMS_UTILITY.get_time; FOR i IN 1 .. l_loops LOOP INSERT INTO COLUMN_ENC_SALT_EMP_TS (empID, accNo,salary) VALUES (i, 1000*1,250*1); END LOOP; DBMS_OUTPUT.put_line(‘Encrypted Insert Default Tablespace WITH SALT : ‘ || (DBMS_UTILITY.get_time – l_start)); l_start := DBMS_UTILITY.get_time; FOR i IN 1 .. l_loops LOOP INSERT INTO COLUMN_ENC_SALT_EMP_ENC_TS (empID, accNo,salary) VALUES (i, 1000*1,250*1); END LOOP; DBMS_OUTPUT.put_line(‘Encrypted Insert Encrypted Tablespace WITH SALT: ‘ || (DBMS_UTILITY.get_time – l_start)); l_start := DBMS_UTILITY.get_time; FOR i IN 1 .. l_loops LOOP SELECT accNo,salary INTO l_accno,l_salary FROM employee_DEF_TS WHERE empID = i; END LOOP; DBMS_OUTPUT.put_line(‘Normal Query Default Tablespace : ‘ || (DBMS_UTILITY.get_time – l_start)); l_start := DBMS_UTILITY.get_time; FOR i IN 1 .. l_loops LOOP SELECT accNo,salary INTO l_accno,l_salary FROM employee_ENC_TS WHERE empID = i; END LOOP; DBMS_OUTPUT.put_line(‘Normal Query Encrypted Tablespace: ‘ || (DBMS_UTILITY.get_time – l_start)); l_start := DBMS_UTILITY.get_time; FOR i IN 1 .. l_loops LOOP SELECT accNo, salary INTO l_accno,l_salary FROM COLUMN_ENC_EMP_TS WHERE empID = i; END LOOP; DBMS_OUTPUT.put_line(‘Encrypted Query Default Tablespace : ‘ || (DBMS_UTILITY.get_time – l_start)); l_start := DBMS_UTILITY.get_time; FOR i IN 1 .. l_loops LOOP SELECT accNo,salary INTO l_accno,l_salary FROM COLUMN_ENC_EMP_ENC_TS WHERE empID = i; END LOOP; DBMS_OUTPUT.put_line(‘Encrypted Query Encrypted Tablespace: ‘ || (DBMS_UTILITY.get_time – l_start)); l_start := DBMS_UTILITY.get_time; FOR i IN 1 .. l_loops LOOP SELECT accNo,salary INTO l_accno,l_salary FROM COLUMN_ENC_SALT_EMP_TS WHERE empID = i; END LOOP; DBMS_OUTPUT.put_line(‘Encrypted Query Default Tablespace WITH SALT : ‘ || (DBMS_UTILITY.get_time – l_start)); l_start := DBMS_UTILITY.get_time; FOR i IN 1 .. l_loops LOOP SELECT accNo,salary INTO l_accno,l_salary FROM COLUMN_ENC_SALT_EMP_ENC_TS WHERE empID = i; END LOOP; DBMS_OUTPUT.put_line(‘Encrypted Query Encrypted Tablespace WITH SALT : ‘ || (DBMS_UTILITY.get_time – l_start)); END; / Code Summary. Declaration of variables to be used in the loop. DECLARE l_loops NUMBER := 1000; l_accno NUMBER; l_salary NUMBER(6); l_start NUMBER; BEGIN The SQL script above declares variables l_loops, l_accno, l_salary and l_start as variables of type NUMBER. Variable l_loops stores the number of loops which the processes (insertion and selection) iterate through. The number of loops is initiated to 1000 meaning every insertion or selection will be repeated 1000 times. The l_start variable holds the value of the initial time at the start of the loop. The initial time would later be used to compute the overall time taken to complete the loops by subtracting the time at the start of the loop from the time returned by the internal Oracle DB utility function DBMS_UTILITY.get_time at the end of the loop. The BEGIN statement commences the loop. Data Insertion into the tablespaces. l_start := DBMS_UTILITY.get_time; FOR i IN 1 .. l_loops LOOP INSERT INTO employee_DEF_TS (empID, accNo,salary) VALUES (i, 1000*1,250*1); END LOOP; DBMS_OUTPUT.put_line(‘Normal Insert Default Tablespace : ‘ || (DBMS_UTILITY.get_time – l_start)); The above script inserts values “i”, “1000*1” and “250*1” into columns empID, accNo and salary of the employee_DEF_TS tablespace respectively iterating one thousand times. This first SQL script makes a Normal insertion into the “Default Tablespace”. The insertion action is non-encrypted. The last line in the script returns the amount of time taken to complete the insertion and prints it to the console. The same script is repeated to perform 1000 encrypted insertions into the tablespace in different modes. There is also an encrypted insertion performed in an encrypted tablespace with SALT. INSERT INTO employee_ENC_TS (empID, accNo,salary) VALUES (i, 1000*1,250*1); END LOOP; DBMS_OUTPUT.put_line(‘Normal Insert Encrypted Tablespace: ‘ || (DBMS_UTILITY.get_time – l_start)); l_start := DBMS_UTILITY.get_time; Performing Queries: For a thousand times the script below selects the account number and salary of a record whose id is “i” from the tablespace, returns the amount of time taken to perform the query and prints it to the console. l_start := DBMS_UTILITY.get_time; FOR i IN 1 .. l_loops LOOP SELECT accNo,salary INTO l_accno,l_salary FROM employee_ENC_TS WHERE empID = i; END LOOP; DBMS_OUTPUT.put_line(‘Normal Query Encrypted Tablespace: ‘ || (DBMS_UTILITY.get_time – l_start)); The same script is applied on the rest of the tablespaces in encrypted and decrypted modes. The aim of the running SQL scripts was to record the time it took to execute them respectively on both tablespaces that applied Transparent Data Encryption and tablespaces without any encryption. Additionally, the analysis made utilized real-time SQL Monitor to track the time it took to execute individual SQL scripts, and the CPU each consumed by each transactions. The DBMS_SQL_MONITOR is available on Oracle12c and later versions. The function can also be used to monitor the CPU usage of the respective SQL executions. The SQL Monitor combines well with Oracle Database Manager to enable configuration of threshold of resource usage of SQL executions. The image below presents a summary of the final results after execution of the SQL executions. Normal insertion of one record into a non-encrypted tablespace a thousand times took about 2/100 of a second (50th of a second or two centiseconds) to complete. In comparison to an Encrypted insertion into an Encrypted Tablespace with SALT, it took double the time to successfully complete the operation. A normal Query run on an Encrypted Tablespace took about 3 centiseconds to successfully complete the transaction while an encrypted query on and Encrypted Tablespace recorded twice as much time. The results tested using the local oracle 18c Express version were interesting. The above scripts were executed in the database to ensure consistency. The CPU performance and the time elapsed to run each query was recorded. comparison between the database with TDE and that without TDE were made within two cases discussed below. Furthermore, a new concept was introduced to cement the results since, using the local database breaks the arrangement of using a controlled environment as stated above. The constraints introduced included whether the data was stored in memory or disk for both encrypted and not encrypted database. In the local oracle 18c however, each query was run 5 times rather than 100 times as before. Each query was run 5 times to even out the CPU variances between executions. Subsequently, the tests that involved reading from disks, it was vital to execute the command DBCC DROPCLEANBUFFERS between different executions of the query. This ensure the buffer is cleared to avid falsified results. The output of the tests is shown in the following tables: CPU performance and the time for execution. It is also fundamental to note that the MAXDOP was set to four and each given query was executed over four parallel threads. Therefore, the results may differ from one laptop to another. For these tests, HP X360 convertible with 16GB RAM and 1000TB HDD was used. It had 4 logical processors and total of 8 cores. There was a quite noticeable variance that existed between each run. Therefore, nothing significant on these tests due to the small differences. However, the execution time recorded for in memory data was the same for database with TDE and for the database without TDE. But there was an overhead of about 10% with the database with TDE when the data was fetched from the disk. In an event a specific record was being fetched much noticeable changes were recorded. When the query included a WHERE clause or an equality predicate, there was less work to be done by the CPU therefore, lesser times of execution were recorded. Therefore, the query was executed much faster, and the results were as below. As indicated earlier, the query was executed faster and, the time elapsed with TDE and without TDE were almost the same when the data was fetched from memory. However, investigating the time elapsed with TDE when fetching from disk is 10 times larger than without TDE. When represented in percentages, it is 1000% worse. Discussion Beginning from a rudimentary level of analysis, the above results have shown that tablespaces which do not apply any kind of Transparent Data Encryption perform relatively faster than those that apply DTE. Logically there are more processes involved in executing an encrypted SQL transaction than a non-encrypted transaction. For the former, the query process has to initially access an encryption key from Oracle DB keystore. The encryption key is used to decode the data files into plain text. The decrypted data files are then loaded into the buffer cache memory for ready access by other processes. Any other similar concurrent SQL transaction that requires the previously buffered data files can access the files in the cache memory. Notice that at this point, TDE has to make use of the computer’s cache memory to hold the decrypted files and make them available in plain text in order to reduce the process of encrypting and decrypting the data in use repeatedly. It is therefore in order to conclude that apart from TDE being characterized with consistent performance “overheads”, it also requires more computer memory as compared to working with non-encrypted tablespaces (Baba, M. et. al., 2014, Greenwald, R. et. al., 2013). In reference to the outcome of the tests, Non-encrypted (also referred to Default Tablespaces) recorded less time to complete most of the SQL scripts. The fundamental cause of better performance of non-encrypted tablespaces emanates from the fact that non-encrypted SQL transactions contain fewer processes than TDE based SQL transactions. The insert script goes straight to the tablespace and pulls the required data files without having to through the process of decoding. Additionally, unencrypted SQL transactions do not require much caching memory. In this mode data files are usually stored in plain text in their permanent storage. This makes it possible for access and usage of the data files from their respective tablespaces without holding them in the cache memory. However, TDE benefits from caching in instances where files which are already buffered get used by processes most of the time throughout the DBMS processes. In such instances, the required files are in plain text therefore bearing no need to encrypt or decrypt them. After running several tests on Oracle’s SQL Monitor the outcome indicated that SQL scripts performed on the encrypted tablespace recorded higher CPU usage than those run on the default tablespace. These results are coherent to the logical functioning of TDE on Oracle tablespace. The process of conversion of data files to and from plain text to their respective ciphers requires multiple computations. In comparison to Default unencrypted operations, there are fewer computations involved. The higher the number of processes involved in a transaction, the more the amount of CPU consumed. On the local database 18c Express, two different scenarios created. The first scenario involved fetching data from memory while the second one involved reading data from the disk. Accessing data from disk was very expensive for the CPU. In sum, the tests performed in this study converge to uphold the hypothesis grounded in this research that data encryption causes an overhead in performance of a database management system. Conclusion The foundation and motivation of the study presented herein rose from the need to examine, dissect and explore internally how Transparent Data Encryption is applied to secure a Database Management System. The paper centered its focus on establishing the resulting impact when TDE is applied in encoding database files to enhance security of data at rest. Drawing from the outcome or the results, the discussion and therefore the conclusion of the hypothesis, it is visibly evident that encryption causes a performance overhead of a DBMS. However, the performance overhead does not surpass the need to uphold data security. Thus, TDE should be implemented so protect data against access by unauthorized persons. There needs to be a balance between enhancing performance and maintaining data security while implementing TDE. The two metrics are the determinants of a sophisticated and efficient database system. Modern day computer systems are sophisticated enough such that some of this overhead is assumed by database users. The intensity of the overhead is usually observed in case of large volumes of data and bulky database transactions. Big companies which operate on extremely large volumes of data invest much into developing high-speed hardware to counter the intense database processes. The overhead in database performance mostly affects consumers who subscribe to such on premise and cloud DB services. Future Works Although there exists ample scholarly works that study and provide solutions on security of cloud systems, encryption technologies and ciphering algorithms, many of them do not consider important aspects that affect end consumers. Computer Scientists should distribute some of their focus on analyzing the minimal yet important issues that exists within DBMS security technologies. Such issues end up affecting the end consumers gradually. For instance, the slight inefficiency of databases as a result of data encryption escalates to decelerated database queries and updates. This finally affect the output of analytics-based organizations. The field of data security is still in need of elevated, state of the art and investigative research in order to develop fast, efficient and high level technologies to secure DBMSs. Some of the subjects and technologies still that require research content are Endpoint Data Protection, Crowd Sourced Storage and Data and Internet of Things. These are some of the most promising technologies that are gradually being incorporated in routine operation of different organizations. There still hails a future for this research. Notably, this work did not go deep into studying the aesthetics of prominent cryptographic algorithms built for securing DBMSs. The work only focused on determining the performance of Oracle’s TDE on its DBMS and therefore the performance of any other DB that applies encryption to data at rest. However, by examining the logic that is applied by such algorithms, possible compatible microprocessor and memory technology, this research stands a chance to suggest better implementation of encryption to increase database performance. Reference List Ahmad, A., Baba, M.A., Maijama’a, L. and Yusuf, A., 2014. Performance analysis of the encryption algorithms as a solution to cloud database security. International Journal of Computer Applications, 99(14), pp.24-31. Bouganim, L. and Guo, Y., 2009. Database encryption Elovici, Y., Gudes, E., Shmueli, E. and Vaisenberg, R., 2014. Implementing a database encryption solution, design and implementation issues. Computers & Security, 44, pp.33-50. Elovici, Y., Vaisenberg, R. and Shmueli, E., Ben Gurion University of Negev Research and Development Authority Ltd, 2018. Method and system for database encryption. U.S. Patent 9,934,388. Available at: US9934388B2 – Method and system for database encryption – Google Patents Ferretti, L., Pierazzi, F., Colajanni, M. and Marchetti, M., 2014. Performance and cost evaluation of an adaptive encryption architecture for cloud databases. IEEE transactions on cloud computing, 2(2), pp.143-155. Freeman, W. and Miller, E., 1999, October. An experimental analysis of cryptographic overhead in performance-critical systems. In MASCOTS’99. Proceedings of the Seventh International Symposium on Modeling, Analysis and Simulation of Computer and Telecommunication Systems (pp. 348-357). IEEE. Göttel, C., Pires, R., Rocha, I., Vaucher, S., Felber, P., Pasin, M. and Schiavoni, V., 2018, October. Security, performance and energy trade-offs of hardware-assisted memory protection mechanisms. In 2018 IEEE 37th Symposium on Reliable Distributed Systems (SRDS) (pp. 133-142). IEEE. Available at: https://ieeexplore.ieee.org/document/8613961 Howie, P. and Bagnall, R., 2016. A methodology for field-testing concepts through expert practitioner engagement. International Journal of Social Research Methodology, 20(4), pp.401-410. Hue, P., 2017. Oracle Database Advanced Security Guide, Available at https://docs.oracle.com/database/121/ASOAG/toc.htm [Accessed January 21, 2021]. Jervis, M. and Drake, M., 2014. The Use of Qualitative Research Methods in Quantitative Science: A Review. Journal of Sensory Studies, 29(4), pp.234-247. Jun, H., Li, D., Li, J., Li, T., Zhang, L. and Zhu, B., 2019, November. Design and implementation of a database encryption system for the cloud environment. In Proceedings of the International Conference on Advanced Information Science and System (pp. 1-7). Mattsson, U.T., 2005. Database encryption-how to balance security with performance. Available at SSRN 670561. Moulianitakis, F. and Asimakopoulos, K., 2019. Benchmarking Framework for Transparent Data Encryption Systems. Available at: www.diva-portal.org/smash/get/diva2:1347966/fulltext01.pdf Mattsson, U., 2017. Database Encryption – How to Balance Security with Performance. [online] Protegrity Corp. Available at: http://hosteddocs.ittoolbox.com/UM070805.pdf [Accessed 14 February 2021]. Moulianitakis, F. and Asimakopoulos, K., 2019. Bench-marking Framework for Transparent Data Encryption Systems. Masters. The Luleå University of Technology. Oracle Database, 2016. Oracle Advanced Security Transparent Data Encryption (TDE). Frequently Asked Questions (FAQ). [online] Oracle Inc. Available at: https://www.oracle.com/a/ocom/docs/aso_12c_faq.pdf [Accessed 14 February 2021]. Natarajan, K. and Shaik, V., 2020, November. Transparent Data Encryption: Comparative Analysis and Performance Evaluation of Oracle Databases. In 2020 Fifth International Conference on Research in Computational Intelligence and Communication Networks (ICRCICN) (pp. 137-142). IEEE. Available at: https://ieeexplore.ieee.org/document/9296168 Retinger, M., 2019. A client-based encryption model for secure data storing in publicly available storage systems. Computer Science, 20. Rafique, A., Van Landuyt, D., Reniers, V. and Joosen, W., 2017, April. Towards scalable and dynamic data encryption for multi-tenant saas. In Proceedings of the Symposium on Applied Computing (pp. 411-416). Saunders, M., Lewis, P., & Thornhill, A. (2007). Research Methods for Business Students, (6th ed.) London: Pearson. Sendłak, M., 2018. On Quantitative and Qualitative Parsimony. Metaphilosophy, 49(1-2), pp.153-166. Shang, T., Chen, R. and Lei, Q., 2019. Quantum random oracle model for quantum public-key encryption. IEEE Access, 7, pp.130024-130031. Strauss, A. and Corbin, J. (1990). Basics of Qualitative Research: Grounded Theory Procedures and Techniques. Thousand Oaks, California: Sage publishing. Webster, M. and Sell, J., 2014. Why Do Experiments? Laboratory Experiments in the Social Sciences, pp.5-21. Wiese, L., Waage, T. and Brenner, M., 2020. CloudDBGuard: A framework for encrypted data storage in NoSQL wide column stores. Data & Knowledge Engineering, 126, p.101732. Williams, N., 2020. Non-Representational Theory. International Encyclopedia of Human Geography, pp.421-427. Yan, S., 2019, December. Research on Implementation Method of Key Management Based on Data Encryption Technology. In IOP Conference Series: Materials Science and Engineering (Vol. 677, No. 4, p. 042018). IOP Publishing. Zea, A.V., Barrera, J.F. and Torroba, R., 2017. Cryptographic salting for security enhancement of double random phase encryption schemes. Journal of Optics, 19(10), p.105703. Zhang, F., Chen, Y., Meng, W. and Wu, Q., 2019. Hybrid encryption algorithms for medical data storage security in a cloud database. International Journal of Database Management Systems (IJDMS) Vol, 11.
