Soon:

* Get some keysafe servers set up.
* Set up --check-servers in a cron job, so I know when servers are down.

Later:

* The attack cost display can lead to a false sense of security if the user
  takes it as gospel. It needs to be clear that it's an estimate. This and
  other parts of the keysafe UI need usability testing.
* improve restore progress bar points (update after every hash try)
* If we retrieved enough shares successfully, but decrypt failed, must
  be a wrong password, so prompt for re-entry and retry with those shares.
* Don't require --totalshares and --neededshares on restore when unusual
  values were used for backup. Instead, probe until enough shares are found
  to restore.
* --no-jargon which makes the UI avoid terms like "secret key" and "crack
  password". Do usability testing!
* --key-value=$N which eliminates the question about password value,
  and rejects passwords that would cost less than $N to crack at current
  rates. This should add a combo box to the password entry form in the
  GUI to let the user adjust the $N there.
* In backup, only upload to N-1 servers immediately, and delay the rest
  for up to several days, with some uploads of chaff, to prevent
  collaborating evil servers from correlating related shards.
* Add some random padding to http requests and responses, to make it
  harder for traffic analysis to tell that given TOR traffic is
  keysafe traffic.

Wishlist:

* Keep secret keys in locked memory until they're encrypted.
  (Raaz makes this possible to do.)
  Would be nice, but not super-important, since gpg secret keys
  are passphrase protected anyway..