Live data from Hacker News

Keybase raises $10.8M

keybase.io

61–70 of 126 posts

Re: Keybase raises $10.8M

#61
post #31

The fatal problem with this plan is that all end user devices are by now hopelessly compromised. Take a look at the Snowden documents, which are now years behind the state of the art. It doesn't matter if your crypto is both bulletproof and easy to use. They'll just break into your phone or your laptop through a side channel and read the key. And you won't even notice.

Have it ocurred to you that different people have different threat models? Yes, if a powerful state actor really is after you, they will most probably find a way sooner or later. Crypto is still useful for lots of use cases. E.g. protecting data from competitors, stalkers or identity thiefs.

Has it occurred to you that if your device is full of side channels, anyone can use those side channels?

How can you create a legitimate-government-only side channel? You could do it by basing all encryption off a master key that only the legitimate government controls. However, there's no way for a legitimate government to force everyone to only communicate with the master key.

Any other side channel is going to be exploitable by non-legitimate-government's in some way.

Re: Keybase raises $10.8M

#62
post #46

Earlier quoted context omitted.

I don't know what you mean by "encrypt per email address." Who is doing the encrypting, and to who? Do you want to have multiple keypairs associated with a single keybase account?

You can encrypt with lots of things, for example $> keybase encrypt twitter://twitter_id -m 'message' But there seems to be no way to to it with an email address like this: $> keybase encrypt email://email@example.org -m 'message' Or maybe I did not understand something.

Yeah, email's a bit more complicated than twitter. I think for the time being, you want to just encrypt to a file and attach that. Maybe there's a standard (PGP mail?) that keybase could output to a file, but that doesn't tend to play well with the GUI mail clients that people typically use.

Re: Keybase raises $10.8M

#63
post #56

Earlier quoted context omitted.

Thanks for your opinion. >"U jelly?" certainly qualifies as that. I'd argue that maligning keybase as a hobby project qualifies as much as "U jelly?". At least it is discourse, rather than an anonymous downmod.

what do you mean by "maligning"? Second paragraph of their blog post: "Keybase started as a PGP keyserver hobby project, aimed at making key lookups as easy as knowing someone's username."

That's fair. When did Keybase start? They seemed to be much further along than hobby, unless they just started working full-time (and with $10million!).

Re: Keybase raises $10.8M

#64
post #46

Earlier quoted context omitted.

I don't know what you mean by "encrypt per email address." Who is doing the encrypting, and to who? Do you want to have multiple keypairs associated with a single keybase account?

You can encrypt with lots of things, for example $> keybase encrypt twitter://twitter_id -m 'message' But there seems to be no way to to it with an email address like this: $> keybase encrypt email://email@example.org -m 'message' Or maybe I did not understand something.

[deleted]

Re: Keybase raises $10.8M

#65
post #50

Keybase is the wrong way to do a PKI directory. First, people should have multiple keys/identities by default; multiple identities should be the normal thing everyone does. Single identities will be used by governments to control people. They'll also work against normal communication patterns where people speak differently to different groups (think parents, friends, coworkers.) Second, matching a name with social me…

1. You can set up multiple Keybase accounts if this is an issue for you. It doesn't seem like that much of a problem.

2. Most people do put enough personally identifiable information on their social media accounts. If you don't want to, that's fine, but you'll have to find some other way to identify yourself to people who you want to use your public key.

3. You can have Keybase manage it for you, if you want. Yes, of course there are problems with this, but it provides a reasonable compromise, especially if your threat model isn't a government entity (in which case, you're likely screwed anyway).

The truth is, most people have trouble working with more than one email account. Adding multiple sets of keys on top of it isn't going to make anything easier. At least with Keybase, I could get someone who isn't all that aware of security measures set up with public key encryption in a way they have a chance at using.

There's ideal, and there's better. Unfortunately, ideal has proven to be too onerous for people to use, but we can work on better.

Re: Keybase raises $10.8M

#66
post #62

Earlier quoted context omitted.

You can encrypt with lots of things, for example $> keybase encrypt twitter://twitter_id -m 'message' But there seems to be no way to to it with an email address like this: $> keybase encrypt email://email@example.org -m 'message' Or maybe I did not understand something.

Yeah, email's a bit more complicated than twitter. I think for the time being, you want to just encrypt to a file and attach that. Maybe there's a standard (PGP mail?) that keybase could output to a file, but that doesn't tend to play well with the GUI mail clients that people typically use.

