dataesr/scientific-paragraphs-categorization huggingface dataset:
Unprotected implementation results In this section, we provide first results of optimized (unprotected) implementations of Spook. Our main objective is to demonstrate that even in this disadvantageous context (which does not take advantage of leveled implementations), Spook has excellent performance figures on a wide range of platforms. In particular, the overheads (in hardware area and embedded software code size) due to the use of two different primitives are shown to be limited thanks to the possibility to share resources (i. e. , S-boxes and L-boxes).
Software implementations The structure of the (m)LS-design primitives with 32-bit row length makes them very easy to implement on 32-bit platforms. The naive implementation provided in the reference implementation of Spook (see https://www. spook. dev/) is already quite efficient, and the optimized implementations keep the same structure. This implementation is based on storing each row of the (m)LS-designs as a machine word. The L-box is then implemented using rotations and XORs, the S-box in a bitslice fashion (4 ANDs and 4 XORs for a full LS state), and the D-box takes another 24 XORs for the full mLS state. We focus on two kinds of platforms: high-end (x86_64 with SIMD instructions) and embedded targets (ARM Cortex-M/RISC-V). For portability, we use as much as possible standard C code (with a few common compiler extensions).
First, we explored the use of 128-bit words, used as 4 times 32 bits, where each 32-bit sub-word is associated to one bundle. The full Shadow-512 state is thus four 128-bit words, one for each row. S-boxes and L-boxes are then easily implemented (using bitwise XORs and ANDs, and 32-bit rotations). The D-box is more challenging to implement, since it mixes sub-words from the same 128-bit word. We do it by using the shuffle primitive, requiring 12 shuffles and 8 XORs for the full 512-bit D-box. The implementation is written using only C code without platform-specific instrinsics, thanks to the vector compiler extension supported by GCC and Clang. We explored implementations of Shadow-512 with larger word sizes. We considered the use of 256-bit AVX2 and 512-bit AVX512 instructions, but this does not translate into significant practical gains.
Embedded Software (ARM Cortex/ RISC-V) The code of our embedded software implementations is written in C with minor changes compared to the reference implementation, chosen to optimize the assembly code generated by the compiler. The round constants are not stored in memory but derived from an LFSR to reduce the code size. The three tweakeys are pre-computed: at each round, the correct one is loaded according to the round index modulo three. In order to avoid (sometimes costly) arithmetic operations, the later is performed by hard-coding a value 0x924 at the beginning of each encryption, which is then right-shifted by two at the end of each round so that its lower bits always correspond to the round index modulo 3. The performances obtained with optimization flags set for reduced code size and maximum speed are given in Tables  7  and 8.
Tweak proposals While the analysis of [DHL + 20] does not target the full Spook AEAD, it exploits two design choices in Shadow that may be improved with simple changes: (i) the round constants are sparse and affect only one S-Box per bundle, and (ii) the branch number of D is only 4. In Section 7. 1, we discuss tweaks that strengthen Shadow. Our rationale is that they should increase the security more efficiently than a direct increase of the number of rounds. Next, in Section 7. 2, we discuss additional tweaks to improve performances, based on the finer-grain understanding of software and hardware implementations that the previous section enables. We conclude this section by proposing Spook v2, a variation of Spook improving its security margins at the cost of minimum performance overheads.
Improving efficiency The original constant addition of Shadow adds a single-bit constant to the four 32-bit words of each bundle. This limits the efficiency for software implementations, as each touched word requires a fixed amount of operations independently of the actual number of bits of the constant. By grouping constant additions to fewer state words, the execution time of Spook on microprocessors can decrease by more than 10 % while at the same time enabling denser constants. New constants for Shadow taking advantage of this observation are as follows: for the round A, a constant word is added to the second row of each bundle (so that we need four 32-bit constants for Shadow-512 and three ones are for Shadow-384); for the round B, a constant word is added to all the rows of the first bundle.
Spook v2 and performance overheads The Spook v2 proposal combines the two improvements presented above for Shadow (Clyde-128 is left unchanged). It reaches similar performances as Spook v1: the cost increase due to the MDS D-box is compensated by the cost reduction due to the change of constants. For completeness, we refer to Appendix G for updated figures and details about the Spook v2 design, and to Appendix H for software and hardware implementation figures.
H. 1 Software implementations For high-end platforms, the D-box change has the most significant impact (since it requires to transpose the Shadow state when viewed as a 4x4 matrix of 32-bit words), while the impact of the change of constants remains small since these constants are pre-computed anyway (and loads use different computing resources than the main computation). Overall, Spook v2 increases the cost by up to 22% on the selected platform. For embedded platforms, Spook v2 either increases slightly (up to 2. 5%) or reduces (up to 19%) the cost of software implementations, depending on the platorm and optimisation target. This is the combination of the cost increase of the D-box and the cost reduction of the constants, while the initialization change has no performance impact. We note that in the case of size-optimized code, Spook v2 is faster on all the considered platforms.
Acknowledgments. The authors are grateful to  Patrick Derbez ,  Paul Huynh ,  Virginie Lallemand ,  Léo Perrin ,  Maria Naya Plasencia  and  Andre Schrottenloher  for sharing their analysis of Shadow and Spook and discussing tweaks. We specially thank  Maria Naya Plasencia  for numerous interactions. Gaëtan Cassiers ,  Thomas Peters  and  François-Xavier Standaert  are respectively PhD Student, Post-Doctoral Researcher and  Senior Research Associate of the Belgian Fund for Scientific Research (FNRS-F. R. S. ). This work has been funded in part by  European Union  and the  Walloon Region  through the  ERC  Project  724725  (acronym SWORD), the  FEDER  Project  USERMedia  (convention  501907-379156 ), the  H2020  project  REASSURE  and the Wallinov  TRUSTEYE  project.
I. INTRODUCTION The Internet of Things (IoT) has received much attention in the last decade. A collection of controllers, actuators and sensors allows cyber physical systems (CPS,  [1] ) to take smart decisions. For instance, a smart building is able to limit its carbon footprint by adapting its heating system to both occupancy fluctuations and actual temperatures reported in each part of the building  [2]. IoT applications rely on filtering and aggregation operations to extract relevant information from the large number of sensors and data generated. While usual approaches assume that the raw data is directly pushed to a cloud infrastructure, we are convinced that this centralization jeopardizes the network scalability, and creates privacy concerns as a single external actor concentrates all the data.
In contrast, edge computing brings processing operations closer to the producers, to reduce the network load, and the latency  [3]. Such approaches are also promising to enforce data privacy needs since in-network processing may help to ensure some level of anonymity. In the same vein, data centric approaches such as Named Data Networking (NDN)  [4]  have raised considerable attention as a novel communication paradigm for IoT networks. In this context, IoT applications can indeed naturally benefit from features such as semantic requests and in-network caching. Additionally, named function networking  [5]  represents a pioneering piece of work to provide in-network processing. This novel paradigm allows consumers to insert lambda expressions directly in their requests such that NDN routers are then in charge of both retrieving data and computing the desired expression.
Currently, most complex CPS rely on multiple domains with different owners, that may accept to share some of their data only to other trusted domains. In theory, data may be ciphered between domains. However, sharing data among multiple domains rely on access control rules that are very complex to manage. Without a full knowledge of the different stakeholders, it is particularly challenging to deploy in practice. Thus, we rather aim to rely on NDN border routers that filter and pre-process data-streams when they exit a domain. Streams can be transformed (e. g. aggregated and filtered) before leaving the network/Typically, when the interests of the customers concern simple operations like applying an average function on several datasets of the same kind, there exists an opportunity to apply these operations inside the network rather than letting customers perform them on their own.
In this paper, we focus on this multi-domains IoT scenario. We re-use here our previous framework  [6] : we proposed to extend the NDN paradigm by including aggregation functionalities in border routers in order to provide privacy as well as improving the network performance. We extend it to handle any kind of transformation on the top of an overlay of border routers. The contributions of this paper are as follows: 1) we propose an overlay of NDN aware border routers interconnecting multiple IoT domains. They exchange their anonymized datasets on the basis of a simple policybased inter-domain routing protocol. Such policies define control plane exporting rules that describe which data stream can be exported and how; 2) we define how to implement in-network transformations in the data plane.
Data-streams can be aggregated and filtered before exiting a domain. Privacy rules defined in the exporting policies are efficiently enforced using in-network caching; 3) we implement our transformation based NDN overlay in NS3 to evaluate its benefits and performance. In particular, we show how the opportunity to transform, aggregate and reuse popular data allows to improve scalability while enforcing privacy by design. 978-1-7281-8326-8/20/$31. 00 ©2020 IEEE.
II. RELATED WORK Privacy has always been a key challenge for IoT. Packets may be ciphered, but it requires to pre-deploy and manage keys, which is a challenging task in complex large scale dynamic environments  [7]. We focus in this paper on multidomain IoT applications, where pre-shared keys and global access control schemes are not practically feasible. Privacy can typically be preserved for IoT streams by applying masking operations (e. g. , attribute removal, accuracy reduction, and entry removal) to respect quantifiable privacy metrics  [8]. A K-anonymous dataset guarantees that it is impossible to use attributes to distinguish any entry from K -1 other entries. Similarly, -differential  [9]  guarantees that multiple disclosures of the same data set are sufficiently similar to prevent data interpolation.
A. Named Data Networking (NDN) NDN is a clean-slate approach to the current Internet stack, which fits very well the needs for IoT application to handle and directly forward pieces of data. Hierarchical names replace numerical addresses and enable semantic requests, prefix-based routing, and route aggregation  [4]. Consumers create interest packets, that describe with names the information they search for. This interest is then forwarded according to the prefix name specified in the interest. Every router can cache the data it forwards in its Content Store. In that way, a router can use this cache to reply directly to any novel interest that matches the same piece of data. A signature mechanism allows each piece of data to be authenticated, i. e. , a router cannot forge a chunk of data by its own.
Unfortunately, some IoT requirements are not supported natively by NDN. For instance, a consumer may be interested in any measurement in a given geographical area (e. g. , a temperature anywhere inside a building), which is not supported natively by NDN. Ascigil et al. [10]  proposes a keywordbased approach but this work does not support the acquisition of large datasets aggregated from multiple domains. Additionally, IoT applications often rely on streams of data  [11]. Thus, subscription-based mechanisms  [12]  have been proposed to extend NDN; persistent pending interest table entries are employed to allow the association of multiple data packets of a given stream to the same interest. We employ this approach to ease IoT stream re-usability.
III. A NDN MULTI-DOMAIN OVERLAY FOR PRIVACY We re-use here the terminology that we have already defined in  [6] : a domain represents a collection of devices that are possessed and administrated by the same owner (e. g. , a smart home) or involved in the same system (e. g. , heating); a data stream is a continuous flow of data generated by a producer, e. g. , a temporal sequence of measurements; a dataset represents a data stream that a domain accepts to export, with its characteristics encoded as metadata (providing its nature and cardinality in particular). For instance, a domain may export the average energy consumption for 10,000 smart meters, in flats with 4 inhabitants. To enable the exchange of datasets between multiple domains, we propose to construct an overlay of border routers. A border router is basically in charge of defining what data can be exported to respect a set of privacy requirements (defined by the owner or administrator of the domain).
The overlay connecting them is a logical topology, built on the top of the peering relations between domains. Typically, a border router defines which data it accepts to share with its peers: it defines the exporting policies attached to each of the dataset it exports. We model privacy requirements (aka. exporting policy) as a collection of (anonymization) transformations that must be applied to the exported dataset. For instance, a border router may filter and aggregate a dataset before it exits the domain. It consist, respectively, in removing personal data that can lead to any kind of identification and sending only the average value to further obfuscate precise data. We also make a distinction between direct peers, that can trust each others, and the rest of the network, reached transitively, where additional transformations may be enforced.
Fig. 1 : Overlay on top of multiple domains. This overlay forms a logical tree for a given dataset (here customers in domain4 can directly access the entire set of producers). Note that transformations based on data aggregation is at the core of our multi-domain architecture  [6]. Indeed, such an aggregation not only hides individual data streams to respect privacy but also allows for scalability. Let us consider Figure  1 : each domain has a border router in charge of exporting and importing data from/to outside. Typically, the overlay forms a tree due to the consumer-producer relationships between domains, e. g. , R4 is for instance a consumer for domain2, and a producer for domain3. Here R4 aggregates the data from two domains (domain1 and domain2 being here leafs of the tree). Such a tree is enough to capture well existing commercial relationship among domains.
For example, a subscriber sends its electricity consumption to its electricity provider, that resells the anonymized set of data to a broker. Finally, the broker aggregates the data from different electricity providers to sell a large dataset to R&D / marketing / commercial entities. Besides, a tree structure prevents by design the occurrence of loops in the acquisition and transformation of data; indeed they may result in inconsistencies such as averaging the same data multiple times. We choose to implement this overlay relying on the Named Data Networking (NDN) paradigm. This clean-slate approach is particularly relevant for IoT applications as a NDN router manipulates chunks of data and not anymore opaque packets. Data can be cached in the network to reduce the volume of packets to transmit when multiple consumers are interested in the same popular data  [12].
Typically, two or more consumers subscribing to the same dataset exported by a domain, will receive the same continuous flow of data in a multicast fashion. We also expand NDN cache mechanisms to detect overlapping dataset. Indeed, the sequence of transformations for two exiting data-streams may be partially overlapping. In that case, the border router detects the overlaps and uses its Content Store to save transmissions. Our tree-based overlay defines the underlying control plane of our simple but efficient NDN routing scheme. Forks in such a structure actually emerge at the data-plane when a given NDN interest is decomposed into multiples because the necessary number of samples (the dataset cardinality) cannot be achieved considering only one child in the tree. We let the definition of more flexible and sophisticated routing schemes, using graph construct less strict than a single directed tree per dataset, for future work.
A. Border Routers In each domain, at least one border router is in charge of defining what data may be exported, where and how. In other words, each border routers is a door for any data stream to/from the outside: it represents the key location to control privacy but also to enable re-usability. To fulfill its functions, each border router maintains peering (point-to-point) connections with a selected set of other border routers, which are part of different domains. To favor flexibility and enable the incremental deployment of relations between domains, border routers can form an overlay on top of the physical network, as illustrated in Fig. 1. This NDN overlay is a logical topology deployed on top of the physical one. A domain first decides whether it aims to expose a portion of its data to its peering border routers.
In other words, it accepts (or not) to reply to NDN interests that it receives from its peers. A peering border router can aggregate several datasets to form a novel one, exported to its peering domains. Globally, this overlay forms a directed tree that may not match the physical topology. In Figure  1 , an arrow (A → B) in the overlay represents the dataset export between domains A and B. The direction of a link describes the relationship between domains: A provides a (possibly aggregated) dataset with a given semantic, granularity, and cardinality to domain B. For instance, let us assume that R2 and R4 are peers: while they are connected with a tunnel which consists in the physical path (R2, R3, R4) (one of the two best shortest path between them), R2 provides its dataset to R4 that can then share it with R3 (along with the dataset of R1 -having the same semantic).
B. Policy engine We exploit an overlay of border routers, where each domain selects what data it accepts to export, and with which (trusted) peering domain(s). The data that exits a domain may have been generated locally or received from another domain, indistinctly. In particular, a border router may aggregate several data-streams for an anonymization purpose. The novel aggregated stream can then be reused to answer several interests. The policy engine is in charge of defining policies and exporting them to peering domains. More precisely, each border router associates a set of transformations to each of its dataset (e. g. , all temperature measurements). Then, border routers push each policy to its peers, denoting characteristics of the datasets that can be shared, e. g. their size, the nature of their content, and the applied and requested transformations.
List of usages: usages that are authorized by the owner (commercial, market, research, etc). Nowadays, most data owners consent to only some specific usages of their data  [19]. Usages correspond typically to keywords (see  [10] ), appended in the metadata. Blacklist: for the same reason, a list of domains may be prohibited. These domains cannot access concerned data as long as the trust between peers is not violated. Transformations: how the data should be transformed before being exported (i. e. , which mathematical transformation with which parameters). The applied sequence of transformations provides privacy guarantees. Typically, the policy engine associates an exporting policy to each available dataset (cf. Fig. 2 ), and the border routers enforce the policies. In other words, a peer receives an interest only if its dataset complies with the policies defined in the interest.
C. Routing engine The overlay of border routers is used when external data is required to be exchanged with other domains. For example, when an application needs a large volume of data, e. g. information from numerous producers aggregated in a large stream, multiple domains will be solicited. 1) Interest and subscription through the overlay: The routing engine (which is implemented in the border router) is in charge of receiving and handling interests (Fig. 2 ). In our proposal, each interest is composed of the dataset description with the desired chain of transformations. In addition, the usage and the consumer domain are appended to the interests' parameters to check compliance with privacy policies. We also append transformations and parameters natively to the name of the interests so that (transformed) data-streams can be distinguished from each other.
We encode this by embedding each transformation into a name component, e. g. , /Producer-Name/DataSet/$average?every=5minutes. The exact naming for transformations and parameters are left as a open issue but some form of unified semantics has to be used. If the data to answer a given interest is not available in its content store, the routing engine has to ask a peering border routers. First, it asks the policy engine all the datasets it knows (characteristics, imported policies). Then, it selects a sufficient collection of datasets to answer the interest (that maps to a collection of peers). In Figure  2 , the consumer (in Domain4) asks its policy engine for the list of datasets it knows. Here, the border router forwards the interest to Domain3, which has exported the policy corresponding to the requested data.
The border router of Domain3 receives the interest, and solicits its policy engine: the two datasets from Domain1 and Domain2 are required to form an aggregated data stream (to respect for instance a minimum number of measurements). Thus, in such a case, it forwards the initial interest to its two peers via their border routers. Note that it modifies the initial interest packet by adapting the parameter describing the number of measurements in the two (sub-)interests it relays. Fig. 2 : An overall illustration of our multi-domain overlay solution with all its components. 2) Policy enforcement: When the routing engine receives an interest, it has to verify that it is authorized to answer. In other words, it has to verify that the resulting data stream respects the exporting policy. Thus, it asks the policy engine the list of policies in its domain and verifies that a dataset is compliant with the interest.