Project Fairdice
[Home] [Docs] [Users] [Gaming] [Crypto] [Devel] [Download] [Help]

Architecture : Requirements


Be Boring. This protocol does nothing special in cryptographic terms. In fact it goes out of its way to only use well known and understood procedures like one way hashing. The only thing new about all this is that no one has yet bothered to implement it in an open source (and thus trustable) form.

Require as little as possible. The default client-server connection protocol knows nothing about bets, game rules, game selection, finding hosts or registering public keys. It knows the minimum that it requires in order to let participants collaborate to fairly select between a set of distinct pre-determined outcomes. Anything else that it refers to or passes on is treated as opaque.

Assume as little as possible. Strong versioning and flexible extensibility are intended to promote stability through long term backwards compatibilty. The protocol is designed to seamlessly allow future versions to implement link level encryption, authentication and binary or XML encoding of the link data.

Security through transparency. Everything is coded as simply as possible. No obscurity is used. The aim is to get security by Doing It Right, not by trusting anyone or by relying on just making things difficult. The hash algorithm used as default in this first version (TIGER) is not intrinsic to the overall protocol, and future versions could allow the user to choose between multiple algorithms.

Developmental Requirements

transparancy, maintainability, extensibility, configurability

Cryptographic Requirements

correctness, security

End User Requirements

usability, stability, speed, portability, compatability, flexibility