Searcharxiv⌕ Search

arXiv subjects

Srivatsan Ravi

Publications and source records attributed to Srivatsan Ravi.

At least 37 records · Page 2Linked to original sources

Secure Neuroimaging Analysis using Federated Learning with Homomorphic Encryption

Federated learning (FL) enables distributed computation of machine learning models over various disparate, remote data sources, without requiring to transfer any individual data to a centralized location. This results in an improved generalizability of models and efficient scaling of computation as more sources and larger datasets are added to the federation. Nevertheless, recent membership attacks show that private or sensitive personal data can sometimes be leaked or inferred when model parameters or summary statistics are shared with a central site, requiring improved security solutions. In this work, we propose a framework for secure FL using fully-homomorphic encryption (FHE). Specifically, we use the CKKS construction, an approximate, floating point compatible scheme that benefits from ciphertext packing and rescaling. In our evaluation on large-scale brain MRI datasets, we use our proposed secure FL framework to train a deep learning model to predict a person's age from distributed MRI scans, a common benchmarking task, and demonstrate that there is no degradation in the learning performance between the encrypted and non-encrypted federated models.

cs.CR↗

AMPPERE: A Universal Abstract Machine for Privacy-Preserving Entity Resolution Evaluation

Entity resolution is the task of identifying records in different datasets that refer to the same entity in the real world. In sensitive domains (e.g. financial accounts, hospital health records), entity resolution must meet privacy requirements to avoid revealing sensitive information such as personal identifiable information to untrusted parties. Existing solutions are either too algorithmically-specific or come with an implicit trade-off between accuracy of the computation, privacy, and run-time efficiency. We propose AMMPERE, an abstract computation model for performing universal privacy-preserving entity resolution. AMPPERE offers abstractions that encapsulate multiple algorithmic and platform-agnostic approaches using variants of Jaccard similarity to perform private data matching and entity resolution. Specifically, we show that two parties can perform entity resolution over their data, without leaking sensitive information. We rigorously compare and analyze the feasibility, performance overhead and privacy-preserving properties of these approaches on the Sharemind multi-party computation (MPC) platform as well as on PALISADE, a lattice-based homomorphic encryption library. The AMPPERE system demonstrates the efficacy of privacy-preserving entity resolution for real-world data while providing a precise characterization of the induced cost of preventing information leakage.

cs.CR↗

A Concurrency-Optimal List-Based Set

Designing an efficient concurrent data structure is an important challenge that is not easy to meet. Intuitively, efficiency of an implementation is defined, in the first place, by its ability to process applied operations in parallel, without using unnecessary synchronization. As we show in this paper, even for a data structure as simple as a linked list used to implement the set type, the most efficient algorithms known so far are not concurrency-optimal: they may reject correct concurrent schedules. We propose a new algorithm for the list-based set based on a value-aware try-lock that we show to achieve optimal concurrency: it only rejects concurrent schedules that violate correctness of the implemented set type. We show empirically that reaching optimality does not induce a significant overhead. In fact, our implementation of the concurrency-optimal algorithm outperforms both the Lazy Linked List and the Harris-Michael state-of-the-art algorithms.

cs.DC↗

Separation and Equivalence results for the Crash-stop and Crash-recovery Shared Memory Models

Linearizability, the traditional correctness condition for concurrent data structures is considered insufficient for the non-volatile shared memory model where processes recover following a crash. For this crash-recovery shared memory model, strict-linearizability is considered appropriate since, unlike linearizability, it ensures operations that crash take effect prior to the crash or not at all. This work formalizes and answers the question of whether an implementation of a data type derived for the crash-stop shared memory model is also strict-linearizable in the crash-recovery model. This work presents a rigorous study to prove how helping mechanisms, typically employed by non-blocking implementations, is the algorithmic abstraction that delineates linearizability from strict-linearizability. Our first contribution formalizes the crash-recovery model and how explicit process crashes and recovery introduces further dimensionalities over the standard crash-stop shared memory model. We make the following technical contributions: (i) we prove that strict-linearizability is independent of any known help definition; (ii) we then present a natural definition of help-freedom to prove that any obstruction-free, linearizable and help-free implementation of a total object type is also strict-linearizable; (iii) finally, we prove that for a large class of object types, a non-blocking strict-linearizable implementation cannot have helping. Viewed holistically, this work provides the first precise characterization of the intricacies in applying a concurrent implementation designed for the crash-stop model to the crash-recovery model, and vice-versa.

