Show us the server: https://github.com/keybase/client/issues/6374
This comment may be of interest (we could release server code at some point, and I will take this as a vote), but I hope people reading this aren't distracted by Signal's flaw here.
[edit: chilled a bit!]
...
I get why you showed up here, but you're really not addressing the point of the post at all, and in fact you're trying to distract with the suggestion that Signal's publication of that code protects people from this flaw. It doesn't. At all.
Wow, that's a pretty hostile (and accusatory) response to a fair ask. This is one (small) step removed from accusing someone of shilling/astroturfing.
Let your product stand on its own merits. If you have a good reason why you won't open source Keybase's server implementation, own it. Don't undermine requests to open source the code by publicly accusing people of supporting a competing product.
The person you're replying to didn't make an argument in favor of Signal - or any other competing product, for that matter. In my opinion, your response is actively distracting from their request.
It's tough to compete on security because users struggly to know what's actually better (on top of needing convincing security is a worthwhile differentiator in the first place). A client that doesn't trust a server is a great improvement and "show us the server" is a terrible response.
If you have a good reason not to fulfill the request, charitably responding to the request with that reasoning is an educational opportunity for the audience. There's just no need to bring identities into the mix like this, and I think a dispassionate response outlining why the server need not even be trusted would stand on its own.
In other words - you don't need to be affiliated with Signal to be in favor of open sourcing the server-side code. It's a fairly common complaint on HN, and I can see why it was the top comment for a while even if I don't ultimately agree with the need to open source the code. Likewise, if you look at the link to the GitHub issue you can see many other people likewise asking for - or reacting to responses to - open source the server code.
Do all those people have conflicts of interest? Is it possible that the affiliation with Signal doesn't matter here? Then be charitable, and let your actual reason for not fulfilling the request stand on its own.
I mean other than coquettishly dropping a tantalizing hint by saying 'yet?'. That's nice, but insufficient.
I literally do not work for Signal.
We know you don't work for Signal. We also know that you very obviously have a close professional relationship (at the very least) with its founder.
Moxie and I have a close professional relationship but I'm not sure what bearing that has on asking for the code of Keybase's server to be open-sourced. That's not a biased statement, and I would say the same thing in any thread about Telegram, WhatsApp, or FB Messenger's privacy. It's all the same.
If you want trust, you have to be open source. That statement has absolutely nothing to do with Signal.
Yes I use Signal. Yes I'm a fan of the Signal team's work. No, I don't think Signal would be better off with a closed source server. Yes, I do think Keybase should open source their server.
I honestly have no idea why this is even controversial :/.
You have a professional relationship with the founder of one of their competitors. It's appropriate in those cases to note that you have a bias. I realize you don't think you have a bias, but that's the whole point.
> If you want trust, you have to be open source.
That's such a confusing statement, and a particularly misleading one coming from someone that works for a crpyto company.
The whole point of end to end crypto is that you don't need to trust the server.
> I honestly have no idea why this is even controversial :/.
That's the core of the problem. You have a professional relationship with the founder of Signal. If you comment on a thread about Signal, or it's competitors, we shouldn't have to click the link to your site to find that out.
Think of it as building trust...
I've been a fan of Signal since it was RedPhone and TextSecure and my professional relationship with Moxie is quite recent in the scheme of watching the rise of his projects. I apologize if my lack of awareness was offensive, it was unintended.
Edit: Just to be clear, I don't think you need to have the server open-sourced to trust the end to end encryption of the messages, but that's just one part of the overall trust model.
Surely you’d have a direct line to the Vatican if you had the pope as an advisor, no?
I think it's worth meditating on the tradeoffs of your system design. Nothing is perfect.
Signal is trying to do the best that it can, and I really think that the starting line in writing secure software is open sourcing the whole thing from top to bottom. Anything less isn't auditable.
Note: I edited this post to make the language more addressable. I love the work Keybase is doing, but I want them to open source their server.
Given the choice between having the server code open sourced or not, the choice that is higher trust has to be open source.
edit: To be clear, even if they open sourced the server right now, I would not even look at the code to determine if running the client was safe. The only time I would care to look at the server code is if the client's correct operation depends on the server running specific code. If it doesn't do that, then the server code doesn't matter. And if it does do that, I wouldn't trust the system, anyway.
Regardless, until you have a way to ensure the server is running the code you expect it to be running (can this even exist? what about hardware level attacks on the servers keybase is running?) the server code is useless from a security perspective.
The server is not outside of scope.
edit: Do you audit all of the software running on all of the routers between you and keybase's servers? Why or why not? If not, why does this reasoning not extend to the servers? Why would the routers not part of the whole system, top to bottom?
Let me phrase this another way: if there's nothing to hide on the server, why isn't it open source?
We can go back and forth on this forever. My position is simple: strictly speaking, it's more rational to trust open source software. Trusting closed source software ultimately boils down to "trust me". I would love to reduce the degrees to which we have to blindly trust the systems we use.
The answer is that they do have things to hide: anti-spam/anti-scam systems, for example. The question is if they are hiding something that matters for security. You can determine this by auditing only the client.
Sure, open source software is great, and has many uses. In this case, it has no use in ensuring that keybase is secure. Somehow, you don't have to trust a great many components in the secure software you use on a daily basis, and yet you have to trust keybase's servers because.. reasons? And somehow this trust is important even though you'd still be blindly trusting that they're running what you hope.
I won't argue that some people would benefit from the server being open source, but to argue that open sourcing it has anything to do with security is just inane and FUD.
You have to model the whole system to understand the threat model. Anything less is blind trust.
You prove that it doesn't matter by assuming that keybase is running the most malicious code possible, auditing your client, and deciding that the system is still secure. This is what auditing the client means.
Additionally, to bring up this fact again because it has only been hand-waved away: Even if the server was open source, there is no guarantee they are running that code. Thus, there is no benefit to security until systems exist (somehow?) to prove the server is running the code you expect.
Double additionally: even IF you can prove that the server is running what you expect, how do you know that some box, after https is peeled off, but before the request makes it to the server, is not sending the same request off to some other, malicious, server?
It's one thing to tell people that you aren't logging anything. It's another thing to show everyone you're not logging anything except the account creation date and last access date by open sourcing the software and then show exactly that in a response to a national security letter: https://www.aclu.org/open-whisper-systems-subpoena-documents.
If you didn't have the NSA letter, would you be able to verify the source code? If another project got an NSA letter and responded to it, would it tell you anything about the source code?
This is simple: Having the source code means you get to learn more from the other signals, no pun intended, of how that source code is used.
Again, as we move to a world where servers have more verifiable code running on them, the value of having open source code will increase.
I think you're trying to argue that open source is good, and I agree with you. Open sourcing the server has many benefits. The only point I have consistently been trying to make is that open sourcing it does not help with determining the security of the system, whatsoever.
edit:
> If you didn't have the NSA letter, would you be able to verify the source code?
No, but even if the code was open sourced, you would not be able to verify the code that is running.
> If another project got an NSA letter and responded to it, would it tell you anything about the source code?
It would tell you something about the code they are running, yes, but nothing about the code they open sourced.
> This is simple: Having the source code means you get to learn more from the other signals, no pun intended, of how that source code is used.
This is equally simple: the source code that is open may have nothing to do with the source code that is running, and you must assume that they are not equal when auditing the security of the system.
In contrast, if you received an NSA letter for keybase and they delivered similar information, you couldn't make any suppositions about the server's code.
To be extra, extra clear, to me, the future of the private internet is further verifiability of remote systems. That begins with Open Source. I concede that we aren't there for most parts of the systems we use today, but we are getting better (see attested contact discovery in Signal as one example).
The article on attested contact discovery states "Of course, what if that’s not the source code that’s actually running? After all, we could surreptitiously modify the service to log users’ contact discovery requests. Even if we have no motive to do that, someone who hacks the Signal service could potentially modify the code so that it logs user contact discovery requests, or (although unlikely given present law) some government agency could show up and require us to change the service so that it logs contact discovery requests.", which is exactly the point I'm making. They choose to solve it by signing code and ensuring that exactly that code is running (seems like they just move the trust to Intel. Hopefully SGX never has any bugs like https://github.com/lsds/spectre-attack-sgx or issues with the firmware, as noted by the Intel SGX security model document), which is fine, but an equally valid way to do this is to make it so that the secure operation of the system does not depend on what code the server is running.
Doing that has some tradeoffs: there's usually overhead with cryptography, or an algorithm you need may not even be possible (Signal disliked those tradeoffs for this specific algorithm), but for some algorithms, it's entirely possible to do. For example, one can audit OpenSSL's code base, and determine, regardless of what the middle boxes or routers do, that the entire system is secure. Just replace OpenSSL with keybase's client, and middle boxes with keybase's servers, and do the auditing. Hence, open sourcing the server is not necessary for security. Would it be great if more systems could be audited? Absolutely. Is it always necessary for security? Absolutely not.
edit: Another quote from the article: "Since the enclave attests to the software that’s running remotely, and since the remote server and OS have no visibility into the enclave, the service learns nothing about the contents of the client request. It’s almost as if the client is executing the query locally on the client device." Indeed, open sourcing the code running in the secure enclave is effectively open sourcing more code in the client.
I’m not yet prepared to publicly get into all of the nuances of SGX, but I think it’s worth noting that there’s something very interesting happening there. I look forward to being able to discuss my team’s technical findings on the subject in public.
To summarize why this is so interesting: the attack surface is the whole system. Enclaves let us extend parts of our trust model to systems we don’t own. That is a real change and, if it works, it’s going to change how systems are designed at a deep level. The problem is that there aren’t very many working implementations of sgx in the Wild (signal is the only one I know of).
We’ll see where the wind blows.
I'm tired of trying to get you to understand this point and have you respond with red-herrings and FUD. Please be intellectually honest when asking keybase to open source their server in the future, and don't claim that it's relevant to the security of the system.
Good day.
Please don’t come back and tell me “oh but you can use a vpn”. We have yet to build a real vpn that can stand up to serious scrutiny.
Edit: to be clear, we might be able to build routers that actually are blind routing oracles, but we haven’t done that yet.
Why do you presume that? I certainly don't believe in the security of many applications that I use. I generally try to avoid putting any damaging information into them though.
I still think it makes sense in terms of security. If I run a piece of client software X that connects to a server Y, it will always be better in terms of security if I'm in control of what runs on Y. This is independent on how X has been audited. So yeah I would argue that security is also a reason.
This is a subtle point, but that thinking is misguided. You, as a client, have no control over what server you’re actually talking to. The only way to be sure you are secure is to be secure independently of if the server has been hacked, or is malicious, or whatever. Thus, you design your system such that the client only discloses information that is allowed to be public to the server (public keys, encrypted messages where the server can’t decrypt it, etc). In that way, you don’t care what code the server is running, and auditing the server makes no difference to security.
The whole purpose of cryptography is to reduce the set of things you need to trust. Including the server in the trusted base is not only a worse design but a false sense of security if your trust ends up misplaced (hacked).
So, this is different than how a bank would work, for example. In the case of a bank, you have to trust that their servers are secure, and their software being open would help with auditing that. In this case, keybase is not the endpoint you’re talking to: another keybase client is. The keybase server is just an intermediary, just like any router on the internet.
Your comment would be much better without any allusions to this person's affiliation. Just answer the question directly without casting aspersions. You seem confident in your answer, so that shouldn't be hard.
That's a very useful property, because even if the server is open source, that doesn't guarantee that what the Keybase team is actually running in production matches the source they've released.
So I would say a system where the clients don't (and don't need to) trust the server, even if no server source is publicly available, is still strictly better from a security standpoint than a system where the clients do need to trust the server, and source is available. (Assuming, of course, that the design of the system as a whole is sound, and that clients have been audited to ensure that they follow the design of the system correctly.)
It is better to not even have to think about looking at the server-side code.
The best case would be there is no “server” at all, but that’s the Internet we have to work with today to enable the usability and user experience they are going for.
Keybase looks really really cool, and I would love to use it, but I can't in good conscience recommend something that is cagey about the half-open nature of their product, especially when the server. It is by definition "man-in-the-middle"-ing all your data, and if you can't inspect it you can't reasonably trust it.
That is the point the article is making, and that's what it sounds like the Keybase client is doing--not trusting the server by relying on client-side encryption rather than storing keys on the server.
The fact that you can change keys and see old messages without the other party sending them to you using your new key points to serious problems with these other apps. It seems the Keybase client rightly considers the channel insecure.