• Documents
  • Authors
  • Tables
  • Log in
  • Sign up
  • MetaCart
  • DMCA
  • Donate

CiteSeerX logo

Advanced Search Include Citations
Advanced Search Include Citations | Disambiguate

Proactive Recovery in a Byzantine-Fault-Tolerant System (2000)

by Miguel Castro, Barbara Liskov
Add To MetaCart

Tools

Sorted by:
Results 1 - 10 of 138
Next 10 →

Small Byzantine Quorum Systems

by Jean-Philippe Martin, Lorenzo Alvisi, Michael Dahlin - DISTRIBUTED COMPUTING , 2001
"... In this paper we present two protocols for asynchronous Byzantine Quorum Systems (BQS) built on top of reliable channels---one for self-verifying data and the other for any data. Our protocols tolerate Byzantine failures with fewer servers than existing solutions by eliminating nonessential work in ..."
Abstract - Cited by 468 (49 self) - Add to MetaCart
In this paper we present two protocols for asynchronous Byzantine Quorum Systems (BQS) built on top of reliable channels---one for self-verifying data and the other for any data. Our protocols tolerate Byzantine failures with fewer servers than existing solutions by eliminating nonessential work in the write protocol and by using read and write quorums of different sizes. Since engineering a reliable network layer on an unreliable network is difficult, two other possibilities must be explored. The first is to strengthen the model by allowing synchronous networks that use time-outs to identify failed links or machines. We consider running synchronous and asynchronous Byzantine Quorum protocols over synchronous networks and conclude that, surprisingly, "self-timing" asynchronous Byzantine protocols may offer significant advantages for many synchronous networks when network time-outs are long. We show how to extend an existing Byzantine Quorum protocol to eliminate its dependency on reliable networking and to handle message loss and retransmission explicitly.
(Show Context)

Citation Context

... tolerate a given number of failures than previously possible. Reducing the required number of servers is particularly important where Byzantine protocols protect againstsecurity breaches of servers =-=[8, 9, 25, 39]-=-. Note that using Byzantine protocols to tolerate security breaches is sound only if server failures are independent, i.e. if breaking into one server does not increase the probability of successfully...

Plutus: Scalable secure file sharing on untrusted storage

by Mahesh Kallahalla, Erik Riedel, Ram Swaminathan, Qian Wang, Kevin Fu , 2003
"... Plutus is a cryptographic storage system that enables secure file sharing without placing much trust on the file servers. In particular, it makes novel use of cryptographic primitives to protect and share files. Plutus features highly scalable key management while allowing individual users to retain ..."
Abstract - Cited by 229 (2 self) - Add to MetaCart
Plutus is a cryptographic storage system that enables secure file sharing without placing much trust on the file servers. In particular, it makes novel use of cryptographic primitives to protect and share files. Plutus features highly scalable key management while allowing individual users to retain direct control over who gets access to their files. We explain the mechanisms in Plutus to reduce the number of cryptographic keys exchanged between users by using filegroups, distinguish file read and write access, handle user revocation efficiently, and allow an untrusted server to authorize file writes. We have built a prototype of Plutus on OpenAFS. Measurements of this prototype show that Plutus achieves strong security with overhead comparable to systems that encrypt all network traffic.
(Show Context)

Citation Context

...ne, however, cannot prevent destruction of data by a malicious server. Replication on multiple servers can ensure preservation of data even when many of the servers are malicious. Systems such as BFS =-=[7]-=-, Farsite [1], OceanStore [25], PASIS [17], PAST [12], and S4 [47] address techniques for secure availability through replication. Though, in this paper, we restrict our focus to securing data on a si...

Pond: the OceanStore Prototype

by Sean Rhea, Patrick Eaton, Dennis Geels, Hakim Weatherspoon, Ben Zhao, John Kubiatowicz , 2003
"... OceanStore is an Internet-scale, persistent data store designed for incremental scalability, secure sharing, and long-term durability. Pond is the OceanStore prototype; it contains many of the features of a complete system including location-independent routing, Byzantine update commitment, push-bas ..."
Abstract - Cited by 222 (18 self) - Add to MetaCart
OceanStore is an Internet-scale, persistent data store designed for incremental scalability, secure sharing, and long-term durability. Pond is the OceanStore prototype; it contains many of the features of a complete system including location-independent routing, Byzantine update commitment, push-based update of cached copies through an overlay multicast network, and continuous archiving to erasure-coded form. In the wide area, Pond outperforms NFS by up to a factor of 4.6 on readintensive phases of the Andrew benchmark, but underperforms NFS by as much as a factor of 7.3 on writeintensive phases. Microbenchmarks show that write performance is limited by the speed of erasure coding and threshold signature generation, two important areas of future research. Further microbenchmarks show that Pond manages replica consistency in a bandwidthefficient manner and quantify the latency cost imposed by this bandwidth savings.
(Show Context)

