Fix up formatting of module doc comments

src/bridge_table.rs

@@ -1,11 +1,12 @@
-/*! The encrypted table of bridges.  The table consists of a number of
- * buckets, each holding some number (currently up to 3) of bridges.
- * Each bucket is individually encrypted with a bucket key.  Users will
- * have a credential containing a bucket (number, key) combination, and
- * so will be able to read one of the buckets.  Users will either
- * download the whole encrypted bucket list or use PIR to download a
- * piece of it, so that the bridge authority does not learn which bucket
- * the user has access to. */
+/*! The encrypted table of bridges.
+
+The table consists of a number of buckets, each holding some number
+(currently up to 3) of bridges.  Each bucket is individually encrypted
+with a bucket key.  Users will have a credential containing a bucket
+(number, key) combination, and so will be able to read one of the
+buckets.  Users will either download the whole encrypted bucket list or
+use PIR to download a piece of it, so that the bridge authority does not
+learn which bucket the user has access to. */
 
 use aes_gcm::aead;
 use aes_gcm::aead::{generic_array::GenericArray, Aead, NewAead};

src/cred.rs

@@ -1,7 +1,8 @@
-/*! The various credentials used by the system.  In each case, (P,Q)
- * forms the MAC on the credential.  This MAC is verifiable only by the
- * issuing party, or if the issuing party issues a zero-knowledge proof
- * of its correctness (as it does at issuing time). */
+/*! The various credentials used by the system.
+
+In each case, (P,Q) forms the MAC on the credential.  This MAC is
+verifiable only by the issuing party, or if the issuing party issues a
+zero-knowledge proof of its correctness (as it does at issuing time). */
 
 use curve25519_dalek::ristretto::RistrettoPoint;
 use curve25519_dalek::scalar::Scalar;

src/dup_filter.rs

@@ -1,7 +1,8 @@
 /*! Filter duplicate shows of credentials and open invitations by id
- * (which will typically be a Scalar).  This implementation just keeps
- * the table of seen ids in memory, but a production one would of course
- * use a disk-backed database. */
+(which will typically be a Scalar).
+
+This implementation just keeps the table of seen ids in memory, but a
+production one would of course use a disk-backed database. */
 
 use std::cmp::Eq;
 use std::collections::HashMap;

src/open_invite.rs

@@ -1,6 +1,8 @@
 /*! A module for the protocol for the user to redeem an open invitation
 with the BA (bridge authority) to receive their initial Lox
-credential.  The credential will have attributes:
+credential.
+
+The credential will have attributes:
 
 - id: jointly chosen by the user and BA
 - bucket: set by the BA