cs.DC↗

Programming Scalable Cloud Services with AEON

Designing low-latency cloud-based applications that are adaptable to unpredictable workloads and efficiently utilize modern cloud computing platforms is hard. The actor model is a popular paradigm that can be used to develop distributed applications: actors encapsulate state and communicate with each other by sending events. Consistency is guaranteed if each event only accesses a single actor, thus eliminating potential data races and deadlocks. However it is nontrivial to provide consistency for concurrent events spanning across multiple actors. This paper addresses this problem by introducing AEON: a framework that provides the following properties: (i) Programmability: programmers only need to reason about sequential semantics when reasoning about concurrency resulting from multi-actor events; (ii) Scalability: AEON runtime protocol guarantees serializable and starvation-free execution of multi-actor events, while maximizing parallel execution; (iii) Elasticity: AEON supports fine-grained elasticity enabling the programmer to transparently migrate individual actors without violating the consistency or entailing significant performance overheads. Our empirical results show that it is possible to combine the best of all the above three worlds without compromising on the application performance.

cs.DC↗

Concurrency and Privacy with Payment-Channel Networks

Permissionless blockchains protocols such as Bitcoin are inherently limited in transaction throughput and latency. Current efforts to address this key issue focus on off-chain payment channels that can be combined in a Payment-Channel Network (PCN) to enable an unlimited number of payments without requiring to access the blockchain other than to register the initial and final capacity of each channel. While this approach paves the way for low latency and high throughput of payments, its deployment in practice raises several privacy concerns as well as technical challenges related to the inherently concurrent nature of payments, such as race conditions and deadlocks, that have been understudied so far. In this work, we lay the foundations for privacy and concurrency in PCNs, presenting a formal definition in the Universal Composability framework as well as practical and provably secure solutions. In particular, we present Fulgor and Rayo. Fulgor is the first payment protocol for PCNs that provides provable privacy guarantees for PCNs and is fully compatible with the Bitcoin scripting system. However, Fulgor is a blocking protocol and therefore prone to deadlocks of concurrent payments as in currently available PCNs. Instead, Rayo is the first protocol for PCNs that enforces non-blocking progress (i.e., at least one of the concurrent payments terminates). We show through a new impossibility result that non-blocking progress necessarily comes at the cost of weaker privacy. At the core of Fulgor and Rayo is Multi-Hop HTLC, a new smart contract, compatible with the Bitcoin scripting system, that provides conditional payments while reducing running time and communication overhead with respect to previous approaches.

cs.CR↗

On the Cost of Concurrency in Hybrid Transactional Memory

State-of-the-art \emph{software transactional memory (STM)} implementations achieve good performance by carefully avoiding the overhead of \emph{incremental validation} (i.e., re-reading previously read data items to avoid inconsistency) while still providing \emph{progressiveness} (allowing transactional aborts only due to \emph{data conflicts}). Hardware transactional memory (HTM) implementations promise even better performance, but offer no progress guarantees. Thus, they must be combined with STMs, leading to \emph{hybrid} TMs (HyTMs) in which hardware transactions must be \emph{instrumented} (i.e., access metadata) to detect contention with software transactions. We show that, unlike in progressive STMs, software transactions in progressive HyTMs cannot avoid incremental validation. In fact, this result holds even if hardware transactions can \emph{read} metadata \emph{non-speculatively}. We then present \emph{opaque} HyTM algorithms providing \emph{progressiveness for a subset of transactions} that are optimal in terms of hardware instrumentation. We explore the concurrency vs. hardware instrumentation vs. software validation trade-offs for these algorithms. Our experiments with Intel and IBM POWER8 HTMs seem to suggest that (i) the \emph{cost of concurrency} also exists in practice, (ii) it is important to implement HyTMs that provide progressiveness for a maximal set of transactions without incurring high hardware instrumentation overhead or using global contending bottlenecks and (iii) there is no easy way to derive more efficient HyTMs by taking advantage of non-speculative accesses within hardware.

