7 ms·

Show us the server: https://github.com/keybase/client/issues/6374 https://github.com/keybase/client/issues/6374

giancarlostoro 8y ago
Why I like Wire in this regard, they seem to have their front-end and back-end open sourced. I believe their servers AGPL licensed, but it still allows you to run your own instance. Sadly people are highly more likely to use either Signal or KeyBase than Wire, which I think is my favorite since it doesn't tie you to a phone number (tip: register from the desktop first), and you can delete all your account information.
- kerouanton 8y ago
  I also use and like Wire for the same reasons.
  - giancarlostoro 8y ago
    I use all I have listed, I like the UI for KeyBase the most personally especially the way it handles social proofs where you need to verify yourself through a crypto key or another device. I wish Signal would just do this, but it's too married to phone numbers that it's suspicious in that simple regard. I use Signal with my wife, so for us to verify our keys it's very easy and simple.
icelancer 8y ago
"Open source project"
99052882514569 8y ago
It's on their roadmap, guys.
- Arkanosis 8y ago
  Is it? In the aforementioned issue, keybase-travis says “it still isn't”.
nickpsecurity 8y ago
To Keybase people here, I'm not sure why you can or won't open/free the software. However, it might be possible that you meet your goal by using shared source that licenses published source for specific uses as educational/academic, security review, and/or build locally from source. Doesn't allow commercial use or forks of that code. There's precedent for that in security software, like Cryptophone doing it (below) for review. I suggest considering an option like that if open/free source doesn't work since it still increases confidence in Keybase. https://www.cryptophone.de/en/background/source-code/ https://www.cryptophone.de/en/background/source-code/
- lallysingh 8y ago
  They commented today that it's to avoid some sort of spam problem.
  - mbrubeck 8y ago
    This is the same reason pg gives for not releasing the full source code for Hacker News.
drexlspivey 8y ago
If the client is open and you can see what it sends to the server, why do you care what the server is doing? It shouldn't be able to do anything nefarious and all the crypto happens locally afaik.
malgorithms 8y ago
It _seems_ you (someone from the Signal project?) are actively diverting from the point, with what is ultimately a security theater request. Keybase's app - which IS open source - doesn't trust the server at all. We could be running anything server-side, regardless of what we do or don't publish. Meanwhile, Signal's story is "you MUST trust our server, over and over again," as the blog post explains. Unfortunately there's no way to know what's happening on the server. So being like Signal and publishing your server source is strictly worse than being like Keybase and not (yet?) publishing server-side source. At any time, Signal could be throwing in these fake key upgrades, either due to running other source code on purpose, or being forced to, or just plain getting hacked. The most malicious Keybase server could not. 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!]
- throwawaymath 8y ago
  > But to be clear, you're actively diverting from the point. ... 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.
  - drexlspivey 8y ago
    Even if they publish their server code there is no way for anyone to verify that it's the code they are actually running and it would be just a PR move. If the client implementation is good there should be no way that the server can compromise any message.
zaroth 8y ago
I’m saddened this is the top comment, as it appears to be little more than trolling. 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.
elagost 8y ago
This can be applied to pretty much any security-focused product, or product claiming to be secure/encrypted. If it relies on an unknown number of proprietary/closed-source components, it can't be trusted. Keybase, WhatsApp, Telegram, and iMessage are all good examples of this. If your code can't stand up to public scrutiny it might not be able to withstand attack. I'm not willing to blindly chuck messages into a black box and hope what comes out the other end is exactly what I put into it. (This complaint is not specifically about Keybase; in fact the linked article and a few comments say their client doesn't trust the server at all, which is really cool. Point still stands.) 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.
- dfischer 8y ago
  This is technically not true because the client is the source of truth - not the server.
  - elagost 8y ago
    Thanks for the correction. I've not heavily investigated Keybase but I believe this point applies to the other products mentioned.
- nulbyte 8y ago
  > ...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.
