Closed absorber closed 9 years ago
Like you mentioned yourself it wouldn't be the safest idea, if you really want to do this, you always could put them in an archive together On 5 Dec 2014 00:54, "absorber" notifications@github.com wrote:
Hi, I'm pretty new on Git(Hub) and as such I'm not sure how to report new issues (or feature requests for that matter). If you have a comment then please let me know how I could do things better next time :)
If I'm not mistaken, as of now I have to have 3 things to access the tomb:
- The key file.
- Passphrase to the key file.
- The tomb itself.
Although this makes it so that there is no single point of failure, you can still lose access if you lose 1 of those 3 things. So hence, if there was an extra option to somehow merge the .key file with the tomb (so that only the passphrase would be required to access the tomb), it would make certain things easier in some situations.
Now I know that this is a dangerous proposition, as it gives the user more convenience at the cost of security, so perhaps it's a good idea to not let this be a default and if the user still chooses for this option, then warn the user using lots of uppercase words and exclamation marks.
— Reply to this email directly or view it on GitHub https://github.com/dyne/Tomb/issues/177.
Keeping the keys separate from the tomb is a feature in it self.
If you are worried about loosing your key look into using something like Shamir's Secret Sharing, SSSS, to protect your self from loosing the key or just do what @x3nu suggested and place the key along with the tomb in the same archive.
SSSS or other implementations of Shamir's are in Tomb's TODO since long. Will be implemented some time in the future (quorum key pieces), but that will add complexity to the key function not diminish it. @x3nu answer to this issue is correct, there is no feature to be added. Thanks for your thinkering.
@x3nu Hmm yeah haven't thought about putting the tomb+key into an archive. Although it would require some extra steps which get into the way of convenience.
@JoelMon I've only vaguely heard about SSSS, I'll research that.
Thinking back though, going out of the way of implementing this feature for the tiny bit of added convenience probably isn't worth it in the end. Sorry for any inconvenience.
Hey @absorber, I fail to understand a use-case for having the key with the tomb. Why not put the files in clear directly?
@hellekin well I don't really want to lose access to a tomb if the key is lost and also the convenience of managing just 1 file + passphrase was somehow comforting for me.
Oh, I see. Hmmm. This is probably not a practice we want to encourage for Tomb. "Do not put all your eggs in the same basket."
There's a feature that you can use to make a paper copy of your key, so you won't fear losing it.
@hellekin absolutely, and it shouldn't be encouraged. This is why (if implemented) bells and gongs would have to sound in the form of warning messages when attempting to do so.
@absorber, an analogy would be the door to your safe. Would you keep the key or code to your safe near the safe? Probably not, yet you need a backup in case you lose the key/code, right?
So what do you do? You keep a backup of the key/code far from the safe.
Is it inconvenient? Sure. Is it safer? No question about it.
You can take your key, and split it up. For example: take the key and split it into 3 parts using SSSS. Store one on a USB stick and hide it in the backyard, the other print it and store at work and the third give it to a family member in the form of a note on page 50 of a book.
In order to reconstruct your key you will need all three parts.
Is it inconvenient? Sure, is it safer? No question about it.
In the end if you are protecting something that can cause a lot of trouble for you or get you killed, you will prefer to loose the key forever than have someone learn the secret.
@JoelMon If the key would only be functional to access the safe in combination with a good password, then I'd be inclined to leave my key near the safe because I would know I'd be the only one in control of the password.
In order to reconstruct your key you will need all three parts.
I'm also unsure yet as of how SSSS works because I didn't have time to research it yet, but if I have to split the key in 3 parts and then worry about all of the 3 parts of the key then that's extra headache for me. Now I have to worry about not losing my passphrase, my tomb and one of the 3 parts of the key.
So please correct me if I'm wrong, but the points of failure seem to only multiply instead of becoming divided and distributed.
Anything like SSSS will be entirely optional of course, useful in certain situations and certainly not weaker when needed (I dissent from your analysis about it, but won't argument further).
FYI: Tomb's core concept is key and password separation, something that has been and will be always recommended in our documentation. Tomb's design will always follow directions to increase its security from this base scheme, not decrease it.
If you insist about keeping the key in the same place as the Tomb, you can do that and snap it into a command with an alias or script, which we anyway encourage having when using Tomb, since that can also enhance deniability. Yet Tomb's documentation will always discourage keeping keys close to Tombs.
If for some reason you insist this shouldn't be so, please desist advising to change Tomb's threat model and look for other software to satisfy your needs, since there is plenty out there, like cryptkeeper based on cryptfs for instance.
happy hacking.
That makes perfect sense. Thank you for your eloquent explanation @jaromil :)
Hi, I'm pretty new on Git(Hub) and as such I'm not sure how to report new issues (or feature requests for that matter). If you have a comment then please let me know how I could do things better next time :)
If I'm not mistaken, as of now I have to have 3 things in order to access the tomb:
Although this makes it so that there is no single point of failure, you can still lose access if you lose 1 of those 3 things. So hence, if there was an extra option to somehow merge the .key file with the tomb (so that only the passphrase would be required to access the tomb), it would make certain things easier in some situations.
Now I know that this is a dangerous proposition, as it gives the user more convenience at the cost of security, so perhaps it's a good idea to not let this be a default and if the user still chooses for this option, then warn the user using lots of uppercase words and exclamation marks.