From flud

There are several alternate ways to provide credential recovery. These have all been rejected at present because the solutions are either immature at this time or they are more complex than the simple encrypted credentials sent in email.

[edit] k-deterministic assymetric keys

(from 'An Encoding for Censorship-Resistent Sharing', Grotoff et al), Ku/Kr are generated from a deterministic psuedo-random number generator and a keyword K. Given K, one can regenerate Ku/Kr. Can we use a variant of K-deterministic asymmetric keys for key recovery? E.g., upon first use, the user is required to enter a passphrase (or N easily remembered values, such as maiden name, favorite athlete, phone number, etc) from which their Ku/Kr pair is generated. Then, in the case of catastrophic loss, they can regenerate Ku/Kr from memory and recover all their data? At the moment, this idea is largely unworkable for practical reasons: the passphrase must not collide with any other user's passphrase (impossible to enforce), and the passphrase must be 100% memorable (which, if the passphrase doesn't collide and the user isn't required to enter it regularly, means that this is also an uphill battle from a usability perspective)

[edit] backup credentials to the flud network itself

Another option is to back up an encrypted version of the key to the Flud network. If we neglect to do this, we must insist that the user print out the config file, write down their key pair, or otherwise manage this information safely themselves and externally from the computer (to survive hardware theft, drive crash, etc.), which is an okay idea to do anyway, but from a usability perspective is disastrous. Instead, we could store this information safely in the flud network. In order to do so, this operation needs to be a special case -- instead of storing the file using convergent storage (the hash of the file as the key), the user should pick a secret passphrase (chosen carefully to avoid conflicts and to maintain secrecy [must enforce passphrase length requirements]), the hash of which will become the storage key (in fact, we will likely rehash this value and store it several [3?] times to ensure that the file gets extra-replicated to the network) The file is also encrypted locally using the secret passphrase before being stored. To recover this file (which will be required to restore all the user's data), the user then only needs their secret passphrase and the secret groupID (which defaults to the public flud network if not on a private flud network). The user must understand the importance of choosing a good passphrase and of safely remembering this information [passpharse, groupID]. Luckily, groupID should usually be obtainable from the same place as it was originally obtained (members of the group, etc.), so the passphrase is the really vital piece. Unfortunately, this is also a largely unworkable solution. See StoringCredentialsInFlud for details.