Soon:

* Finish vetting 2 servers to Recommended.
* Set up --check-servers in a cron job, so I know when servers are down.
* Remove gpg key passohrase from gpg keys that keysafe backs up.
  The reason for this is that the user may well forget their gpg key
  passphrase, and it's *weird* to restore a key with keysafe's password
  and then have it passphrase protected.
  The gpg key passphrase is intended only to keep a key from being used
  for a short period of time (a week or so) when the device holding it 
  is known to have been compromised, so the key can be revoked.
  This doesn't really apply to keys backed up with keysafe -- if they get
  compromised somehow, the user won't know, and cracking the gpg passphrase
  should be almost trivial to an attacker who was able to break keysafe's
  password.
  paperkey can remove gpg key passphrases. Is there any better way?
  It might make sense for keysafe to prompt for a new gpg passphrase
  when restoring.

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.
* Make --gui password entry fields longer, so user does not feel they need
  to make password short. (zenity may not allow configuring this)
* 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.
* --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:

* Custom GUI, instead of zenity. Allows:
  - Fewer screens by consolidating multiple prompts.
  - Check same password entered second time and don't allow continuing
    if not.
  - Password strengh display, and don't allow continuing if password is too
    weak.
* 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..
* Don't require --totalshares and --neededshares on restore when unusual
  values were used for backup. 

  The difficulty is that the number of needed shares cannot be determined by
  looking at shares, and guessing it wrong will result in combining
  too few shares yielding garbage, which it will take up to an hour to
  try to decrypt, before it can tell that more shares are needed.

  This could be dealt with by including the number of needed shares in the
  serialization of Share, but then an attacker could use it to partition
  shares from servers. If only one person uses --neededshares=5,
  the attacker can guess that all their shares go together.

  What about including the number of needed shares in the name? Since that's
  hashed, it's not visible to an attacker. Keysafe would need to try names
  with 2 shares, then 3, etc, and once it found shares, it would know the
  number needed. It should also be possible to avoid breaking backwards
  compatability, by only including the number of shares in the name when
  it's not the standard number. To avoid needing to re-run argon2 for each
  try, the argon2 hash of the name could be calculated first, and then the
  number of needed shares appended before the final sha256 hash is
  generated.
  
  If an attacker is able to guess the name, and a nonstandard number of
  shares was used, the attacker could upload other objects where they would
  be found before the real objects. This could be used to prevent
  restore from working. (It also makes a malicious data attack (as described
  in https://keysafe.branchable.com/details/) possible by attackers who do not
  control the servers.

Encryption tunables changes:

* Argon2d is more resistent to GPU/ASIC attack optimisation.
  Switching from Argon2i would require new tunables, and delay restores
  (of keys backed up using the old tunables, and when the user provides the
  wrong name) by ~10 minutes, so deferred for now
  until there's some other reason to change the tunables.
* The ShareIdents derivation currently appends a number and sha256 hashes
  to generate a stream of values. Ben M points out that HMAC is a more
  typical way to do such a thing. Even better, a HKDF-Expand
  (RFC5869) can generate a stream which can then be chunked up into values.  
  Either of these would avoid a full pre-image attack on SHA-2 breaking
  keysafe. Of course, such an SHA-2 attack would be a general security
  disaster. HKDF may prove more robust in the face of partial SHA-2 breaks.
  Deferred for now until tthere's some other reason to change keysafe's
  tunables.