cs.DC↗

Merge: An Architecture for Interconnected Testbed Ecosystems

In the cybersecurity research community, there is no one-size-fits-all solution for merging large numbers of heterogeneous resources and experimentation capabilities from disparate specialized testbeds into integrated experiments. The current landscape for cyber-experimentation is diverse, encompassing many fields including critical infrastructure, enterprise IT, cyber-physical systems, cellular networks, automotive platforms, IoT and industrial control systems. Existing federated testbeds are constricted in design to predefined domains of applicability, lacking the systematic ability to integrate the burgeoning number of heterogeneous devices or tools that enable their effective use for experimentation. We have developed the Merge architecture to dynamically integrate disparate testbeds in a logically centralized way that allows researchers to effectively discover, and use the resources and capabilities provided the by evolving ecosystem of distributed testbeds for the development of rigorous and high-fidelity cybersecurity experiments.

cs.DC↗

Generalized Paxos Made Byzantine (and Less Complex)

One of the most recent members of the Paxos family of protocols is Generalized Paxos. This variant of Paxos has the characteristic that it departs from the original specification of consensus, allowing for a weaker safety condition where different processes can have a different views on a sequence being agreed upon. However, much like the original Paxos counterpart, Generalized Paxos does not have a simple implementation. Furthermore, with the recent practical adoption of Byzantine fault tolerant protocols, it is timely and important to understand how Generalized Paxos can be implemented in the Byzantine model. In this paper, we make two main contributions. First, we provide a description of Generalized Paxos that is easier to understand, based on a simpler specification and the pseudocode for a solution that can be readily implemented. Second, we extend the protocol to the Byzantine fault model.

cs.DC↗

A Concurrency-Optimal Binary Search Tree

The paper presents the first \emph{concurrency-optimal} implementation of a binary search tree (BST). The implementation, based on a standard sequential implementation of an internal tree, ensures that every \emph{schedule} is accepted, i.e., interleaving of steps of the sequential code, unless linearizability is violated. To ensure this property, we use a novel read-write locking scheme that protects tree \emph{edges} in addition to nodes. Our implementation outperforms the state-of-the art BSTs on most basic workloads, which suggests that optimizing the set of accepted schedules of the sequential code can be an adequate design principle for efficient concurrent data structures.

cs.DC↗

Why Transactional Memory Should Not Be Obstruction-Free

Transactional memory (TM) is an inherently optimistic abstraction: it allows concurrent processes to execute sequences of shared-data accesses (transactions) speculatively, with an option of aborting them in the future. Early TM designs avoided using locks and relied on non-blocking synchronization to ensure obstruction-freedom: a transaction that encounters no step contention is not allowed to abort. However, it was later observed that obstruction-free TMs perform poorly and, as a result, state-of-the-art TM implementations are nowadays blocking, allowing aborts because of data conflicts rather than step contention. In this paper, we explain this shift in the TM practice theoretically, via complexity bounds. We prove a few important lower bounds on obstruction-free TMs. Then we present a lock-based TM implementation that beats all of these lower bounds. In sum, our results exhibit a considerable complexity gap between non-blocking and blocking TM implementations.

cs.DC↗

In the Search of Optimal Concurrency