Citation Context

...heck update predicates, and sign a heartbeat for each new version. To construct this primary replica in a fault-tolerant manner, we adapt a Byzantine agreement protocol developed by Castro and Liskov =-=[4]-=-. Byzantine agreement is a distributed decision process in which all non-faulty participants reach the same decision as long as more than two-thirds of the participants follow the protocol correctly. ...

Fast and secure distributed read-only file system

by Kevin Fu, M. Frans Kaashoek, David Mazieres , 2007
"... ..."
Abstract - Cited by 207 (19 self) - Add to MetaCart
Abstract not found

Hail: A high-availability and integrity layer for cloud storage,” in

by Kevin D Bowers , Ari Juels , Alina Oprea - Proc. Of CCS’09, , 2009
"... ABSTRACT We introduce HAIL (High-Availability and Integrity Layer), a distributed cryptographic system that allows a set of servers to prove to a client that a stored file is intact and retrievable. HAIL strengthens, formally unifies, and streamlines distinct approaches from the cryptographic and d ..."
Abstract - Cited by 195 (4 self) - Add to MetaCart
ABSTRACT We introduce HAIL (High-Availability and Integrity Layer), a distributed cryptographic system that allows a set of servers to prove to a client that a stored file is intact and retrievable. HAIL strengthens, formally unifies, and streamlines distinct approaches from the cryptographic and distributed-systems communities. Proofs in HAIL are efficiently computable by servers and highly compact-typically tens or hundreds of bytes, irrespective of file size. HAIL cryptographically verifies and reactively reallocates file shares. It is robust against an active, mobile adversary, i.e., one that may progressively corrupt the full set of servers. We propose a strong, formal adversarial model for HAIL, and rigorous analysis and parameter choices. We show how HAIL improves on the security and efficiency of existing tools, like Proofs of Retrievability (PORs) deployed on individual servers. We also report on a prototype implementation.
(Show Context)

Citation Context

..., which has yielded protocols resilent to mobile adversaries for secret sharing [23, 7] as well as signature schemes [22]. Proactive recovery has been proposed for the BFT system by Castro and Liskov =-=[10]-=-. Their system constructs a replicated state machine that tolerates a third of faulty replicas in a window of vulnerability, but any number of faults over the lifetime of the system. In previous proac...

Zyzzyva: Speculative byzantine fault tolerance

