search

dyne / tomb

the Crypto Undertaker
https://dyne.org/software/tomb
GNU General Public License v3.0
1.32k stars 150 forks source link

[Feature request] Ability to 'bind' the secret.key to secret.tomb #177

Closed absorber closed 9 years ago

absorber commented 9 years ago

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:

  1. The key file.
  2. Passphrase to the key file.
  3. 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.

x3nu commented 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:

  1. The key file.
  2. Passphrase to the key file.
  3. 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.

JoelMon commented 9 years ago

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.

jaromil commented 9 years ago

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.

absorber commented 9 years ago

@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.

hellekin commented 9 years ago

Hey @absorber, I fail to understand a use-case for having the key with the tomb. Why not put the files in clear directly?

absorber commented 9 years ago

@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.

hellekin commented 9 years ago

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.

absorber commented 9 years ago

@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.

JoelMon commented 9 years ago

@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.

absorber commented 9 years ago

@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.

jaromil commented 9 years ago

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.

absorber commented 9 years ago

That makes perfect sense. Thank you for your eloquent explanation @jaromil :)