Implementing a concurrent data structure typically begins with defining its sequential specification. However, when used \emph{as is}, a nontrivial sequential data structure, such as a linked list, a search tree, or a hash table, may expose incorrect behavior: lost updates, inconsistent responses, etc. To ensure correctness, portions of the sequential code operating on the shared data must be "protected" from data races using synchronization primitives and, thus, certain schedules of the steps of concurrent operations must be rejected. But can we ensure that we do not "overuse" synchronization, i.e., that we reject a concurrent schedule only if it violates correctness? In this paper, we treat this question formally by introducing the notion of a \emph{concurrency-optimal} implementation. A program's concurrency is defined here as its ability to accept concurrent schedules, i.e., interleavings of steps of its sequential implementation. An implementation is concurrency-optimal if it accepts all interleavings that do not violate the program's correctness. We explore the concurrency properties of \emph{search} data structures which can be represented in the form of directed acyclic graphs exporting insert, delete and search operations. We prove, for the first time, that \emph{pessimistic} e.g., based on conservative locking) and \emph{optimistic serializable} e.g., based on serializable transactional memory) implementations of search data-structures are incomparable in terms of concurrency. Specifically, there exist simple interleavings of sequential code that cannot be accepted by \emph{any} pessimistic (and \emph{resp.}, serializable optimistic) implementation, but accepted by a serializable optimistic one (and \emph{resp.}, pessimistic). Thus, neither of these two implementation classes is concurrency-optimal.

cs.DC↗

Progressive Transactional Memory in Time and Space

Transactional memory (TM) allows concurrent processes to organize sequences of operations on shared \emph{data items} into atomic transactions. A transaction may commit, in which case it appears to have executed sequentially or it may \emph{abort}, in which case no data item is updated. The TM programming paradigm emerged as an alternative to conventional fine-grained locking techniques, offering ease of programming and compositionality. Though typically themselves implemented using locks, TMs hide the inherent issues of lock-based synchronization behind a nice transactional programming interface. In this paper, we explore inherent time and space complexity of lock-based TMs, with a focus of the most popular class of \emph{progressive} lock-based TMs. We derive that a progressive TM might enforce a read-only transaction to perform a quadratic (in the number of the data items it reads) number of steps and access a linear number of distinct memory locations, closing the question of inherent cost of \emph{read validation} in TMs. We then show that the total number of \emph{remote memory references} (RMRs) that take place in an execution of a progressive TM in which $n$ concurrent processes perform transactions on a single data item might reach $Ω(n \log n)$, which appears to be the first RMR complexity lower bound for transactional memory.

cs.DC↗

On the Cost of Concurrency in Transactional Memory

Traditional techniques for synchronization are based on \emph{locking} that provides threads with exclusive access to shared data. \emph{Coarse-grained} locking typically forces threads to access large amounts of data sequentially and, thus, does not fully exploit hardware concurrency. Program-specific \emph{fine-grained} locking or \emph{non-blocking} (\emph{i.e.}, not using locks) synchronization, on the other hand, is a dark art to most programmers and trusted to the wisdom of a few computing experts. Thus, it is appealing to seek a middle ground between these two extremes: a synchronization mechanism that relieves the programmer of the overhead of reasoning about data conflicts that may arise from concurrent operations without severely limiting the program's performance. The \emph{Transactional Memory (TM)} abstraction is proposed as such a mechanism: it intends to combine an easy-to-use programming interface with an efficient utilization of the concurrent-computing abilities provided by multicore architectures. TM allows the programmer to \emph{speculatively} execute sequences of shared-memory operations as \emph{atomic transactions} with \emph{all-or-nothing} semantics: the transaction can either \emph{commit}, in which case it appears as executed sequentially, or \emph{abort}, in which case its update operations do not take effect. Thus, the programmer can design software having only sequential semantics in mind and let TM take care, at run-time, of resolving the conflicts in concurrent executions. Intuitively, we want TMs to allow for as much \emph{concurrency} as possible: in the absence of severe data conflicts, transactions should be able to progress in parallel. But what are the inherent costs associated with providing high degrees of concurrency in TMs? This is the central question of the thesis.

cs.DC↗

Optimism for Boosting Concurrency

