Protocol v2(last edited 12-27-2004)
* The protocol is still under construction, and is subject to change
* This is the second version of the SBD protocol. This version uses
  one time pad(OTP) along with HMAC-SHA1, as opposed to version 1 which
  uses only OTP. This version is meant to be based on current well
  known cryptographic primitives, while version 1 is based on experimental
  home-brewed primitives. For the time being, all release of SBD will
  use version 2 of the protocol, but the version 1 protocol will always
  be available from CVS.

Overview:

The SBD protocol is based on the strength of using a one-time 
symmetric key. This means that each the user and the server are
the only ones that share the key. Failure to keep this key a secret
results in the failure of the protocol, therefore it is important that
you keep your key a secret.

The power of a one-time key is largely based on the randomness of the key,
the method used should be generated from a truly random source if possible. 
The generation of random keys is left up to the user, since it goes beyond
the scope of SBD. Linux provides a source of fairly random numbers from
/dev/random. Also, there are a few sites such as http://www.random.org
that provide users with random bytes. You should keep in mind though, that
random.org does not offer secure access for downloading these randomly 
generated numbers. For most purposes, a simple program that generates
pseudo-random numbers using the C rand() function should be sufficient for
most users.

Goals:

The goals of SBD v2 are as follows:

* Should allow remote execution of commands
* Should be secure as possible
* Should be minimal as possible to avoid inherent security risks that large
  programs such as SSH carry with them
* Should provide some basic methods for IP spoofing protection
* Should provide some basic methods for Denial of Service protection

Algorithm/Implementation:

1. The client connects to server, the server sends 20 random bytes to
   the client as a challenge.
2. The client takes 20-bytes of OTP and computes the HMAC-SHA1 using
   the 20-bytes of OTP as it's shared secret, and the combination of challenge
   and the command as it's message.
3. The client prepends the HMAC-SHA1 hash with the original command
   and xors the whole thing with as many bytes of OTP as needed,
   then sends it to the server.
4. The server computes the amount of key it needs (20 bytes for the
   SHA1 seed, plus however many bytes long the encrypted message is),
   then reads the OTP from file.
5. It uses the last n bytes of OTP from the key to xor the file back
   to it's original state, where n is the length of the message.
6. It then strips the command, and computes the HMAC-SHA1 hash using
   the first 20 bytes of OTP as the share secret, and the original challenge
   plus the original command as it's message.
7. It then checks this hash with the one that was prepended to the 
   original command that the client sent. If they match, the command
   is executed.

      
Notes:
* For the checksum, SBD currently uses SHA-1 with HMAC, with that said, 
  it might be changed to a different hash in the future, the protocol 
  itself is not dependent on SHA-1.
* Things such as allowing or denying certain IP's, or throttling the number
  of connections are assumed to be taken care of by the firewall. This 
  functionality might be in SBD some day, but for now is best handled by the
  firewall.      	     
