diff options
Diffstat (limited to 'TODO')
| -rw-r--r-- | TODO | 36 |
1 files changed, 31 insertions, 5 deletions
@@ -2,6 +2,20 @@ 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: @@ -25,11 +39,6 @@ Later: * 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. -* 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. Wishlist: @@ -72,3 +81,20 @@ Wishlist: 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. |