Open amingilani opened 10 years ago
gwadej
commented
9 years ago Agreed. That one issue bothers me the most. Allowing my private key on your server, even encrypted, requires a bit more trust of the keybase servers. If I understand the "in the browser" option, you would need to decrypt the key in the browser with javascript you supply. That requires significantly more trust in the keybase servers.
zQueal
commented
9 years ago I honestly don't see why another one of these threads is relevant at this point. It's been said in every instance of this topic that the ability to upload your private key won't be taken away, or disallowed.
Additionally, my point stays relevant--why the hell would you upload your actual private key that controls your entire life to a public server? When I joined keybase I created a new key, I didn't upload my established one. You don't give the key to the city to a stranger then get angry about what they do with the keys. Many people want to argue that fact, which is pretty moot IMO, but the fact still stands. Keybase is being beta tested right now. It's not meant to be used earnestly at this point. If you're using it for any other reason than testing, you're using it wrong.
So can we please lay this to rest, even if its just for now while Keybase is in beta? I won't say this isn't an important issue, however, opening more issue threads for the same topic is counterproductive and unhelpful--especially when the answer to said issue is well known.
For sanity, I'll state that I do not support uploading your private key to Keybase. At all. Which is why I haven't, nor would I--which is why I don't see any point to threads like these.
amingilani
commented
9 years ago opening more issue threads for the same topic is counterproductive and unhelpful
@zQueal, this thread was opened months ago, if you think this is a duplicate, please link it here and I'll close this.
When I joined keybase I created a new key, I didn't upload my established one. You don't give the key to the city to a stranger then get angry about what they do with the keys.
That's nice. Some of us didn't create a new key or upload an old one. You can operate it without uploading any keys at all.
I do not support uploading your private key to Keybase
I'm glad you hold the same opinion as me and @gwadej.
It's been said in every instance of this topic that the ability to upload your private key won't be taken away, or disallowed.
Read:
Encouraging private keys (especially since this service is meant to make PGP easy) to be tossed to an online server is extremely bad practice and should be discouraged, if not disallowed.
Thank you for taking the time to respond. I'll close this issue if it's frivolous, but until it's resolved, I'll keep it open.
I don't see any point to threads like these.
Now you're just being rude. I don't see any point to comments like these.
zQueal
commented
9 years ago I'll close this issue if it's frivolous
It's not necessarily frivolous, I just don't see its point of discussing this again--not only that but the software is still in beta. There are bound to be issues with the software in general causing security concerns, mostly because its a software that deals with cryptography, however you're challenging the entire basis of the software itself. Without the use of the private key by the web interface you are cutting functionality for those who cannot or aren't able to use the CLI by 50% rendering Keybase useless; as there are other methods of encryption besides PGP that would work even better if this were the case. Not everyone is versed in the workings of the command line, and I've come across quite a few people that are unable to even install node to get to the point where they could install Keybase to even begin working with the CLI. Without the ability to complete functions via the web interface that require the private key Keybase loses the entire idea behind the software; bringing simple crypto to those who don't know how.
You can operate it without uploading any keys at all.
This is entirely true, but like I said before you'd lose more than 50% of the functionality that Keybase provides without using the CLI. When pushing software like this the idea is to get far reaching adoption, not limiting yourself to those with technical knowledge. That's all I'm trying to say. If that came off as rude I apologize, it wasn't my intent.
amingilani
commented
9 years ago Otherwise, nobody gets fired for opening an issue, I'll keep this open. Also, I'll just quote you from https://github.com/keybase/keybase-issues/issues/518#issuecomment-52448796:
For future reference. You can easily unsubscribe from a topic if it's not going the way you like.
@malgorithms, don't close this issue like #160, please wait for atleast a real resolution. Thanks for the awesome work!
malgorithms
commented
9 years ago I'm happy to leave this open as a place for discussion. I'm unlikely to add much to it right now. I've said a lot already.
That said, one related topic worth reflecting on is deterministic keys. I bring this up because (1) it's gaining a lot of implementation success and approval. miniLock and, related, Peerio, are based on the idea that your private key is simply a deterministic function of a salted passphrase. And (2) because it's a similar convenience/threat model argument to passphrase-encrypted private keys.
In both these scenarios:
the attack you open yourself up to is a brute force/passphrase stealing/guessing attack. In both cases, the services argue:
One advantage of the first method (encrypting and storing on the server) is that you have one extra level of protection: a guessing or brute force attack can be throttled by the server, unless the server is compromised or data is stolen from it. At which point it is equivalent to the deterministic case.
I think it follows that if you consider the worst case scenario for the server's data integrity, it's equally bad as a deterministic key. But I open this up for discussion with all of you :-)
mgifford
commented
9 years ago Can we just change the default to No rather than Yes after you run "sudo keybase gen"? Right now the default is yes:
Push your encrypted private key to the server? [Y/n]
pkirkovsky
commented
9 years ago @mgifford +1 on the default option being No It's far too easy to mash the enter key and instantly make a very bad (IMO) security mistake, especially when going through a series of prompts on the command line.
At the very least, a better option would be doing something similar to SSH and requiring the user to explicitly type "yes" or "no".
SuyogSoti
commented
7 years ago Hey all
I do not know too much about crypto, but I have a couple of questions. Is it not possible to store a private key in the device, and then have one device push it to the others as the user logs on to more and more devices (keybase already keeps track of all of the devices). This way, the keys would not be stored in the keybase servers, and the user would have the private key available with all clients.
Also, if the user revokes permission from all devices, then tries to log back on, then would it be ok to regenerate the private and public keys. Keybase will already have known which user name is associated with which users' social accounts, so it would be able to handle the private and public key decryption in the back end. With this case, a layman user like me will not have to worry about storing keys, and the keys will also be transferred from one device to another. This would all rely on devices being able to communicate with each other in a secure way, which I do not think would be too hard because of the rigid way keybase keeps track of the devices.
Again, I am still learning more about this topic, and I am sure that I have a lot of misconceptions. Please help me by pointing out flaws so that I can learn more about this topic.
SlayerShadow
commented
6 years ago opening more issue threads for the same topic is counterproductive and unhelpful
If issues were opened so many times by different people then there is something actually in this, isn't it?
Can we just change the default to No rather than Yes after you run "sudo keybase gen"? Right now the default is yes: Push your encrypted private key to the server? [Y/n]
I'd like to suggest additional option that will point user to some warning that he tries to upload the private key to the public server. Something like this: "WARNING: You choose to upload your private key to keybase.io. If you understand consequences and completely sure with this action then you can proceed. Really upload? y/N"
This looks more like in terms of GPG - when I make any changes with keys, especially when generate a new key, i'm asking twice.
This way, the keys would not be stored in the keybase servers, and the user would have the private key available with all clients.
I'm not a cryptographic expert too but you transmit your key (unencrypted manually - just a standard GPG passphrase) through a third-party service so you never cannot be actually sure that this service will not keep (or make a copy of) your key. Only if you both did not sign a contract to not keep this kind of data. But even so.......
In any case I don't like the idea of uploading private keys to the server without any notice. Especially by default. It is blocker for me from using this service.
I'm not sure if this has already been discussed but every, single, place, you, look, securing your private key is of the utmost importance.
Encouraging private keys (especially since this service is meant to make PGP easy) to be tossed to an online server is extremely bad practice and should be discouraged, if not disallowed.
With all the elimination of trust Keybase promises with publicly auditable proofs, why would you make people upload keys to your server?