by Ramakrishna Kotla, Lorenzo Alvisi, Mike Dahlin, Allen Clement, Edmund Wong - In Symposium on Operating Systems Principles (SOSP , 2007
"... We present Zyzzyva, a protocol that uses speculation to reduce the cost and simplify the design of Byzantine fault tolerant state machine replication. In Zyzzyva, replicas respond to a client’s request without first running an expensive three-phase commit protocol to reach agreement on the order in ..."
Abstract - Cited by 188 (16 self) - Add to MetaCart
We present Zyzzyva, a protocol that uses speculation to reduce the cost and simplify the design of Byzantine fault tolerant state machine replication. In Zyzzyva, replicas respond to a client’s request without first running an expensive three-phase commit protocol to reach agreement on the order in which the request must be processed. Instead, they optimistically adopt the order proposed by the primary and respond immediately to the client. Replicas can thus become temporarily inconsistent with one another, but clients detect inconsistencies, help correct replicas converge on a single total ordering of requests, and only rely on responses that are consistent with this total order. This approach allows Zyzzyva to reduce replication overheads to near their theoretical minima.

COCA: A Secure Distributed Online Certification Authority

by Lidong Zhou, Fred B. Schneider, Robbert Van Renesse - ACM TRANSACTIONS ON COMPUTER SYSTEMS , 2002
"... ..."
Abstract - Cited by 175 (7 self) - Add to MetaCart
Abstract not found

Separating agreement from execution for byzantine fault tolerant services

by Jian Yin, Jean-Philippe Martin, Arun Venkataramani, Lorenzo Alvisi, Mike Dahlin - IN PROC. SOSP , 2003
"... We describe a new architecture for Byzantine fault tolerant state machine replication that separates agreement that orders requests from execution that processes requests. This separation yields two fundamental and practically significant advantages over previous architectures. First, it reduces rep ..."
Abstract - Cited by 161 (18 self) - Add to MetaCart
We describe a new architecture for Byzantine fault tolerant state machine replication that separates agreement that orders requests from execution that processes requests. This separation yields two fundamental and practically significant advantages over previous architectures. First, it reduces replication costs because the new architecture can tolerate faults in up to half of the state machine replicas that execute requests. Previous systems can tolerate faults in at most a third of the combined agreement/state machine replicas. Second, separating agreement from execution allows a general privacy firewall architecture to protect confidentiality through replication. In contrast, replication in previous systems hurts confidentiality because exploiting the weakest replica can be su#cient to compromise the system. We have constructed a prototype and evaluated it running both microbenchmarks and an NFS server. Overall, we find that the architecture adds modest latencies to unreplicated systems and that its performance is competitive with existing Byzantine fault tolerant systems.
(Show Context)

Citation Context

... by at least g+1 execution servers. In our protocol a reply certificate has the form: 〈REP LY, v, n, t, c, E, r〉E,c,g+1 1 Note that our message formats and protocol closely follow Castro and Liskov’s =-=[11, 12]-=-. where v was the view number in the agreement cluster when it assigned a sequence number to the request, n is the request’s sequence number, t is the request’s timestamp, c is the client’s identity, ...

Flashback: A Lightweight Extension for Rollback and Deterministic Replay for Software Debugging

by Sudarshan M. Srinivasan, Srikanth K, Christopher R. Andrews, Yuanyuan Zhou - In USENIX Annual Technical Conference, General Track , 2004
"... Unfortunately, finding software bugs is a very challenging task because many bugs are hard to reproduce. While debugging a program, it would be very useful to rollback a crashed program to a previous execution point and deterministically re-execute the "buggy " code region. However ..."
Abstract - Cited by 155 (7 self) - Add to MetaCart
Unfortunately, finding software bugs is a very challenging task because many bugs are hard to reproduce. While debugging a program, it would be very useful to rollback a crashed program to a previous execution point and deterministically re-execute the "buggy " code region. However, most previous work on rollback and replay support was designed to survive hardware or operating system failures, and is therefore too heavyweight for the fine-grained rollback and replay needed for software debugging. This paper presents Flashback, a lightweight OS extension that provides fine-grained rollback and replay to help debug software. Flashback uses shadow processes to efficiently roll back in-memory state of a process, and logs a process ' interactions with the system to support deterministic replay. Both shadow processes and logging of system calls are implemented in a lightweight fashion specifically designed for the purpose of software debugging. We have implemented a prototype of Flashback in the Linux operating system. Our experimental results with micro-benchmarks and real applications show that Flashback adds little overhead and can quickly roll back a debugged program to a previous execution point and deterministically replay from that point.

A Generalized Birthday Problem

by David Wagner - In CRYPTO , 2002
"... We study a k-dimensional generalization of the birthday problem: given k lists of n-bit values, nd some way to choose one element from each list so that the resulting k values xor to zero. For k = 2, this is just the extremely well-known birthday problem, which has a square-root time algorithm ..."
Abstract - Cited by 127 (0 self) - Add to MetaCart
We study a k-dimensional generalization of the birthday problem: given k lists of n-bit values, nd some way to choose one element from each list so that the resulting k values xor to zero. For k = 2, this is just the extremely well-known birthday problem, which has a square-root time algorithm with many applications in cryptography.
(Show Context)

Citation Context

... size of m, and so it is no surprise that some implementors have used inadequate parameters: for instance, NASD used a 256bit modulus [21, 22], and several implementations have used a 128-bit modulus =-=[13, 14, 45]-=-. Oursrst attack on the NASD hash applies to AdHash as well, so wesnd that AdHash's modulus m must be very large indeed: the asymptotic complexity of the k-sum problem is as low as O(2 2 p lg m ) if w...

Powered by: Apache Solr
  • About CiteSeerX
  • Submit and Index Documents
  • Privacy Policy
  • Help
  • Data
  • Source
  • Contact Us

Developed at and hosted by The College of Information Sciences and Technology

© 2007-2019 The Pennsylvania State University