diff options
Diffstat (limited to 'doc/todo')
23 files changed, 267 insertions, 0 deletions
diff --git a/doc/todo/Fix_compiler_errors_in_HEAD.mdwn b/doc/todo/Fix_compiler_errors_in_HEAD.mdwn new file mode 100644 index 0000000..08dbdc8 --- /dev/null +++ b/doc/todo/Fix_compiler_errors_in_HEAD.mdwn @@ -0,0 +1,78 @@ +``` +From e1fee7bb9dd508b9bef420fd76292f91bb151c8c Mon Sep 17 00:00:00 2001 +From: Mitchell Rosen <mitchellwrosen@gmail.com> +Date: Sat, 1 Apr 2017 14:39:41 -0400 +Subject: [PATCH 1/1] Fix compiler errors + +--- + HTTP/ProofOfWork.hs | 8 ++++---- + HTTP/Server.hs | 3 ++- + 2 files changed, 6 insertions(+), 5 deletions(-) + +diff --git a/HTTP/ProofOfWork.hs b/HTTP/ProofOfWork.hs +index 0237347..9a10d39 100644 +--- a/HTTP/ProofOfWork.hs ++++ b/HTTP/ProofOfWork.hs +@@ -16,7 +16,7 @@ import ByteStrings + import GHC.Generics + import qualified Data.Text as T + import qualified Data.ByteString as B +-import Data.Text.Encoding (encodeUtf8) ++import Data.Text.Encoding (decodeUtf8, encodeUtf8) + import Raaz.Core.Encode + import qualified Raaz + import Data.BloomFilter.Hash +@@ -55,7 +55,7 @@ instance Hashable RequestID where + hashIO64 = hashIO64 . hashRequestID + + hashRequestID :: RequestID -> B.ByteString +-hashRequestID rid = encodeUtf8 (fromRandomSalt (randomSalt rid)) ++hashRequestID rid = encodeUtf8 (fromRandomSalt (randomSalt rid)) + <> ":" <> encodeUtf8 (requestHMAC rid) + + -- | Using Text and not ByteString so that ProofOfWorkRequirement can have a +@@ -80,7 +80,7 @@ maxProofOfWork = Seconds (16*60) + -- on the very first try. On average, the client will need to work for half + -- as long as the returned number of Seconds. + generationTime :: ProofOfWorkRequirement -> Seconds +-generationTime req = ++generationTime req = + let UseArgon2 (CPUCost (Seconds s) _) _ = proofOfWorkHashTunable (addedArgon2Iterations req) + in Seconds ((2^(leadingZeros req)) * s) + +@@ -109,7 +109,7 @@ mkRequestID secret = mkRequeestID' secret <$> mkRandomSalt + mkRequeestID' :: RequestIDSecret -> RandomSalt -> RequestID + mkRequeestID' (RequestIDSecret key) salt = + let hmac = Raaz.hmacSha256 key (encodeUtf8 $ fromRandomSalt salt) +- in RequestID salt $ T.toByteString (Raaz.encode hmac :: Base16) ++ in RequestID salt $ decodeUtf8 $ Raaz.toByteString (Raaz.encode hmac :: Base16) + + validRequestID :: RequestIDSecret -> RequestID -> Bool + validRequestID secret rid = +diff --git a/HTTP/Server.hs b/HTTP/Server.hs +index 61bdbfd..12a8f26 100644 +--- a/HTTP/Server.hs ++++ b/HTTP/Server.hs +@@ -18,6 +18,7 @@ import CmdLine (ServerConfig(..)) + import Storage.Local + import Serialization () + import Servant ++import Network.Wai (Application) + import Network.Wai.Handler.Warp + import Control.Monad.IO.Class + import Control.Concurrent +@@ -51,7 +52,7 @@ runServer d cfg = do + _ <- forkIO $ obscurerThread st + runSettings settings (app st) + where +- settings = setHost host $ setPort (serverPort cfg) $ defaultSettings ++ settings = setHost host $ setPort (serverPort cfg) $ defaultSettings + host = fromString (serverAddress cfg) + + serverStorage :: Maybe LocalStorageDirectory -> Storage +-- +2.12.1 +``` + +> Thanks for the patch; I applied essentially these fixes although +> untangled the unrelated issues. [[done]] --[[Joey]] diff --git a/doc/todo/Make_the_number_of_shard_servers_configurable.mdwn b/doc/todo/Make_the_number_of_shard_servers_configurable.mdwn new file mode 100644 index 0000000..d9ebe32 --- /dev/null +++ b/doc/todo/Make_the_number_of_shard_servers_configurable.mdwn @@ -0,0 +1,3 @@ +Currently 3 shard servers are used for saving the key and either two of them are required to reconstruct the key. + +In my opinion it's too easy for any two subjects to cooperate when it comes to key reconstruction. I'd like to therefore have the number of shard servers configurable (with possibly hundreds of shard servers). This implies also having configurable also the minimum number of servers needed for key reconstruction (with possibly hundreds of required pieces of the key). diff --git a/doc/todo/Make_the_number_of_shard_servers_configurable/comment_1_4416f7495e2a34a3cdb6f5106beaf582._comment b/doc/todo/Make_the_number_of_shard_servers_configurable/comment_1_4416f7495e2a34a3cdb6f5106beaf582._comment new file mode 100644 index 0000000..1a2871f --- /dev/null +++ b/doc/todo/Make_the_number_of_shard_servers_configurable/comment_1_4416f7495e2a34a3cdb6f5106beaf582._comment @@ -0,0 +1,20 @@ +[[!comment format=mdwn + username="joey" + subject="""comment 1""" + date="2017-04-04T16:19:10Z" + content=""" +You can use --totalshares and --neededshares to configure how many shares +keysafe splits the key into. See also +[[detect_number_of_required_shares_on_restore]]. + +Bear in mind that colluding servers still have to guess the name used to +find the shares to combine, and even then they still have the expensive +work of cracking the password ahead. Splitting the secret across servers is +only an initial line of defense. + +It's debatable whether having a lot of servers would add much security. + +But, keysafe needs more servers in any case. With more than 3 servers, +splits like 3-of-4 and 2-of-4 become usable; these and other parameters are +probably useful in some cases. +"""]] diff --git a/doc/todo/Move_the_project_to_notabug.org.mdwn b/doc/todo/Move_the_project_to_notabug.org.mdwn new file mode 100644 index 0000000..faec65a --- /dev/null +++ b/doc/todo/Move_the_project_to_notabug.org.mdwn @@ -0,0 +1,9 @@ +Currently it's difficult to discuss anything publicly, refer to solved issues, get a fresh overview of the project's progress, etc. + +So I'd like to propose moving the Keysafe project to [https://notabug.org](https://notabug.org ). They're very open, they respect (in fact require) Free Software and they're pretty stable (I'm following them for about 2 years and they're meticulously publicly documenting what is going on) and legally OK. + +[https://notabug.org](https://notabug.org ) is running [Gogs](https://gogs.io), which is a SW providing a centralized web interface for a great amount of git projects [https://notabug.org](https://notabug.org ) can be seen as an alternative GitHub, but with good Terms of Service and not the GitHub's ToS which basically say among other things that "you're fully responsible for anything we do in your country/land/region"). + +If [https://notabug.org](https://notabug.org ) won't suit our needs, could find another alternative allowing easy public discussion of enhancements/bugs of Keysafe and a nicely visible progress overview? + +[[done]] diff --git a/doc/todo/Move_the_project_to_notabug.org/comment_1_a1e7094aa456b5ff6a6fb5adcc34fcab._comment b/doc/todo/Move_the_project_to_notabug.org/comment_1_a1e7094aa456b5ff6a6fb5adcc34fcab._comment new file mode 100644 index 0000000..02bc5ca --- /dev/null +++ b/doc/todo/Move_the_project_to_notabug.org/comment_1_a1e7094aa456b5ff6a6fb5adcc34fcab._comment @@ -0,0 +1,13 @@ +[[!comment format=mdwn + username="joey" + subject="""comment 1""" + date="2017-04-04T16:58:17Z" + content=""" +I have nothing against notabug, but I prefer to use my own tools and keep +everything in a git repository (not some sql-based wrapper around a git +repository). So I don't think I'll be doing that. + +People generally don't seem to find it impossible to use ikiwiki, +which is what we're using here, for public discussion, to refer to solved +issues, to see what's going on, etc. +"""]] diff --git a/doc/todo/add_--key-value_option.mdwn b/doc/todo/add_--key-value_option.mdwn new file mode 100644 index 0000000..bd6e918 --- /dev/null +++ b/doc/todo/add_--key-value_option.mdwn @@ -0,0 +1,5 @@ +--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. + diff --git a/doc/todo/back_up_only_chosen_subkeys.mdwn b/doc/todo/back_up_only_chosen_subkeys.mdwn new file mode 100644 index 0000000..17a4b4b --- /dev/null +++ b/doc/todo/back_up_only_chosen_subkeys.mdwn @@ -0,0 +1,2 @@ +I'm a DD, so I don't want keysafe to ever back up my signing subkey nor my master key. But I'd like it to back up my encryption subkey, so that I don't lose access to (e.g.) git-annex special remotes encrypted against that key. It would be good if keysafe asked me which subkeys I want to back up. --spwhitton + diff --git a/doc/todo/custom_gui.mdwn b/doc/todo/custom_gui.mdwn new file mode 100644 index 0000000..c2863f6 --- /dev/null +++ b/doc/todo/custom_gui.mdwn @@ -0,0 +1,10 @@ +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. +* Make --gui password entry fields longer, so user does not feel they + need to make password short. (zenity does not seem to allow configuring + this.) diff --git a/doc/todo/delay_some_uploads_to_prevent_correlation.mdwn b/doc/todo/delay_some_uploads_to_prevent_correlation.mdwn new file mode 100644 index 0000000..5b9e324 --- /dev/null +++ b/doc/todo/delay_some_uploads_to_prevent_correlation.mdwn @@ -0,0 +1,19 @@ +In backup, only upload to some 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. + +How many servers should be uploaded to immediately? The safe answer is at least +M (--neededshares); that way the secret key does get backed up immediately. + +Uploading to less would be more secure, but risks the user thinking it +finished backing up the key, and eg, wiping their laptop. So careful +messaging would be needed in this case. + +Might just upload M-1 shares immediatly, and show a dialog saying, the +backup will be completed next Wednesday, or click here to finish it now. + +---- + +Also, when there are multiple chunks, they are currently uploaded in order. +That could easily be shuffled, with server A getting its share of chunk 2 +first, server B its share of chunk 3 first, etc. diff --git a/doc/todo/detect_bad_password_on_restore_and_re-prompt.mdwn b/doc/todo/detect_bad_password_on_restore_and_re-prompt.mdwn new file mode 100644 index 0000000..f010676 --- /dev/null +++ b/doc/todo/detect_bad_password_on_restore_and_re-prompt.mdwn @@ -0,0 +1,2 @@ +If we retrieved enough shares successfully, but decrypt failed, must +be a wrong password, so prompt for re-entry and retry with those shares. diff --git a/doc/todo/detect_number_of_required_shares_on_restore.mdwn b/doc/todo/detect_number_of_required_shares_on_restore.mdwn new file mode 100644 index 0000000..4bfa080 --- /dev/null +++ b/doc/todo/detect_number_of_required_shares_on_restore.mdwn @@ -0,0 +1,34 @@ +When --totalshares and --neededshares were used to back up a key, +those options (well at least --neededshares) +also have to be provided at restore time to make it try to find +enough shares to restore. + +It would be good to detect the number of required shares so the user does +not need to remember to do that. + +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. + +Problem with this: 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. diff --git a/doc/todo/done.mdwn b/doc/todo/done.mdwn new file mode 100644 index 0000000..e7c9808 --- /dev/null +++ b/doc/todo/done.mdwn @@ -0,0 +1,4 @@ +recently fixed [[todo]] items. + +[[!inline pages="./* and link(./done) and !*/Discussion" sort=mtime show=10 +archive=yes]] diff --git a/doc/todo/future_encryption_tunables_changes.mdwn b/doc/todo/future_encryption_tunables_changes.mdwn new file mode 100644 index 0000000..8a9b29d --- /dev/null +++ b/doc/todo/future_encryption_tunables_changes.mdwn @@ -0,0 +1,18 @@ +If switching any of the encryption tunables for some reason, +consider making these changes all at once: + +* 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. +* Perhaps use CHACHA2 instead of AES? diff --git a/doc/todo/important.mdwn b/doc/todo/important.mdwn new file mode 100644 index 0000000..46d2b49 --- /dev/null +++ b/doc/todo/important.mdwn @@ -0,0 +1,4 @@ +important [[todo]] items. + +[[!inline pages="./* and link(./important) and !*/Discussion" sort=mtime show=10 +archive=yes]] diff --git a/doc/todo/improve_restore_progress_bar.mdwn b/doc/todo/improve_restore_progress_bar.mdwn new file mode 100644 index 0000000..5a6af76 --- /dev/null +++ b/doc/todo/improve_restore_progress_bar.mdwn @@ -0,0 +1 @@ +improve restore progress bar points (update after every hash try) diff --git a/doc/todo/need_one_more_recommended_server.mdwn b/doc/todo/need_one_more_recommended_server.mdwn new file mode 100644 index 0000000..a699643 --- /dev/null +++ b/doc/todo/need_one_more_recommended_server.mdwn @@ -0,0 +1,8 @@ +There is currently only 1 recommended server; keysafe needs one more before +it can be used without warning that it's uploading 2 shares to +not-recommended servers. + +Probably need a new recommended server. The existing non-recommended +servers don't have warrant canaries for various reasons. + +[[!tag important]] diff --git a/doc/todo/padding_to_prevent_traffic_analysis.mdwn b/doc/todo/padding_to_prevent_traffic_analysis.mdwn new file mode 100644 index 0000000..c2aa3c1 --- /dev/null +++ b/doc/todo/padding_to_prevent_traffic_analysis.mdwn @@ -0,0 +1,3 @@ +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. diff --git a/doc/todo/remove_gpg_key_passphrase_from_backed_up_gpg_keys.mdwn b/doc/todo/remove_gpg_key_passphrase_from_backed_up_gpg_keys.mdwn new file mode 100644 index 0000000..5a370be --- /dev/null +++ b/doc/todo/remove_gpg_key_passphrase_from_backed_up_gpg_keys.mdwn @@ -0,0 +1,17 @@ +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. diff --git a/doc/todo/remove_jargon.mdwn b/doc/todo/remove_jargon.mdwn new file mode 100644 index 0000000..8706010 --- /dev/null +++ b/doc/todo/remove_jargon.mdwn @@ -0,0 +1,4 @@ +Add --no-jargon which makes the UI avoid terms like "secret key" and "crack +password". Do usability testing! + +Should perhaps be default? diff --git a/doc/todo/set_up_--check-servers_in_cron_job.mdwn b/doc/todo/set_up_--check-servers_in_cron_job.mdwn new file mode 100644 index 0000000..311ae71 --- /dev/null +++ b/doc/todo/set_up_--check-servers_in_cron_job.mdwn @@ -0,0 +1,3 @@ +So I know when servers go down. --[[Joey]] + +[[!tag important]] diff --git a/doc/todo/usability_testing.mdwn b/doc/todo/usability_testing.mdwn new file mode 100644 index 0000000..de8e801 --- /dev/null +++ b/doc/todo/usability_testing.mdwn @@ -0,0 +1,3 @@ +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. Is it? +This and other parts of the keysafe UI need usability testing. diff --git a/doc/todo/use_cryptohash_argon2.mdwn b/doc/todo/use_cryptohash_argon2.mdwn new file mode 100644 index 0000000..61670a2 --- /dev/null +++ b/doc/todo/use_cryptohash_argon2.mdwn @@ -0,0 +1,2 @@ +cryptohash includes argon2 now, so it could be used instead of the separate +argon2 library. --[[Joey]] diff --git a/doc/todo/use_locked_memory.mdwn b/doc/todo/use_locked_memory.mdwn new file mode 100644 index 0000000..2d139a3 --- /dev/null +++ b/doc/todo/use_locked_memory.mdwn @@ -0,0 +1,5 @@ +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.. But, see [[remove_gpg_key_passphrase_from_backed_up_gpg_keys]]. + |