Authenticated Byzantine Fault Tolerance Without Public-Key Cryptography
01 Dec 1999-
TL;DR: The optimization replaces public-key signatures by vectors of message authentication codes during normal operation, and it overcomes a fundamental limitation on the power of message Authentication codes relative to digital signatures — the inability to prove that a message is authentic to a third party.
Abstract: We have developed a practical state-machine replication algorithm that tolerates Byzantine faults: it works correctly in asynchronous systems like the Internet and it incorporates severaloptimizationsthatimprovetheresponsetimeofprevious algorithms by more than an order of magnitude. This paper describes the most important of these optimizations. It explains how to modify the base algorithm to eliminate the major performance bottleneck in previous systems — public-key cryptography. The optimization replaces public-key signatures by vectors of message authentication codes during normal operation, and it overcomes a fundamental limitation on the power of message authentication codes relative to digital signatures — the inability to prove that a message is authentic to a third party. As a result, authentication is more than two orders of magnitude faster while providing the same level of security.
Citations
More filters
22 Feb 1999
TL;DR: A new replication algorithm that is able to tolerate Byzantine faults that works in asynchronous environments like the Internet and incorporates several important optimizations that improve the response time of previous algorithms by more than an order of magnitude.
Abstract: This paper describes a new replication algorithm that is able to tolerate Byzantine faults. We believe that Byzantinefault-tolerant algorithms will be increasingly important in the future because malicious attacks and software errors are increasingly common and can cause faulty nodes to exhibit arbitrary behavior. Whereas previous algorithms assumed a synchronous system or were too slow to be used in practice, the algorithm described in this paper is practical: it works in asynchronous environments like the Internet and incorporates several important optimizations that improve the response time of previous algorithms by more than an order of magnitude. We implemented a Byzantine-fault-tolerant NFS service using our algorithm and measured its performance. The results show that our service is only 3% slower than a standard unreplicated NFS.
3,562 citations
Additional excerpts
...The modified algorithm is described in [5]....
[...]
28 Oct 2002
TL;DR: A new algorithm that uses a "Listeners" pattern of network communication to detect and resolve ordering ambiguities created by concurrent accesses to the system and provides atomic consistency semantics, which is stronger than the regular or pseudo-atomic semantics provided by these existing protocols.
Abstract: Byzantine fault-tolerant storage systems can provide high availability in hazardous environments, but the redundant servers they require increase software development and hardware costs. In order to minimize the number of servers required to implement fault-tolerant storage services, we develop a new algorithm that uses a "Listeners" pattern of network communication to detect and resolve ordering ambiguities created by concurrent accesses to the system. Our protocol requires 3f + 1 servers to tolerate up to f Byzantine faults--f fewer than the 4f + 1 required by existing protocols for non-self-verifying data. In addition, SBQ-L provides atomic consistency semantics, which is stronger than the regular or pseudo-atomic semantics provided by these existing protocols. We show that this protocol is optimal in the number of servers-- any protocol that provides safe semantics or stronger requires at least 3f + 1 servers to tolerate f Byzantine faults in an asynchronous system. Finally, we examine a non-confirmable writes variation of the SBQ-L protocol where a client cannot determine when its writes complete. We show that SBQ-L with non-confirmable writes provides regular semantics with 2f + 1 servers and that this number of servers is minimal.
177 citations
Additional excerpts
...3f+1, atomic [ 5 ]2 3f+1, atomic2 3f+1 for safe 3f+1, regular [12],[15]1; or stronger semantics con rmable, self-verifying 3f+1, atomic [13],[6]1;2 3f+1, atomic2 non-conrma ble, generic 3f+1, safe [15] 2f+1, regular2 2f+1 for safe non-conrmable , self-verifying 2f+1, regular [15] 2f+1, regular2 or stronger semantics...
[...]
14 Oct 2007
TL;DR: An erasure-coded Byzantine fault-tolerant block storage protocol that is nearly as efficient as protocols that tolerate only crashes and achieves throughput within 10% of the crash-tolerance protocol for writes and reads in failure-free runs.
Abstract: This paper presents an erasure-coded Byzantine fault-tolerant block storage protocol that is nearly as efficient as protocols that tolerate only crashes. Previous Byzantine fault-tolerant block storage protocols have either relied upon replication, which is inefficient for large blocks of data when tolerating multiple faults, or a combination of additional servers, extra computation, and versioned storage. To avoid these expensive techniques, our protocol employs novel mechanisms to optimize for the common case when faults and concurrency are rare. In the common case, a write operation completes in two rounds of communication and a read completes in one round. The protocol requires a short checksum comprised of cryptographic hashes and homomorphic fingerprints. It achieves throughput within 10% of the crash-tolerant protocol for writes and reads in failure-free runs when configured to tolerate up to 6 faulty servers and any number of faulty clients.
132 citations
Posted Content•
13 Jun 2019
TL;DR: Mir is a generalization of the celebrated and scrutinized PBFT protocol, with changes needed to accommodate novel features restricted to PBFT liveness, and achieves unprecedented throughput on WANs without sacrificing latency, robustness to malicious behavior, or even performance in clusters.
Abstract: This paper presents Mir-BFT (or, simply, Mir), a robust Byzantine fault-tolerant (BFT) total order broadcast protocol aimed at maximizing throughput on wide-area networks (WANs), targeting permissioned and Proof-of-Stake permissionless blockchains.
We show that Mir achieves unprecedented throughput on WANs without sacrificing latency, robustness to malicious behavior, or even performance in clusters. Our evaluation shows that Mir orders more than 60000 signed Bitcoin-sized transactions per second on a widely distributed 100 nodes, 1 Gbps WAN setup, while preventing a range of attacks including request duplication performance attacks.
To achieve this, Mir relies on a novel protocol mechanism that allows a set of leaders to propose request batches independently, in parallel, while rotating the assignment of a partitioned request hash space to leaders. Several optimizations boost Mir throughput even further, including partial replication through a novel abstraction we call light total order (LTO) broadcast.
Perhaps most importantly, Mir relies on proven BFT protocol constructs, which simplifies reasoning about Mir correctness. Specifically, Mir is a generalization of the celebrated and scrutinized PBFT protocol. In a nutshell, Mir follows PBFT ``safety-wise'', with changes needed to accommodate novel features restricted to PBFT liveness.
70 citations
Cites methods from "Authenticated Byzantine Fault Toler..."
...EPOCH-CHANGE message follows the structure of PBFT VIEW-CHANGE message (page 411, [23]) with the difference that it is signed and that there are no VIEW-CHANGE-ACK messages exchanged (to streamline and simplify the implementation similarly to [21])....
[...]
Book•
01 Jan 2007
TL;DR: Using web servers and web applications as running examples throughout, this comprehensive guide helps you manage risk due to insecure code and build trust with users by showing how to write code to prevent, detect, and contain attacks.
Abstract: Using web servers and web applications as running examples throughout, this comprehensive guide helps you manage risk due to insecure code and build trust with users by showing how to write code to prevent, detect, and contain attacks.
69 citations
References
More filters
TL;DR: An encryption method is presented with the novel property that publicly revealing an encryption key does not thereby reveal the corresponding decryption key.
Abstract: An encryption method is presented with the novel property that publicly revealing an encryption key does not thereby reveal the corresponding decryption key. This has two important consequences: (1) Couriers or other secure means are not needed to transmit keys, since a message can be enciphered using an encryption key publicly revealed by the intented recipient. Only he can decipher the message, since only he knows the corresponding decryption key. (2) A message can be “signed” using a privately held decryption key. Anyone can verify this signature using the corresponding publicly revealed encryption key. Signatures cannot be forged, and a signer cannot later deny the validity of his signature. This has obvious applications in “electronic mail” and “electronic funds transfer” systems. A message is encrypted by representing it as a number M, raising M to a publicly specified power e, and then taking the remainder when the result is divided by the publicly specified product, n, of two large secret primer numbers p and q. Decryption is similar; only a different, secret, power d is used, where e * d ≡ 1(mod (p - 1) * (q - 1)). The security of the system rests in part on the difficulty of factoring the published divisor, n.
14,659 citations
"Authenticated Byzantine Fault Toler..." refers background or methods in this paper
...The cryptographic techniques we use are thought to have these properties [28, 30, 27]....
[...]
...Our messages contain public-key signatures [28], message authentication codes [30], and message digests produced by collision-resistant hash functions [27]....
[...]
TL;DR: In this paper, the concept of one event happening before another in a distributed system is examined, and a distributed algorithm is given for synchronizing a system of logical clocks which can be used to totally order the events.
Abstract: The concept of one event happening before another in a distributed system is examined, and is shown to define a partial ordering of the events. A distributed algorithm is given for synchronizing a system of logical clocks which can be used to totally order the events. The use of the total ordering is illustrated with a method for solving synchronization problems. The algorithm is then specialized for synchronizing physical clocks, and a bound is derived on how far out of synchrony the clocks can become.
8,381 citations
TL;DR: In this paper, it is shown that every protocol for this problem has the possibility of nontermination, even with only one faulty process.
Abstract: The consensus problem involves an asynchronous system of processes, some of which may be unreliable The problem is for the reliable processes to agree on a binary value In this paper, it is shown that every protocol for this problem has the possibility of nontermination, even with only one faulty process By way of contrast, solutions are known for the synchronous case, the “Byzantine Generals” problem
4,389 citations
"Authenticated Byzantine Fault Toler..." refers background in this paper
...) This is a rather weak synchrony assumption that is likely to be true in any real system provided network faults are eventually repaired, yet it enables us to circumvent the impossibility result in [9]....
[...]
...Therefore, it must rely on synchrony to provide liveness; otherwise it could be used to implement consensus in an asynchronous system, which is not possible [9]....
[...]
Book•
01 Jan 1996
TL;DR: This book familiarizes readers with important problems, algorithms, and impossibility results in the area, and teaches readers how to reason carefully about distributed algorithms-to model them formally, devise precise specifications for their required behavior, prove their correctness, and evaluate their performance with realistic measures.
Abstract: In Distributed Algorithms, Nancy Lynch provides a blueprint for designing, implementing, and analyzing distributed algorithms. She directs her book at a wide audience, including students, programmers, system designers, and researchers.
Distributed Algorithms contains the most significant algorithms and impossibility results in the area, all in a simple automata-theoretic setting. The algorithms are proved correct, and their complexity is analyzed according to precisely defined complexity measures. The problems covered include resource allocation, communication, consensus among distributed processes, data consistency, deadlock detection, leader election, global snapshots, and many others.
The material is organized according to the system model-first by the timing model and then by the interprocess communication mechanism. The material on system models is isolated in separate chapters for easy reference.
The presentation is completely rigorous, yet is intuitive enough for immediate comprehension. This book familiarizes readers with important problems, algorithms, and impossibility results in the area: readers can then recognize the problems when they arise in practice, apply the algorithms to solve them, and use the impossibility results to determine whether problems are unsolvable. The book also provides readers with the basic mathematical tools for designing new algorithms and proving new impossibility results. In addition, it teaches readers how to reason carefully about distributed algorithms-to model them formally, devise precise specifications for their required behavior, prove their correctness, and evaluate their performance with realistic measures.
Table of Contents
1 Introduction
2 Modelling I; Synchronous Network Model
3 Leader Election in a Synchronous Ring
4 Algorithms in General Synchronous Networks
5 Distributed Consensus with Link Failures
6 Distributed Consensus with Process Failures
7 More Consensus Problems
8 Modelling II: Asynchronous System Model
9 Modelling III: Asynchronous Shared Memory Model
10 Mutual Exclusion
11 Resource Allocation
12 Consensus
13 Atomic Objects
14 Modelling IV: Asynchronous Network Model
15 Basic Asynchronous Network Algorithms
16 Synchronizers
17 Shared Memory versus Networks
18 Logical Time
19 Global Snapshots and Stable Properties
20 Network Resource Allocation
21 Asynchronous Networks with Process Failures
22 Data Link Protocols
23 Partially Synchronous System Models
24 Mutual Exclusion with Partial Synchrony
25 Consensus with Partial Synchrony
4,340 citations
22 Feb 1999
TL;DR: A new replication algorithm that is able to tolerate Byzantine faults that works in asynchronous environments like the Internet and incorporates several important optimizations that improve the response time of previous algorithms by more than an order of magnitude.
Abstract: This paper describes a new replication algorithm that is able to tolerate Byzantine faults. We believe that Byzantinefault-tolerant algorithms will be increasingly important in the future because malicious attacks and software errors are increasingly common and can cause faulty nodes to exhibit arbitrary behavior. Whereas previous algorithms assumed a synchronous system or were too slow to be used in practice, the algorithm described in this paper is practical: it works in asynchronous environments like the Internet and incorporates several important optimizations that improve the response time of previous algorithms by more than an order of magnitude. We implemented a Byzantine-fault-tolerant NFS service using our algorithm and measured its performance. The results show that our service is only 3% slower than a standard unreplicated NFS.
3,562 citations
"Authenticated Byzantine Fault Toler..." refers background or methods in this paper
...We have implemented a Byzantine-fault-tolerant NFS file system and it performs less than 3% slower than a standard, unreplicated implementation of NFS [5]....
[...]
...They are repeated here for completeness and because the version of the algorithm with public-key signatures is easier to understand, but can be skipped by a reader that is familiar with the algorithm in [5]....
[...]
...The number of message delays introduced by our algorithm between the moment the client sends a request and receives a reply is only 4 for read-write requests and 2 for read-only requests [5]....
[...]
...Copy-on-write techniques can be used to reduce the space overhead to store the extra copies of the state, as was done in [5]....
[...]
...In our current implementation [5], session keys are 16 bytes....
[...]