dataesr/scientific-paragraphs-categorization huggingface dataset:
Functional Analyses of SEC epi To examine the function of SEC epi in S. epidermidis pathogenicity from human, a recombinant protein was purified from E. coli and used to assess the superantigenic activity of enterotoxin. Lymphocyte proliferation and cytokines production were measured using human PBMC from three healthy donors. First, PBMC were stimulated in the presence or absence of various concentrations of rSEC epi and SEC aureus. SEC epi was tested for mitogenic activity on stimulated human PBMC in a 5-bromo-2 deoxyuridine (BrdU) colorimetric incorporation assay  [15]. Figure  6  shows representative results of three experiments. Addition of 100 U of polymyxin B as a LPS inhibitor did not influence the results, indicating that the effect due to LPS contamination was negligible (data not shown).
Bioinformatic Analysis Sequence databases were searched with the blast program available https://blast. ncbi. nlm. nih. gov/blast. cgi. The sequence alignments were performed using the Clustalw2 alignment software (http://www. ebi. ac. uk/tools/msa/clustalw2/). The DNA sequences were translated to ORF by expasy translate  [42]. The molecular weight and isoelectric point (pI) were predicted by the protParam server  [43]. The modeled structure and protein ligand binding site residues of SEC epi were predicted using the I-TASSER server (Iterative Threading ASSEmbly Refinement) in Michigan University  [44]. The modeled SEC epi was used for comparison with predetermined structure SEC derived from S. aureus.
0 (Bio-Rad Laboratories, Inc. , Hercules, CA, USA) according to manufacturer's instructions. Briefly, beads were incubated for 20 s on 96 well plates and were washed in Bio-plex wash buffer. Diluted standard and samples were added, and the plates were incubated for 30 min on shaker. After washing, detection antibodies were added and reincubated for 30 min on shaker. The plates were washed and streptavidin-phycoerythrin (SA-PE) added, followed by 10 min of incubation and wash. Assay buffer was finally added and incubated for 10 min, followed by the plates analyzed. Data are presented as the means of standard deviations of triplicate determinations.
In recent years, the increasing popularity of outsourcing data to third-party cloud servers sparked a major concern towards data breaches. A standard measure to thwart this problem and to ensure data confidentiality is data encryption. Nevertheless, organizations that use traditional encryption techniques face the challenge of how to enable untrusted cloud servers perform search operations while the actually outsourced data remains confidential. Searchable encryption is a powerful tool that attempts to solve the challenge of querying data outsourced at untrusted servers while preserving data confidentiality. Whereas the literature mainly considers searching over an unstructured collection of files, this paper explores methods to execute SQL queries over encrypted databases. We provide a complete framework that supports private search queries over encrypted SQL databases, in particular for PostgreSQL and MySQL databases.
INTRODUCTION Outsourcing data storage and processing to thirdparty servers, such as cloud servers, has become a common procedure. However, when it comes to storing personal or business confidential data, the usage of cloud services is currently questioned as as potentially malicious cloud servers may try to learn information from the data they store and the queries they process or even leak them to some unauthorized parties. Encryption is a standard approach to ensure the confidentiality of data outsourced at honestbut-curious cloud servers. However, "traditional" encryption schemes deprive the users of functionalities over the data, such as searching. In this case, to search words in encrypted outsourced data, the users are required to retrieve the entire dataset from the cloud, decrypt it and operate the search locally.
This naive approach poses serious performance concerns which cancel out the benefit of outsourcing. Therefore, cloud servers should be able to perform the search operation in outsourced databases, while the actual databases are encrypted. The problem of searching over encrypted data has received much interest from both academia  (Song et al. , 2000; Hacigümüs ¸et al. , 2002; Agrawal et al. , 2004; Curtmola et al. , 2006; Chase and Kamara, 2010; Popa et al. , 2012; Cash et al. , 2013; Kamara and Papamanthou, 2013)  and industry (Bitglass 1 , Cipher-Cloud 2 or Skyhigh 3 ). Research on this topic mainly focuses on the scenario of a user who outsources an encrypted collection of documents (such as e-mails, medical records, etc. ) and would like to further search keywords over this encrypted dataset.
While this theoretical setting is valid, in practice, many organizations such as governments, hospitals or companies store data in relational databases which structure data into tables according to a set of attributes. The popular SQL language  (Chamberlin and Boyce, 1974)  enables users to store, query and update their data in a user-friendly manner. SQL databases ensure fast record search and retrieval provided that the SQL server is able to read data content. As mentioned before, encryption typically impedes the server from reading data which makes search over encrypted databases challenging. In particular, a cryptographic data protection mechanism for searching over encrypted data stored in a SQL database should allow the server to efficiently process search queries without having access to the plaintext data.
Besides, querying an encrypted SQL database should be user-friendly: protected que-ries should adopt the SQL syntax and simulate the search functionality as if data was not encrypted. A direct application of solutions for searching an encrypted collection of files to SQL databases is not straightforward. Indeed, existing solutions  (Curtmola et al. , 2006; Chase and Kamara, 2010; Cash et al. , 2013; Kamara and Papamanthou, 2013)  build an index of the keywords. In the case of SQL, data is arranged into tables, and records are queried based on a condition over one or more attributes. Therefore, keywords should preserve this notion of attribute. Furthermore, SQL allows performing comparisons of data (range queries) which are not always addressed in existing work. To solve these challenges, in  (Popa et al.
, 2012) , the authors proposed CryptDB, a framework that supports SQL queries over encrypted data. This solution relies on layers of different property-preserving encryptions, such as deterministic (DET) and orderpreserving encryption (OPE), applied to a column of an SQL table. To query the encrypted database, CryptDB converts the plaintext SQL query into its encrypted equivalent and decrypts the targeted layers. The major drawback of CryptDB lies in the fact that whenever one layer is removed, the encryption scheme becomes weak. In light of this, the major problem is to deliver a practical solution for searching over encrypted databases that does not suffer from the leakage occurring in CryptDB and that enables transparent processing of complex queries over encrypted SQL databases. In this work, we tackle this problem and propose a practical construction for searching over encrypted SQL databases which limits information leakage.
Our solution builds upon the searchable encryption technique designed in  (Curtmola et al. , 2006)  which applies to unstructured documents. This mechanism builds an inverted search index of keywords in the database to enable keyword search queries over encrypted data. We make the following contributions: • We define a solution that is SQL-compatible, so as to empower user and server to use SQL's operations of database creation, data insertion and search. We propose a framework for implementing our solution on the PostgreSQL backend; • Our solution achieves practicality thanks to the use of the cuckoo hashing technique which renders the search in the index efficient; • Our solution supports complex queries, namely boolean and range queries; • We evaluate the practicality of our solution by testing it over an encrypted e-health database.
SQL Databases Our work focuses on data structured in SQL databases such as MySQL 4  or PostgreSQL 5. An SQL database D organizes the data in a set of two-dimensional tables (T 1 , T 2 ,. , T n ). Each table row is a record, the columns are attributes, and each table entry a value. We assume the existence of a view V , resulting from a query applied to the data in D, which represents a subset of the records, selected from different tables in D, in such a way that queries can directly be processed on V. We mainly consider the SELECT operation that can be expressed as follows: SELECT attributes FROM table WHERE conditions. This query retrieves from an SQL table (or a view) the records, and more precisely, the attributes specified after SELECT, that match conditions. In this work, we are interested in conditions that can be written as a boolean expression Q : r → {0, 1}, which, evaluated on a record r of D, returns Q (r) = 1, if r satisfies the expression or Q (r) = 0 otherwise.
Q consists of several predicates P i that express conditions over one or more attributes in D and are combined with boolean operators: OR and AND. Each of the P i involves operators such as =, >, <, ≥, ≤ and relates a database attribute to a search criterion. Q = P 1 ∧ P 2 ∧. ∧ P m. Disjunctive queries (OR): Predicates are combined with an OR operator: Q = P 1 ∨ P 2 ∨. ∨ P m. Range queries: They involve one or two predicates combined with an AND operator, and apply to numeric data to find value within a range. Complex queries: They combine conjunctions, disjunctions and range queries.
Use Case Let us consider a hospital that collects data from their patients. This data may consist of their personal information (names, age, etc. ), their biological data (height, weight, body temperature, etc. ) or the care they received (surgery operation, etc. ). This data is managed in an SQL database (such as in Table  1 ). The hospital's information technology (IT) department would like to pay the service of a cloud provider to store and enable access to the data. However, since the e-health data is confidential and because the hospital must comply with strong regulations with respect to the storage and processing of medical data (such as the recent European General Data Protection Regulation (GPDR, 2016)), the IT staff encrypts the data before its outsourcing. Nevertheless, the hospital does not want to lose the functionalities offered by the SQL language.
Background We base our work on the scheme described in  (Curtmola et al. , 2006). Unlike our use case, the authors do not consider SQL databases but focus on an unstructured collection of files D. To enable user U to efficiently search for a keyword ω in the encrypted dataset C , this scheme builds an inverted search index I , that links each keyword ω with D(ω), the set of identifiers of documents containing ω. I is also obfuscated so that it does not disclose any information about the data. Only the holder of the secret key can issue a search query. The search time is linear in the size of D(ω), which is believed to be optimal  (Curtmola et al. , 2006). Besides, the authors proved that their scheme is secure under IND-CKA1 (security against chosen-keyword attack). In a nutshell, this security definition requires that an adversary should learn nothing from the outsourced data and the index beyond what can be inferred from the search results and the access pattern, even if the adversary chooses the keywords.
Requirements for SQL-compatibility Given the scenario described in Section 3. 1, we identify five requirements for designing an SSE solution that would support SQL databases: R1: Dictionary Creation. The first requirement concerns the choice of the keywords W. In  (Curtmola et al. , 2006) , the authors only mention to "scan D to build the set of distinct words". In SQL databases, the data is structured into tables, where each record contains several attributes that take specific values. Hence, one can imagine that the dictionary would contain all the possible values in D. We show in Section 3. 5 that such a dictionary does not work in the scope of SQL databases. Therefore, we specify an algorithm CreateDictionary to create an appropriate W. R2: Practical Look-up Table  T. The authors in  (Curtmola et al.
, 2006)  mention the use of an FKS dictionary  (Fredman et al. , 1984) , without giving much details about its implementation. FKS dictionaries are known to be memory expensive and finding the hash that prevents hash collisions (as a matter of fact, a perfect hash function) when inserting a new item is a demanding process. For these reasons, we opt for another data structure, simpler to implement, more practical and more flexible, namely a cuckoo hash table. We give an overview of this data structure in Section 3. 4. R3: Structured-data Encryption. In the case of unstructured datasets, each document is encrypted independently. In the case of SQL databases, the organization of data into SQL tables requires that each value in the tables is encrypted independently, using a semantically secure encryption algorithm.
This will preserve the functionality of selecting specific attributes from an SQL table using the instruction SELECT attributes. Therefore, we will define two additional algorithms EncryptTable and DecryptResults. R4: Transparent SQL Queries. In  (Curtmola et al. , 2006) , communication details between user and server are omitted. With SQL databases, querying data is a well-defined process that involves specific SQL instructions such as CREATE, INSERT or SELECT. In this paper, we require that a user transparently queries the database, meaning that no change is needed in the user's application program. Even in the case of encrypted data, our SSE scheme should respect the SQL language expressiveness, available in the case of plain databases. R5: Complex Queries. Last but not least, the SSE in  (Curtmola et al.
Our Construction for Simple Keyword Queries Our solution is built upon the technique described in  (Curtmola et al. , 2006) , but implements several modifications in order to satisfy the previously mentioned requirements. Let us consider a database D = {T }. Table T contains t attributes and R records. Without loss of generality, for databases with multiple tables, we assume that we can reason on a view V extracted from a subset of these tables. Our first proposal provides a solution to satisfy requirement R1. We define an algorithm CreateDictionary to construct a dictionary W from D. As required by algorithm BuildIndex, the search index, built upon W, stores information about the records that contain each of the keywords. Besides, a basic SQL query contains a clause WHERE of the form attribute=value , meaning that we are interested in the records where the attribute has the specified value.
Algorithm 3 depicts the operations to build dictionary W. To build index I = (A, T ), we first permute the rows in the database and then we follow the procedure described in Algorithm 4. In our case, we consider the record identifier, denoted as RecordID, as an additional attribute of the considered SQL table. To improve the efficiency of  (Curtmola et al. , 2006) 2 for ω i ∈ W do 3 value = addr[A(N i,1 )]||k i,0 ⊕ ϕ K ϕ (ω i ) 4 CuckooInsert(T , π K π (ω i ), value) 5 end 6 Output I = (A, T ) The next operation in our SSE construction encrypts the SQL table with a semantically secure encryption scheme E = (E, D). As opposed to  (Curtmola et al. , 2006) , we define two encryption and decryption algorithms 8  (Algorithm 5). Algorithm EncryptTable encrypts each entry in the table separately, and because of the semantically secure property of the encryption scheme, each encrypted entry is indistinguishable from the others.
The last step of our protocol decrypts the obtained records by calling algorithm DecryptResults. and encrypted under key k 5 Output each decrypted record ID Proposed Framework. In addition to the algorithms we specified in the abovementioned paragraphs, we suggest that our SSE construction follows the framework depicted in Figure  2. Specifically, this framework allows to run the secure search function, namely algorithm Search, on a widely adopted SQL server, namely PostgreSQL. The architecture of the proposed framework consists of two zones: Trusted Zone: It includes user U with an unmodified SQL client application. We define a proxy between U and S, which executes all the userside functions of our protocol. The keys generated with KeyGen are stored in a keystore. Untrusted Zone: It consists of the untrusted cloud server S running PostgreSQL that stores the encrypted database and the secure search index.
Range Queries Let us consider the attribute Age from the database example depicted in Table  1  and   3  shows table PATIENT extended with the attribute Range Age. Note that the user selects its preferences on the range interval and the initial value, based on the content of the database and the possible queries she may issue, depending on the use cases 10. When user U wants to retrieve the records that match a range query, the proxy issues an SE query that contains the trapdoor(s) associated with the specified range. Different cases can be encountered: 1. The range query exactly corresponds to one of the range included in the search index. If we consider the example of Table  3,.
IMPLEMENTATION AND PERFORMANCE EVALUATION Implementation. Our SSE scheme is implemented according to the architecture shown in Figure  2. All the functions at the proxy are implemented in Java. The server runs PostgreSQL server (version 9. 5). Search is coded in Java with PL/Java 11  , an addon for server-side procedures. The code is packed into a JAR that is further loaded into the PostgreSQL backend, so as to execute Search directly in PostgreSQL. We tested our prototype on a single machine that simulates both the proxy and the server. The machine has four 3. 20GHz Intel Core TM i5-3470 processors, 32GB of RAM and runs Ubuntu 14. 04 LTS. E-Health Database. This work is done in the context of a collaborative project named CLARUS 12  , which collected data from anonymized medical records of a hospital.
This database consists of eight tables and queries are performed over a view (in the SQL terminology) called LAB. This view lists 64. 440 records and comprises eight attributes, including a patient identifier (pat id), a patient name (pat name), a patient last name (composed of two parts pat last1 and pat last2) and an identifier of an episode of care (ep id). Results. We measured the time consumed by the phases described above over the e-health database. We let our program automatically add range attributes for pat id. The length of the ranges is 10: we insert Range pat id values of the form [0, 9], [10, 19], etc. We ran 100 executions of the functions, and computed the average time, listed in Tables  4  and 6. We com-pare these measurements with the case where upload (resp. search) is performed without the application of our SSE mechanism in Table  5  (resp.
RELATED WORK We reviewed the literature in the area of searchable encrypted database systems. The design of such systems always trades off between the level of security, the query functionalities preserved in spite of encryption and the performance. Boolean Queries. In  (Hacigümüs ¸et al. , 2002) , the authors proposed a heuristic to execute SQL queries over encrypted data where the querier user is required to perform a heavy processing of the search results, whereas in our case, query and retrieval are lightweight operations. Besides, this solution encrypts records as a whole whereas our construction encrypts records attribute-wise. The authors do not provide any security guarantee. In  (Cash et al. , 2013) , an SSE scheme for boolean queries, named OXT, is tested with a MySQL database. This solution builds two indexes, which increases the storage overhead at the server.
ARX  (Poddar et al. , 2016)  is based on a tree to evaluate range queries over encrypted data, and uses Yao's garbled circuit to traverse the tree to respond to range queries. Whenever such a query is computed, nodes of the tree must be updated, which incurs complexity overhead at the user-side. Besides, the authors tested this solution on a NoSQL database, which does not store structured data as in MySQL or PostgreSQL. CryptDB. Proposed by  (Popa et al. , 2012) , this system allows equality, range and boolean queries over encrypted SQL databases, thanks to onion encryption, that encrypts each attribute with one or more onion layers. Each of the encryption layers preserves a particular functionality. For simple keyword search, CryptDB applies a deterministic encryption, disclosing to the server the occurrences of a particular keyword.
CONCLUSION This paper proposes an SSE scheme for SQL databases. The proposed solution builds upon the already existing searchable encryption proposed by Curtmola et al. (Curtmola et al. , 2006) , which is transformed to an SQL-compatible scheme. Our solution supports several query functionalities including range and Boolean queries. Fruthermore, thanks to the use of cuckoo hashing, the search operation becomes more efficient. We finally present a framework for implementation which embeds the search algorithm into PostgreSQL and that converts plain SQL queries into "encrypted" SQL queries directly executable by the Postgres server. This framework is evaluated in terms of performance using an e-health database. Our future work consists in developing an optimized system for databases with million of records.
a probabilistic algorithm executed by user U and, given a security parameter κ, outputs a secret key K. BuildIndex(D, K ) → I : This algorithm is run by user U to generate a search index. It takes key K and dataset D as inputs and outputs index I. When the execution of BuildIndex is completed, index I is stored at server S. Trapdoor(ω, K ) → τ ω : This algorithm, executed by user U, issues a search token, called trapdoor, to search for a given keyword ω. It takes secret key K and keyword ω as inputs and generates τ ω. This trapdoor allows the cloud to perform the search over the encrypted database for the corresponding keyword ω. Search(I , τ ω ) → D(ω): Run by server S, this algorithm processes the search query on ω and generates the search result. It takes index I and trapdoor τ ω as inputs and outputs D(ω), the list of identifiers of documents containing ω.
[pos i ] stores the address in array A of N i,1 and the key k i,0. Therefore, τ ω consists of two values: pos = π(K π , ω) and K ω = ϕ(K ϕ , ω). Search(I , τ ω ) → D(ω): As depicted in Algorithm 2, this algorithm parses τ ω as pos and K ω. Then it locates entry T [pos] and XOR-decrypts it using K ω. It obtains the address in array A of N i,1 and the key k i,0. Starting from N i,1 , algorithm Search can decrypt all the nodes N i, j , 1 ≤ j ≤ |L i | of L i. Finally, the algorithm outputs the list D(ω i ). If one of these steps fails, then algorithm Search aborts and indicates that the keyword was not found. Algorithm 1: I ← BuildIndex(D, K ). Inputs : Database D, Secret Key K Output: Index I 1 Create dictionary W 2 for ω i ∈ W do determine D(ω i ) 3 Set global counter ctr = 1 // Array A creation 5 Initialize an empty array A of size m 6 for ω i ∈ W do // Build a linked list L i with nodes N i, j 7 Generate random key k i,0 8 for 1 ≤ j ≤ |D(ω i )| do 9 Generate random key k i, j 10.