Modern concurrent programming benefits from a large variety of synchronization techniques. These include conventional pessimistic locking, as well as optimistic techniques based on conditional synchronization primitives or transactional memory. Yet, it is unclear which of these approaches better leverage the concurrency inherent to multi-cores. In this paper, we compare the level of concurrency one can obtain by converting a sequential program into a concurrent one using optimistic or pessimistic techniques. To establish fair comparison of such implementations, we introduce a new correctness criterion for concurrent programs, defined independently of the synchronization techniques they use. We treat a program's concurrency as its ability to accept a concurrent schedule, a metric inspired by the theories of both databases and transactional memory. We show that pessimistic locking can provide strictly higher concurrency than transactions for some applications whereas transactions can provide strictly higher concurrency than pessimistic locks for others. Finally, we show that combining the benefits of the two synchronization techniques can provide strictly more concurrency than any of them individually. We propose a list-based set algorithm that is optimal in the sense that it accepts all correct concurrent schedules. As we show via experimentation, the optimality in terms of concurrency is reflected by scalability gains.

cs.DC↗

Inherent Limitations of Hybrid Transactional Memory

Several Hybrid Transactional Memory (HyTM) schemes have recently been proposed to complement the fast, but best-effort, nature of Hardware Transactional Memory (HTM) with a slow, reliable software backup. However, the fundamental limitations of building a HyTM with nontrivial concurrency between hardware and software transactions are still not well understood. In this paper, we propose a general model for HyTM implementations, which captures the ability of hardware transactions to buffer memory accesses, and allows us to formally quantify and analyze the amount of overhead (instrumentation) of a HyTM scheme. We prove the following: (1) it is impossible to build a strictly serializable HyTM implementation that has both uninstrumented reads and writes, even for weak progress guarantees, and (2) under reasonable assumptions, in any opaque progressive HyTM, a hardware transaction must incur instrumentation costs linear in the size of its data set. We further provide two upper bound implementations whose instrumentation costs are optimal with respect to their progress guarantees. In sum, this paper captures for the first time an inherent trade-off between the degree of concurrency a HyTM provides between hardware and software transactions, and the amount of instrumentation overhead the implementation must incur.

cs.DC↗

On Partial Wait-Freedom in Transactional Memory

Transactional memory (TM) is a convenient synchronization tool that allows concurrent threads to declare sequences of instructions on shared data as speculative \emph{transactions} with "all-or-nothing" semantics. It is known that dynamic transactional memory cannot provide \emph{wait-free} progress in the sense that every transaction commits in a finite number of its own steps. In this paper, we explore the costs of providing wait-freedom to only a \emph{subset} of transactions. Since most transactional workloads are believed to be read-dominated, we require that read-only transactions commit in the wait-free manner, while updating transactions are guaranteed to commit only if they run in the absence of concurrency. We show that this kind of partial wait-freedom, combined with attractive requirements like read invisibility or disjoint-access parallelism, incurs considerable complexity costs.

cs.DC↗

On the Cost of Concurrency in Transactional Memory

The crux of software transactional memory (STM) is to combine an easy-to-use programming interface with an efficient utilization of the concurrent-computing abilities provided by modern machines. But does this combination come with an inherent cost? We evaluate the cost of concurrency by measuring the amount of expensive synchronization that must be employed in an STM implementation that ensures positive concurrency, i.e., allows for concurrent transaction processing in some executions. We focus on two popular progress conditions that provide positive concurrency: progressiveness and permissiveness. We show that in permissive STMs, providing a very high degree of concurrency, a transaction performs a linear number of expensive synchronization patterns with respect to its read-set size. In contrast, progressive STMs provide a very small degree of concurrency but, as we demonstrate, can be implemented using at most one expensive synchronization pattern per transaction. However, we show that even in progressive STMs, a transaction has to "protect" (e.g., by using locks or strong synchronization primitives) a linear amount of data with respect to its write-set size. Our results suggest that looking for high degrees of concurrency in STM implementations may bring a considerable synchronization cost.

cs.DC↗