Abstract not found

Abstract not found

This article shines some light in the "four dark corners," exposing problems and proposing solutions. We show that all descriptions involved in requirements engineering should be descriptions of the environment. We show that certain control information is necessary for sound requirements engineering, and we explain the close association between domain knowledge and refinement of requirements. Together these conclusions explain the precise nature of requirements, specifications, and domain knowledge, as well as the precise nature of the relationships among them. They establish minimum standards for what information should be represented in a requirements language. They also make it possible to determine exactly what it means for requirements engineering to be successfully completed.

Communication in distributed systems often relies on useful abstractions such as channels, remote procedure calls, and remote method invocations. The

Abstract not found

Abstract. Lamport showed that a replicated deterministic state machine is a general way to implement a highly available system, given a consensus algorithm that the replicas can use to agree on each input. His Paxos algorithm is the most fault-tolerant way to get consensus without real-time guarantees. Because general consensus is expensive, practical systems reserve it for emergencies and use leases (locks that time out) for most of the computing. This paper explains the general scheme for efficient highly available computing, gives a general method for understanding concurrent and fault-tolerant programs, and derives the Paxos algorithm as an example of the method. 1

Abstract not found

this paper we advocate showing that an abstract functional specification satisfies Noninterference directly and then showing that the program satisfies the functional specification. By being carried out on as abstract a level as possible, our security proof can survive implementation changes that do not affect the user interface to the system.

We attempt to formally define the strong fair exchange problem and present a proof that it is impossible to solve strong fair exchange without a trusted third party. The proof is established by relating strong fair exchange to the problem of consensus and adapting the impossibility result of Fischer, Lynch and Paterson. We show that strong fair exchange is at least as hard as consensus and explore a few requirements for trusted third parties in order to be of use in fair exchange.

Specifications for security protocols range from informal narrations of message flows to formal assertions of protocol properties. This paper discusses those specifications, emphasizing authenticity and secrecy properties. It also suggests some gaps and some opportunities for further work. Some of them pertain to the traditional core of the field; others appear when we examine the context in which protocols operate.