Thanks for your answer. The main goal on my case is to use the email address as an identity (since it's currently the closest thing I have for this) and not to send encrypted PGP email messages. That's why I never really understood keybase. You can encrypt with a twitter id but not send a encrypted tweet with GPG anyway, so why can't you encrypt by email ? I assumed the most basic form of identity is an email address. Thanks again for your answer.

Re: Keybase raises $10.8M

#67
post #37

The fatal problem with this plan is that all end user devices are by now hopelessly compromised. Take a look at the Snowden documents, which are now years behind the state of the art. It doesn't matter if your crypto is both bulletproof and easy to use. They'll just break into your phone or your laptop through a side channel and read the key. And you won't even notice.

> all end user devices are by now hopelessly compromised This is news to me. Are there known side channel vulnerabilities for an arbitrary ubuntu desktop?

I'd like to know the answer to that question.

But also, this one:

    s/an arbitrary/each/

Re: Keybase raises $10.8M

#68
post #60

Earlier quoted context omitted.

Mine was more terse, surely. However, it accurately reflected my perspective, based on what I just read. I didn't present it as anything different. Further, I directly answered the question that was asked. Do you not think that is the general interaction structure of funding? Surely, it doesn't cover every case, but do you seriously think it did not happen in this case? No one has yet put forth any other scenario.

Again, the downvotes, and this entire sub-thread have nothing whatsoever to do with the structure of funding, and whether your scenario is more or less plausible than the money being left under their pillows overnight by an army of Oompa Loompas wearing magical flying tutus. It is (IMO) solely and utterly about "U jelly?". If you hadn't opened with that, you may or may not have been downvoted, but none of this discus…

>Either you get it, or you don't.

Yes, I like binary logic.

Comments about the parent's author vs. comments about the commitment level of the people behind the parent's content's focused project (which is therefore a comment about the author's of Keybase)

I guess there is a distinction there (or at least I just named some distinction), but I'm not really sure why one was judged more acceptable than the other.

Edit: Ok, I guess you (or some anonymous down-modder) want more.

> and this entire sub-thread have nothing whatsoever to do with the structure of funding

This is just plain false. You lampooned my scenario in your first sentence into this sub-thread.

Re: Keybase raises $10.8M

#69
post #50

Keybase is the wrong way to do a PKI directory. First, people should have multiple keys/identities by default; multiple identities should be the normal thing everyone does. Single identities will be used by governments to control people. They'll also work against normal communication patterns where people speak differently to different groups (think parents, friends, coworkers.) Second, matching a name with social me…

Interesting points. The below is a friendly disagreement from someone passingly interested in this field.

> First, people should have multiple keys/identities by default

I feel like you can do this already, no? Just create different Keybase accounts for each identity. I don't understand how having a single keypair prevents you from managing your contact groups however you like. They seem like orthogonal problems to me.

> Second, matching a name with social media is the wrong way to lookup others. It only works if people put enough personally identifiable information (PII) on their social media accounts

Key verification is the problem in crypto. Like it or not, many people already put tons of PII online. It's a perfectly valid way to verify lots and lots of people. Perhaps it doesn't work for everybody, but it's clear that keychains don't work. This is a different strategy to solve the verification problem, and I think it's got legs.

> Third, leaving people to manage their own private keys is worse for security than having them managed by others.

I understand your point here, but I disagree. Given all the server hacking going on these days, I'd much rather not have a single point of failure. Or several large points of failure, in the case of your distributed system. The odds of someone hacking keybase.io or keyexchange.google.com seem much higher than the odds of someone attacking my phone or my desktop.

I think it's a mistake that keybase allows uploading and storing private keys.

> I think the winning solution will be: a distributed

Your idea doesn't seem to solve the verification problem. Keybase's strength is that in order to subsume someone's identify, you have to hack several of their accounts. That's much more difficult than hacking a single keyserver. How do you verify that the key I get when I search your crypto-DNS system for irq-1 actually belongs to you?

Re: Keybase raises $10.8M

#70
post #50

Keybase is the wrong way to do a PKI directory. First, people should have multiple keys/identities by default; multiple identities should be the normal thing everyone does. Single identities will be used by governments to control people. They'll also work against normal communication patterns where people speak differently to different groups (think parents, friends, coworkers.) Second, matching a name with social me…

You laid out a number of points there, and I think some of them are indicative of what's really holding back security for the masses.

"Matching a name with a social media is the wrong way to lookup others" -- this is the one I take greatest issue with, because it's the way we know people now. All the people I collaborate with online now, I know them by those exact names. Coworkers, remote collaborators, friends on instagram, famous software engineers (whose work I might want to consume), even my own brothers... I know them by a set of these identities. This is how I know people.

To illustrate this point: if my own brother wrote me a message and posted it simultaneously on Twitter, Facebook, and LinkedIn, I would think "yeah, that's my brother." Moreover, and more importantly, if he left those posts up publicly, over time the strength of my conviction that he actually wrote the messages (and it wasn't a short-term compromise) would grow.

This works even for people you've maybe never met in real life. If hacker news user "jashkenas" announces on HN that he has a new version of CoffeeScript, I expect that's him. If he pairs it with a tweet, then I really expect it's him. The fact that this method works for possible strangers and loved ones is very powerful. Remember, this isn't just about secure messaging. If someone doesn't have any such identities, then there's always still the fallback: exchange an identifier in person.

The alternatives are so nasty -- in person meeting, coordinating enterprisey apps, and so on -- we'll never get anywhere with this kind of thing. The solution I think you are suggesting requires a lot of human effort to figure out if you have the person you want. This is one of the danger points of PKI. And one of the inconvenience points.

"Leaving people to manage their own private keys is worse for security than having them managed by others." Part of me wonders if you're just trolling. I don't understand this, and I've read your paragraph a few times. There is the confusion argument - that people don't understand how to manage them, which is a problem we're tackling. Our argument is that it's possible to build something usable (finally!) where people do in fact own their own keys.

But you go on to say "software glitches" and "updates" are dangerous for individuals who have device keys, and then suggest they'd be ok if their enterprises / social networks managed their private keys for them. In this case, you're talking about expanding the threats considerably, while still leaving client apps that need to be updated and do the work.

Post reply on HN