Feature Request: Option to not upload the private key

[maltemuth]

Currently, mitro uploads the private key in order to share it with clients using the same account. This obviously creates some convenience, but also some security "issues":

1) The private key is known to anyone with access to mitro's data storage. Though protected by a password, it is possible to "steal" the key file and bruteforce it without anyone noticing. 2) If an account's password is compromised, so is the key - and all the clients at once. Two-Factor Authentication somewhat alleviates this issue. 3) Currently, I have no control over where my secrets go, e.g. I do not want certain secrets available on my phone, while others certainly should be there.

With a new option to not upload the private key, but instead having a key pair on each client, these concerns would be gone and the sole attack vector remaining would be the client (and the hosting machine itself). Additionally, I could control which secrets are available where (see 3)).

I'm more then happy for feedback on whether or not this actually a good idea.

[oderwat]

To share different keys on different devices you could just create multiple accounts and add yourself into teams. This would also make the key for those devices kinda unique for that device.

My thoughts about not uploading the key:

At first it sounds good!

But if you add a second device it can not decrypt any data because you need the key from the first device to do that. So you would need to add a second key on the first device for the data to be (additionally) encoded for the second key (which also increases the storage used). It also may last a long time to re-encode and upload all the new data.

Then you would need to securely transfer this key to the second device manually.

In addition those keys will be encrypted with the same passphrase as the first key (you may not want to have different master passwords for each device).

After all... if somebody can grab your key from the servers and your passphase is "bruteforceable" and you do not have 2 factor enabled. You are doomed.

P.S.: I personally think that adding OTP with YubiKey instead of a master pw would probably be a safer solution. But that has its own limitations and problems.

[maltemuth]

The two devices / accounts could encrypt and/or handshake using each other's public keys, so no key transfer is needed. I think this is what mitro does already (nobody needs my key to decrypt shared secrets).

Right?

[vijayp]

Are you worried your key may be brute forced by guessing pass phrases to reverse pbkdf2? If you pick a really strong pass phrase this shouldn't be a problem. Besides, if you're worried about someone brute forcing, all your private secrets in Mitro are encrypted for a hidden private group. That group key is encrypted for your private key using rsa. Brute forcing that would reveal all your passwords as well, so it's not clear that not uploading your key would be a big win On 14 Aug 2014 09:09, "Malte Muth" notifications@github.com wrote:

The two devices / accounts could encrypt and/or handshake using each other's public keys, so no key transfer is needed. I think this is what mitro does already (nobody needs my key to decrypt shared secrets).

Right?

— Reply to this email directly or view it on GitHub https://github.com/mitro-co/mitro/issues/45#issuecomment-52180555.

[oderwat]

@maltemuth Yeah! Of course one does not need to transfer a new private key to the second device don't even know why I put that in :)

But what I actually meant is that your first device has to encrypt and upload all the data again for a second key which. And that other key has the same passphrase as the first one.

This would also mean, that adding/changing a secret on one device had to encrypt it every time for all other devices and increases the amount of storage and syncing overhead. I already have Mitro running on 7 different "devices".

I still think that one "has to be able to trust" the key encryption in the first place. Stealing the encrypted keys should not break the whole system. Keeping the secret key "secret" should only be a top priority if it is not protected with a passphase.

[maltemuth]

@vijayp That's a very good point. I actually know next to nothing about bruteforcing, that's why I stopped my train of thought right there.

@oderwat I'd actually sacrifice bandwith, cpu time and storage for "some more" security. As vijayp has pointed out, there might be very little to gain from my proposal.