kelnos 8y ago
It's a shame that it's not open source from the perspective of people being able to self-host, but if you don't need to trust the server (as Keybase clients don't), then the security of the system is not weakened one bit. 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.)

Why I like Wire in this regard, they seem to have their front-end and back-end open sourced. I believe their servers AGPL licensed, but it still allows you to run your own instance. Sadly people are highly more likely to use either Signal or KeyBase than Wire, which I think is my favorite since it doesn't tie you to a phone number (tip: register from the desktop first), and you can delete all your account information.

kerouanton 8y ago
I also use and like Wire for the same reasons.
- giancarlostoro 8y ago
  I use all I have listed, I like the UI for KeyBase the most personally especially the way it handles social proofs where you need to verify yourself through a crypto key or another device. I wish Signal would just do this, but it's too married to phone numbers that it's suspicious in that simple regard. I use Signal with my wife, so for us to verify our keys it's very easy and simple.

icelancer 8y ago

"Open source project"

99052882514569 8y ago

It's on their roadmap, guys.

Arkanosis 8y ago
Is it? In the aforementioned issue, keybase-travis says “it still isn't”.

nickpsecurity 8y ago

To Keybase people here, I'm not sure why you can or won't open/free the software. However, it might be possible that you meet your goal by using shared source that licenses published source for specific uses as educational/academic, security review, and/or build locally from source. Doesn't allow commercial use or forks of that code. There's precedent for that in security software, like Cryptophone doing it (below) for review. I suggest considering an option like that if open/free source doesn't work since it still increases confidence in Keybase. https://www.cryptophone.de/en/background/source-code/ https://www.cryptophone.de/en/background/source-code/

lallysingh 8y ago
They commented today that it's to avoid some sort of spam problem.
- mbrubeck 8y ago
  This is the same reason pg gives for not releasing the full source code for Hacker News.

drexlspivey 8y ago

If the client is open and you can see what it sends to the server, why do you care what the server is doing? It shouldn't be able to do anything nefarious and all the crypto happens locally afaik.

malgorithms 8y ago

It _seems_ you (someone from the Signal project?) are actively diverting from the point, with what is ultimately a security theater request. Keybase's app - which IS open source - doesn't trust the server at all. We could be running anything server-side, regardless of what we do or don't publish. Meanwhile, Signal's story is "you MUST trust our server, over and over again," as the blog post explains. Unfortunately there's no way to know what's happening on the server. So being like Signal and publishing your server source is strictly worse than being like Keybase and not (yet?) publishing server-side source. At any time, Signal could be throwing in these fake key upgrades, either due to running other source code on purpose, or being forced to, or just plain getting hacked. The most malicious Keybase server could not. 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!]

throwawaymath 8y ago
> But to be clear, you're actively diverting from the point. ... 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.
- drexlspivey 8y ago
  Even if they publish their server code there is no way for anyone to verify that it's the code they are actually running and it would be just a PR move. If the client implementation is good there should be no way that the server can compromise any message.

zaroth 8y ago

I’m saddened this is the top comment, as it appears to be little more than trolling. 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.

elagost 8y ago

This can be applied to pretty much any security-focused product, or product claiming to be secure/encrypted. If it relies on an unknown number of proprietary/closed-source components, it can't be trusted. Keybase, WhatsApp, Telegram, and iMessage are all good examples of this. If your code can't stand up to public scrutiny it might not be able to withstand attack. I'm not willing to blindly chuck messages into a black box and hope what comes out the other end is exactly what I put into it. (This complaint is not specifically about Keybase; in fact the linked article and a few comments say their client doesn't trust the server at all, which is really cool. Point still stands.) 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.

dfischer 8y ago
This is technically not true because the client is the source of truth - not the server.
- elagost 8y ago
  Thanks for the correction. I've not heavily investigated Keybase but I believe this point applies to the other products mentioned.
nulbyte 8y ago
> ...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.

kelnos 8y ago

It's a shame that it's not open source from the perspective of people being able to self-host, but if you don't need to trust the server (as Keybase clients don't), then the security of the system is not weakened one bit. 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.)