The dice stuff got messed up again when I lost my hard drive. Pretty much everything else has been cleaned up again, but I still need to work on the die roll server.
For more information on Titan see my Titan Home Page.
This document describes how to use the Titan Dice Roller. This service (dice rolls by email) was initially developed for use in play by email Titan games. It is OK to use it for other stuff now (especially for board games). If the load gets too high, I may restrict things in the future. (I really don't expect that to happen.)
If you are having trouble getting through, it may be because of my anti-spam blocks.
To use the dice rolling service send an email message to dice@wolff.to and all of the other people who need to witness the rolls. The server will send a message back to everyone with the rolls signed with the key given at the end of this page.
If you want your own, the server program and random number generator are both written in Perl. You will need to have a number of modules installed in your perl library to use the program. You will also need a /dev/random device on your server. If you want the PGP signing part, you can get a copy of PGP 2.64ui at the The Unofficial International PGP Home Page. (I am still using 2.63i myself.)
Typically this service might be used (when permitted by the game master) to get a roll when the previous player sent out his moves, but the GM hasn't sent your roll yet, when you need to make a split and don't want to wait for the GM to respond with a roll, or when two players wish to quickly fight a battle without having to wait for the GM. Normally these messages should be copied to all players, except when making a split. In that case only the GM should be copied. The message describing the split should be the same one used to get the rolls, otherwise there may be questions about which was done first.
The syntax of die roll requests is:
#number_of_dice,sides_on_dice!-minimum_value_to_count=The sides_on_dice defaults to 6 if it (and the comma) is omitted. If the minimum_to_count field (and the dash) is omitted, no counting is done. Typically this feature is used to count hits on a die roll. If the equals sign is omitted the sum isn't displayed. Using the exclamation point indicates that the rolls must be unique. This is typically omitted.
The # must be the first character on a line. There can be no embedded white space. Trailing white space is allowed. # can only be used in die roll requests. Lines without #s in them can be used for comments.
If an error occurs, the rest of the scanned text will be checked for errors, but no further rolls will be made. If no die rolls are successfully requested, a brief help message will be returned.
Messages from a postmaster, mailer daemon, the die roll server itself or the like are silently ignored. Messages not specifically to the die roll server are also ignored. Replies are not sent to the set of addresses listed above. So that users of this service need a non-postmaster address to use it.
There are also limits on the number of recipients, the number of rolls, and the entropy use allowed in a single message. These shouldn't be an issue for typical Titan use, unless a lot of observers are being copied on die rolls. You are currently limited to the equivalent of about 10000 D6 rolls (in a group) in a single message. This uses up a bit less than half of the maximum amount of available entropy in the pool.
The server understands MIME. Only parts of type text/plain or text are scanned. Embedded white space characters are changed to spaces.
The headers used to mail the reply (which are copied in the signed part) use simplified addresses (comments are removed) to make it easier to spot deceptive addresses.
A multi-part MIME message is returned by the server. The first embedded part is a quoted printable encoded part. This includes a copy of the To, From, Date, Subject and In-Reply-To headers used to send the reply (in the headers for this part). Part of the original message is also included. Trailing white space is removed. '> ' is prepended. Lines over 69 characters are split with '+ ' being prepended to the continuation lines. White space at the end of split lines is also removed.
The Received headers and the first Subject, Date and Message-ID headers from the original request are included. The addresses from the sender headers (From, Sender, Reply-To, Resent-From, Resent-Sender and Resent-Reply-To) are combined into a single From header. Similarly the recipient headers (To, Cc, Bcc, Resent-To, Resent-Cc and Resent-Bcc) are combined into a single To header. Envelope addresses are not used. Other headers are not included. All text from text/plain or text parts are included. Die rolls are returned after the lines requesting the roll. A blank line is add before and after the roll results to help them stand out.
If any rolls were successfully made, then the number of bytes of entropy used will be included in the reply. If no rolls were successfully made, then some help text will be added to the end of the message.
The second embedded part is a pgp signature of the first embedded part. This signature is over both the headers and the body of the first part. This is done according to rfc2015 and is compatible with the mutt mail user agent.
The server program is written in perl. Random numbers are generated using the /dev/random device. This is a special file under linux which takes data such as interrupt timings, mouse and keyboard actions and passes the data through SHA (a cryptographically strong hash function which outputs 160 bits). /dev/random will block if the estimated entropy is exhausted. If you are generating a lot (>20000 D6s) of rolls when I am not actively using the machine it may take some time to generate more random data. Currently I have my maximum entropy pool size set to be 8192 bytes. It doesn't rebuild very fast, as there aren't a lot of things happening on the machine most of the time. A small number of rolls should be handled in a couple of minutes, even just after the entropy pool has been drained.
The random numbers are generated by choosing a random number from a range at least as large as the number of sides on the dice. If the random number is greater than the allowed range, the process is repeated. This is done in a way to both conserve entropy used and to not introduce any bias into the selection. When rolling more than one die at a time, the rolls will be grouped to further save entropy. For more details take a look at the source.
The method used is optimal for individual rolls, but isn't for multiple rolls (except when using the command to roll multiple rolls for the same sided dice). There doesn't appear to be a simple way to use the extra unused entropy when making rolls. A good way to recover more of it would be to grab random bytes instead of bits when possible. Since leftover bits aren't saved between requests, this doesn't waste extra entropy, but does allow for more efficient use of entropy within a single request.
If you seriously want to run tests on the randomness of the generated numbers, please limit yourself to 3500 bytes of entropy. A grouped request of 10000 D6 rolls will use about 3400 bytes of entropy. If you really, really need more than that, please limit yourself to 3500 bytes a day (for no more than a week). If you need more than that, clear it with me first.
Even though the message is PGP signed you still need to be on the lookout for shenanigans. All of the incoming headers can be forged except for the final hop's Received header (the first one in the message). These should be checked if the sender denies having sent the request. It is possible for someone to send in lots of requests without copying the other people and then sending out a favorable reply to everyone. This is caught by checking to see that your correct email address is included in the signed To header and that the Received headers make sense for a message coming directly from the server. People may also try to reuse old messages (check the signed Date header) or try to fudge the text to make it look like part of his message is a returned die roll (this shouldn't be easy). It is possible for the headers used for mail to legitimately be different from those that are signed. Sendmail will rewrite headers, but this would mostly be limited to cases where people were using the service from accounts on my workstation.
Received: (qmail 8426 invoked by uid 500); 27 May 2001 21:56:23 -0000 Date: Sun, 27 May 2001 16:56:22 -0500 From: Bruno Wolff III <bruno@wolff.to> To: dice@wolff.to Cc: bruno@wolff.to Subject: Sample Roll Requests Message-ID: <20010527165622.A7025@wolff.to> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Content-Length: 588 A typical Titan request might look like the following: Cyc1 vs Cyc1 #9-4 Cyc2 vs Gor1 (note that the ,6 says to use 6-sided dice, which is the default) #9,6-5 Cyc3 versus Gor1 if it has 2 or less hits to go, otherwise versus Cyc1 #9 To pick initial towers without needing roll offs: Players will move in the position of the number corrseponding to their color. I.e. the color matching the first number listed gets tower 6. Red = 1, Blue = 2, Green = 3, Brown = 4, Gold = 5, Black = 6. #6! A typical craps request might look like the following: Baby needs a new pair of shoes! #2=
Received: (qmail 8441 invoked from network); 27 May 2001 21:56:24 -0000
Received: from unknown (HELO wolff.to) (127.0.0.1)
by 0 with SMTP; 27 May 2001 21:56:24 -0000
Content-Type: multipart/signed; micalg=pgp-md5;
protocol="application/pgp-signature";
boundary="----------=_991000583-8431-0"
Content-Transfer-Encoding: binary
MIME-Version: 1.0
X-Mailer: MIME-tools 5.314 (Entity 5.211)
Subject: Re: Sample Roll Requests
From: dice@wolff.to
To: bruno@wolff.to
Date: Sun, 27 May 2001 21:56:23 -0000 (GMT)
Content-Length: 1916
This is a multi-part message in MIME format...
------------=_991000583-8431-0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
Subject: Re: Sample Roll Requests
From: dice@wolff.to
To: bruno@wolff.to
Date: Sun, 27 May 2001 21:56:23 -0000 (GMT)
> Received: (qmail 8426 invoked by uid 500); 27 May 2001 21:56:23 -00
+ 00
> Subject: Sample Roll Requests
> From: Bruno Wolff III <bruno@wolff.to>
> To: dice@wolff.to, bruno@wolff.to
> Message-ID: <20010527165622.A7025@wolff.to>
> Date: Sun, 27 May 2001 16:56:22 -0500
>
>
> A typical Titan request might look like the following:
>
> Cyc1 vs Cyc1
> #9-4
Roll: 3 1 6 5 4 3 6 6 5 (6 hits)
>
> Cyc2 vs Gor1 (note that the ,6 says to use 6-sided dice, which is t
+ he default)
> #9,6-5
Roll: 2 4 1 4 1 4 5 1 3 (1 hit)
>
> Cyc3 versus Gor1 if it has 2 or less hits to go, otherwise versus C
+ yc1
> #9
Roll: 5 1 5 4 5 1 4 2 5
>
> To pick initial towers without needing roll offs:
>
> Players will move in the position of the number corrseponding to th
+ eir color.
> I.e. the color matching the first number listed gets tower 6.
> Red =3D 1, Blue =3D 2, Green =3D 3, Brown =3D 4, Gold =3D 5, Black =3D 6.
> #6!
Roll: 6 5 4 3 1 2
>
> A typical craps request might look like the following:
>
> Baby needs a new pair of shoes!
> #2=3D
Roll: 4 4 Sum: 8
12 bytes of entropy were used to make your die rolls.
------------=_991000583-8431-0
Content-Type: application/pgp-signature
Content-Disposition: attachment
Content-Transfer-Encoding: 7bit
-----BEGIN PGP SIGNATURE-----
Version: 2.6.3ia
iQCVAwUBOxF4CNS9jhDSN1xxAQH0bQP/YTd9yRvNzhJdRfG27AI//ToEanAF1kpN
A8enU0otI9zIUsVBx/4eatVWGGcwwEHtV/zAozR73N3VfrFMIzqPn/s4VKtUwrQo
E4xOkT3jUDfJDojdkNJCqXSg5fgRW6W4MDxmtjY46cJtIR9egx5qpL+Soj824MHy
O/1crKlKgME=
=BVbc
-----END PGP SIGNATURE-----
------------=_991000583-8431-0--
Currently the die roll server does not accept encrypted messages.
When there is eventually a real moderator program (for Titan), players will be sent messages encrypted with their public key. Only a non-reusable token will be signed by the moderator. Other data will be sent unsigned so that it can not be passed on to other players along with a certification.
Type Bits/KeyID Date User ID pub 1024/D2375C71 2000/09/19 Titan Dice Roller <dice@wolff.to> -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.6.3ia mQCNAznHc58AAAEEAMR7AT/dyT7Ee3ZGT4rckkDzI/e5/VqXRNd4j7u510UaGD3l X26g6Iq/cpGkJtHN21C7wzbCUTl9Yj6PiRZ+pJxWb4Pfq7iPmn6ltc7XG75MpjhD gEYuaTWHaPYM7IgaI/ny2N8PWsVqAE9OaVl/PNVPQJ7Ul6EkHtS9jhDSN1xxAAUR tCFUaXRhbiBEaWNlIFJvbGxlciA8ZGljZUB3b2xmZi50bz6JAJUDBRA50lz8ijJ1 4/pN/0UBAdb3A/4xPrcpog3NuGZx4ldrRHFqoQ/mnuZPA23U2dF6MQ+PkG5s91kj HSxSWYBsGmmLTib95xNA+ysYVc9nwbx664R/jFwKMHzTVtKFrl84XC4OcsNIJrmz WbBNDC4/4+UGIuVEkAML1taXS0GPZN5+jQFrT3An7sl750/8YVtDAp9mgokAlQMF EDnHc9CrnJQD3F55LQEBr6MD/iLrrzHTuoB00Zl67kO3m1Q1YNw/ddP5CsDfT6F0 7Vg20L/qN7MGJ35rulDskUHlv2vNLm9Htr/dcBDtB51JtQ+ycPdYiD/DrbLK6u5C 9QwTyY82lMIK7bL64tdfaKNi3B1RaCbO0lHB2dnfm9HQRupr3m2wzsFAodd7aJzy U0OViQCVAwUQOcdzn9S9jhDSN1xxAQEjbAP8Cx2hcpkkhihCHqByRQsaAjVPfvP7 mqk4DqwWcXCwwJpIwjg3IbZDg9RaXRD8av0oh4HJWtawKWiOYE0EUjj00M+yPwe7 40ybR//GyPw32yHZao/WebGlmSMaOAE8GlBZletmuqswBFKSdyFHiEkr6oaSXANl WhT7LEeQryCX2Zo= =x0CV -----END PGP PUBLIC KEY BLOCK-----
A secure version of this page is located at: https://wolff.to/dice/