9 ms·

Refusing to verify myself: I am liz on Keybase.io

201 points by achernya 13y ago

raverbashing 13y ago
So to verify a key I need to install npm? No thanks. " It doesn't seem particularly safe for me to trust my valuable PGP keys to this system." I agree
rsync 13y ago
I've only been glacing here and there, but I keep seeing discussion of uploading ones private key to keybase being an actual mechanism that is supported / encouraged / extant ? Surely not...
- opendais 13y ago
  https://keybase.io/ https://keybase.io/ "Keybase.io is also a Keybase client, however certain crypto actions (signing and decrypting) are limited to users who store client-encrypted copies of their private keys on the server, an optional feature we didn't mention above. On the website, all crypto is performed in JavaScript, in your browser. Some people have strong feelings about this, for good reason."
- rdl 13y ago
  The existence of that option is utterly insane IMO. I assumed it was some kind of IQ test for users; if they accept the offer, they get deleted. Sadly, that seems not to be the case.
  - maxtaco 13y ago
    We seem to have hit a real nerve here. I ask everyone to question their assumptions just for a moment. If you post a public key, you are letting the world see p*q. Is it insane to let some people see AES_k(p,q) if k is 256 random bytes? If you think yes, then you are making a strong judgment about the relative difficulty of two very different problems in Crypto that are thought to be quite hard. I realize there are issues surrounding coming up with good k's and keeping those k's secret; are these issues at the core of people's objections?
    - lifeisstillgood 13y ago
      As the article pointed out, what if your key (AES_k) is compromised? I mean what is the point of storing `AES_k(p,q) if k is random` unless you keep k somewhere? What do you use that for? I like the idea of a common way of proving one owns certain social identities. It is probably worth pointing out that the level of trust we give varies - Google "trusts" I own the domain when I put their random key on my homepage. Its not the kind of trust we would send (a lot of) money using, but its the level you guys seem to be aiming for - its a good level in a fair society.
      - maxtaco 13y ago
        k is derived from a password in this case, so capture of the password implies capture of k. We give people the option to store their encrypted secret keys on our server to make it easier to manage their key and sync it across their devices.
        tveita 13y ago
        So when you say "if k is 256 random bytes" it's a flat out lie? e: if k really was 256 random bytes, or bits even, it would mostly be an unnecessary complication. But that's a completely opposite situation from a key derived from a user chosen password.
        maxtaco 13y ago
        It was a thought experiment to encourage people to think about the issue at hand and not dismiss it with a knee-jerk. Your concern is now key stretching and password selection.
        tveita 13y ago
        Well, no, my concern is still to tell people to stay away from Keybase.io, or if they have to use it, to not upload their private key even though it seems to encourage you to, or if they have to upload their key, to use a really strong password and not use the key for anything else. In that order. I think that asking people for their private key is a bad thing that bad sites do. A password derived key isn't random, and no amount of key stretching or pretending will change that.
deleted 13y ago
[deleted]
- cortesoft 13y ago
  What? Why?
- doesnt_know 13y ago
  One users "stale" is another's "stable".
- lizdenys 13y ago
  My machine is going to be upgraded to the next LTS, 14.04, sometime over the summer, but that doesn't change the fact that 12.04 will still be around in 2017. More importantly, 12.04 is the most current Ubuntu LTS. It's definitely still around now.
deleted 13y ago
[deleted]
eik3_de 13y ago
Curious: Why do people choose JavaScript/node.js to write command line apps over traditional languages for that task like python or ruby?
- jonny_eh 13y ago
  Why do people choose python or ruby to write command line apps over traditional languages like BASH, PERL, and C?
  - Crito 13y ago
    The primary argument against node.js (and perhaps ruby) AFAIC is that many users will not already have it installed. Python/Perl/Bash you can count on all users having. C is a fine choice, but of course requires more packaging to be user friendly. I've used zsh as my interactive shell for years, but I always still write bash scripts instead of zsh scripts. You can count on bash scripts running just about anywhere.
  - EpicEng 13y ago
    Because they don't know BASH or Perl and writing a Ruby/Python script is more often than not faster and easier than doing the equivalent in C?
  - rsync 13y ago
    Exactly - I read: "Why do people choose JavaScript/node.js to write command line apps over traditional languages for that task like python or ruby?" and was agreeing with the first part of the sentence and then laughed out loud at the end ... Are we really in a world where ruby is the old school traditionalist way to write unix utilities ?
    - exelius 13y ago
      I was working with Capistrano almost a decade ago when it was called SwitchTower, so yeah -- it is kind of old school considering most "startup" developers are under 30.
- 13y ago
shazow 13y ago
I had a similar issue with the verifying process. I opened an issue requesting better documentation on the signing command so that people can write their own clients: https://github.com/keybase/keybase-issues/issues/174 https://github.com/keybase/keybase-issues/issues/174
- malgorithms 13y ago
  Yeah, thanks for making this issue. (Chris here, one of the two working on Keybase. I commented on that issue recently.) Getting proofs working totally outside our alpha client (and getting them well documented) is something we're working on this week. Keybase will not require running Node at all to interact with it. There will be 2 ways to "prove" yourself as a programmer on Keybase: 1. running `keybase prove github` (or whatever service) which is interactive; the keybase client can generate the nice statement for you and pass it off to GPG for signing. This is already working. 2. running something in your shell which requires nothing but gpg and standard shell commands. The key elements here are that you need to generate a signed statement connecting your two accounts, and you need to post it on github. This is pretty simple and won't require Node at all. Oh, and 3. using some other software of your choice that implements 2. The reason #2 isn't documented yet is that it's a bit more complicated in certain cases. Consider what it takes to perform a twitter proof (click the "show the proof") https://keybase.io/chris/sigs/DZ9rccBD8u-Att6kQzhHHtw-924s7iNt05dB https://keybase.io/chris/sigs/DZ9rccBD8u-Att6kQzhHHtw-924s7i... The signed statement itself isn't hosted on twitter (it won't fit) but needs to be boiled down into an agreeable tweet-sized hash. In order to prove twitter manually, you need to generate this statement, boil it down, make the tweet, and push the statement to Keybase. All this will come, and our goal with Keybase isn't to require Node or npm for anyone.
  - 0x006A 13y ago
    Can you document the api calls neede for #2?
    - malgorithms 13y ago
      yes, sorry if that wasn't clear. What I'm saying is that we'll have them documented very shortly. It's a priority for us, which I believe will address the OP's issue. We'll have documentation on: - what needs to be in the signed statement - how to hash the statement for safety on the platform you're posting, if necessary (twitter: yes, github: no, DNS TXT: yes, web domains: no, etc.) - how to tell Keybase about the statement (API call) - how to post the statement on Keybase (API call; this is needed in the scenario where it's hashed, twitter style) These will all be proof specific, which is necessary for reasons you can imagine. Character encodings allowed, where proofs go, what length they can be, etc., what goes into a proof (username?), etc., are all platform specific. But the goal is that someone can do this with software of their choice.
deleted 13y ago
[deleted]
- kylec 13y ago
  If you don't upload your key to keybase.io, you need the command-line tool to generate the file to upload for you, and then subsequently verify it. She can't install keybase via npm because the version of npm she has with her OS is too old to install it. Therefore, she can't verify.
deleted 13y ago
[deleted]
rdl 13y ago
In reality, the biggest risk for routine comsec with pgp is that no one uses it because it's difficult, but the very specific app of code signing is something where keys need a lot of protection IMO. (I am mostly fine with START TLS for email security 99.99% of the time) The thing which terrifies me is that the npm keybase app asks for my GPG key directly in the same window, and it's impossible for me to (easily) tell when the password prompt is from my GPG binary (which I pretty much trust) vs. the npm binary. I'm using keybase now (rdl), mostly because I trust Chris Coyne personally, and because my key is old. I'm creating a new 4096 RSA key soon, and will be a lot more paranoid about protecting it -- it will only ever exist on read/use only smartcards after initial generation on a secure machine. (sadly, openpgp card doesn't support export and replication, so to be durable, I have to generate it externally and load onto a bunch of cards and then delete the external key; I'm not willing to trust my keys to a single smartcard I carry with me.) Using keybase with gpg agent is maybe a bit safer. I don't really mind being forced to do bad stuff by keybase, due to the risks to them if they're caught, as long as it doesn't expose my keying material. gpg agent plus a hardware smartcard should mostly protect me. The pure-software alternative would be a bunch of text-file messages which I can manually cut and paste and move around between clearly-distinct processes running in separate shells/windows (or machines!). I've been thinking about something a lot better than openpgp card, though, as a secure end-user key management device, with more than just key protections. Unfortunately that means making custom hardware, and that makes little sense in the volumes PGP achieves; maybe if there are other client-side security credentials like ssh or bitcoin, I'd do it.
- maxtaco 13y ago
  There's one instance in which we prompt for your PGP password directly, since gpg doesn't give us command line access to the needed feature: that's adding the username <you@keybase.io> to your public key if it's not already there. Aside from that, we never need your PGP password and just rely on gpg to prompt for it when needed. If you're seeing other prompts, it could be bug, please let us know!
  - rdl 13y ago
    The point is that in a terminal window I have no idea what comes from the keybase binary vs. the gnupg binary it calls out to. You could throw up a convincing looking prompt, steal my passphrase (optionally crashing or passing it on to the real binary to delay suspicion), and then send the key and the passphrase back to your servers. Realistically, I'm not going to validate the keybase binary, npm, etc. every time I update the app. (and even if I am, many users won't). And a "user of interest" could be given a "special" binary pretty easily.
kylec 13y ago
I like the idea of Keybase.io, but I would prefer to use it in a way in which I don't have to trust them at all. As it stands, you need to install their command-line tool and have it directly manage your GPG keychain. For that, I'd prefer to have a platform-neutral tool that's been independently audited and managed by my OS's package manager rather than their keybase-installer tool which seems to want to update very frequently with who-knows-what changes.
- oijaf888 13y ago
  The changes are all pretty well documented in their git repo.
  - kylec 13y ago
    How do I know that the changes keybase-installer is downloading are the same as those in the repo? I'd have to do a lot of legwork every single time I update just to be sure. Better to use a tool I can verify once and use forever, or better yet, not use one at all.
    - maxtaco 13y ago
      Hopefully the pace of changes will slow down once we arrive on the correct core feature set and we sort out the bugs. An earnest thanks to HNers and others for being such great alpha testers BTW.
  - deleted 13y ago
    [deleted]
- tlrobinson 13y ago
  It looks like you can just do this to import a key into GPG: curl https://keybase.io/[them]/key.asc | gpg --import It won't show you the identity proofs though.
  - kylec 13y ago
    Interesting, I didn't know that. I still need some way to produce the verification files/tweets for my own account, though, and currently the only way to do that is with the client. (Maybe it works in the browser if you upload your key, I did not do that for the same reason the post author didn't.)
deleted 13y ago
[deleted]
jrochkind1 13y ago
You just have to know that you're placing all your trust in keybase. If keybase says they have verified that `liz` is a certain facebook account, and you are acting based on that in encyrpting something to `liz`, you are trusting that: * keybase acted honestly * nobody compromised keybases software when it was doing the verification * _after_ it did the verification, nobody managed to get keybase to switch out `liz`s key for some other key that wasn't really liz's (either because keybase was compromised, or keybase was untrustworthy... maybe because the government made them be?) That last one is the kicker for me. If keybase catches on, surely they are going to get government orders to swap our one key for another key at some point. The traditional web of trust does not require trusting any of those things, or at least not in those simple forms. On the other hand, yes, there are reasons traditional PGP hasn't caught on, and usability is a big one. But, still, to compromise security for usability... if you go all the way there, you just wind up where we are now, not secure at all, right? So, okay, is there value in going some of the way there, and getting some improved security but not as much as you could, for a more usable experience? Maybe. The danger is that people will think they are getting a lot more security than they are getting, and that situation can be worse than no security at all. One thing Snowden taught us is that if you have to trust a third party to be honest... it's not that the people running keybase aren't honest, it's that the government will _compel_ them to be dishonest if it ever matters to them.
- lwf 13y ago
  If you trust Twitter/Facebook/Github, you can verify assertions about account ownership by retrieving the signed message from those services and verifying they encode the correct data and that the signatures verify. However, this does not protect against a malicious service provider from modifying the message to replace it with a different user.
- davmre 13y ago
  It's not correct that you need to trust Keybase. The way that someone verifies their social identity is by posting a tweet (or equivalent) signed with their private key. So you can look up someone's public key on Keybase and then verify that Keybase gave you the correct key, by checking the signature on their original tweet / other social verification posts. Assuming you actually do this level of verification yourself (rather than allowing keybase to do it for you), the only thing you have to trust is that Keybase/Twitter/Github/Facebook/etc aren't all simultaneously colluding to give you a bad key. That seems to me like a reasonable assumption in pretty much all plausible circumstances.
trollingineer 13y ago
Don't worry liz -- you'll always be a whiny little twat to me on Keybase.io.
sp332 13y ago
You can build a newer version from an official Ubuntu source package. Start by adding a line to a file in /etc/apt/apt.conf.d/ that pins all your packages to 12.04, "precise": APT::Default-Release "precise"; Then add a line to your /etc/apt/sources.list to include saucy (or trusty), which has the right version of node. deb http://archive.ubuntu.com/ubuntu saucy main restricted universe deb-src http://archive.ubuntu.com/ubuntu saucy main restricted universe Saucy won't be supported after this year. You can either use Trusty now, or wait for Trusty to be officially released next month and then switch. Next, run these: sudo apt-get update sudo apt-get build-dep -t saucy nodejs sudo apt-get -b source -t saucy nodejs This puts the packages in the current directory. Now just install the one(s) you want: dpkg -i nodejs_0.10.15~dfsg1-4_amd64.deb Edit: wow, I just noticed how many packages that build-dep step pulls in. I hope that doesn't step on anything important :( At that point, you might as well just add a file /etc/apt/preferences.d/01node with these lines: Package: nodejs Pin: release n=saucy Pin-Priority: 1000 Then "apt-get install nodejs" will get the right version and all dependencies, no need to build from source.
theboss 13y ago
There was a keybase security vulnerability reported last week as well. I'm not sure if it is 100% relevant because it had nothing to do with js crypto, but it could have allowed someone to impersonate 'liz' as 'iiz' github report: https://github.com/keybase/keybase-issues/issues/397 https://github.com/keybase/keybase-issues/issues/397 blog: http://ejj.io/keybase-io-vulnerability/ http://ejj.io/keybase-io-vulnerability/
riffraff 13y ago
I just signed up on keybase.io. It seems that I can authenticate, get a few people to track me, than revoke my key and upload a new one. I can also, obviously, recover my password via email. And at the end of the process, people who were "tracking" me will still be tracking me. I am not sure this is supposed to happen.
- mey 13y ago
  As long as you don't follow the delete account track, this seems correct. People who track you can choose to be notified by Keybase.io of the change in your key (which is the default option). Additionally, if you can re-prove your identity against the same external identities this makes sense as a way to recover from a compromised key.
kbar13 13y ago
ok, the distro has an outdated version of x software. This is a pretty common issue with older distributions. The great thing about debuntu is that you can pin packages to newer versions! http://packages.ubuntu.com/saucy/nodejs http://packages.ubuntu.com/saucy/nodejs
zobzu 13y ago
This talks much more to me, tho: http://gpg.mozilla.org/pks/lookup?search=0x4E8EA664&op=vindex http://gpg.mozilla.org/pks/lookup?search=0x4E8EA664&op=vinde... And of course, I like that it's distributed and not a business. I don't want people to do business on my identity.
dreamdu5t 13y ago
If I connect to a computer which uses some public key, and I verify that key with keybase.io. I could connect again and the public key could change but still be valid. Ultimately you're trusting keybase.io not to mess with the verification process, correct?
exelius 13y ago
Ok, well, keybase is less than a month old. You are refusing to use bleeding-edge software because it's not supported by your Linux distro. That means you're probably not the target user for what is described on the website as alpha software. Doesn't mean you won't be at some point when they've added functionality and extended the APIs, but for now you don't feel comfortable using it. I think that's a fair stance to take on early-alpha software.
mhandley 13y ago
I don't even get as far as being able to verify myself. When I follow their instructions to upload my public key, I get "Whoa: Error: Unknown public key version: 3". Which doesn't really help me know what's actually wrong.
phelmig 13y ago
Couldn't they create a challenge/response type authentication that proofs that liz has the private key for her public key? Liz wants to authenticate. Keybase sends her a challenge, which she encrypts using her private key. Keybase uses her public key to verify that liz owns the private key for her public PGP key. Easy peasy.
- dfox 13y ago
  Keybase seems to want identity proofs to be independently verifiable, which would not work with challenge/response mechanism.
  - phelmig 13y ago
    Yeah, I know this is somehow the point. On the other hand it (maybe?) would be more useful if they would just verify that certain online-personas (e.g. github, pgp, blog) are the same person, which you could do. I want to know that liz, is the liz that blogs and liz who forks on github, not necessary her facebook/linkedin/real name.
    - SomeoneWeird 13y ago
      This is exactly what Keybase does.
chris123 13y ago
Bitcoin blockchain is looking to take market share for "trust" and "verification" type things. The new web of trust.
uaygsfdbzf 13y ago
I never really looked into Keybase, do you really need to give them your gpg private key? That's something I'd never do...
cyphunk 13y ago
> 'Prerequisites: Node.js' No thanks. Not going to install a slew of node packages all from untrusted sources so that i can "claim" my name in some PGP key DB. Key DB's are not the way to go. Name associations are worse. As someone illustrated by pumping snowden@<somedomain> or glengreenwald@<somedomain> keys into gpg servers. The adverse effect of this names system has a heavier weight than the positive. If people want to improve usability they first should start with authentication. That is, authenticating keys. Second they should develop systems that permit for predictable imperfections in a manner that the user can understand.
- jcrawfordor 13y ago
  Keybase seeks to solve the exact problem you just pointed out by connecting PGP keys to established online identities (Twitter, Github, etc.). You could create a Keybase account for Edward Snowden, sure, but his friends wouldn't trust it when they discover that the Twitter account they know to be his hasn't verified the key. You say that people should start with authentication. That's exactly what keybase is trying to do. Realize that it's a hard problem. How would you implement it?
  - cyphunk 13y ago
    I acknowledge that there is positive to this reputation scheme. It lets Alice ratchet up-trust. But Bob has to be able to somehow confirm the attached accounts. Keybase assumes Bob will check this. 1. It assumes that Malory didn't copy paste all the content of Alice's bitbucket/alice account into an unclaimed github/alice. 2. It assumes a state actor cannot change the content on github, twitter, etc at the moment Bob attempts to validate the associates with Alice's keybase name. 3. Many Bob's will misplace their trust in the names on Keybase just as they do with GPG WoT (Web-of-Trust) systems because Bob doesn't really check the assumptions, caveats and things he should before trusting the key is Alice's. This name/key anchoring will work for casual users of PGP who are not worried about malicious users clever enough to copy+paste enough content to attempt a Sybil attack. It works for people that are probably already in communication with each other for some time. But it should not be used for someone needing to retain anonymity, or anyone worried about state adversaries, or anyone worried about an "advanced persistent" adversary, or in the post-snowden world anyone wanting to communicate with a journalist. It's point #3, how people actually use/abuse WoT's like this, that I feel outweighs the narrow positive scenarios. Keybase might be an improvement on absolutely horrific and broken existing WoT's such as http://pgp.mit.edu http://pgp.mit.edu (I cannot believe this thing is still non-ssl only) and it explores imperfect security, which I am a big fan of. I just think WoT's in general have some other fundamental problems.
rhoml 13y ago
Yet another project that will end up at the bottom of the lake like all other digital identity claiming sites.
maxtaco 13y ago
Install-less, hosted-private-key-less Github, Twitter and Web site verifications are now live on keybase.io. Enjoy!

201 points by achernya 13y ago

So to verify a key I need to install npm? No thanks. " It doesn't seem particularly safe for me to trust my valuable PGP keys to this system." I agree

rsync 13y ago

I've only been glacing here and there, but I keep seeing discussion of uploading ones private key to keybase being an actual mechanism that is supported / encouraged / extant ? Surely not...

opendais 13y ago
https://keybase.io/ https://keybase.io/ "Keybase.io is also a Keybase client, however certain crypto actions (signing and decrypting) are limited to users who store client-encrypted copies of their private keys on the server, an optional feature we didn't mention above. On the website, all crypto is performed in JavaScript, in your browser. Some people have strong feelings about this, for good reason."
rdl 13y ago
The existence of that option is utterly insane IMO. I assumed it was some kind of IQ test for users; if they accept the offer, they get deleted. Sadly, that seems not to be the case.
- maxtaco 13y ago
  We seem to have hit a real nerve here. I ask everyone to question their assumptions just for a moment. If you post a public key, you are letting the world see p*q. Is it insane to let some people see AES_k(p,q) if k is 256 random bytes? If you think yes, then you are making a strong judgment about the relative difficulty of two very different problems in Crypto that are thought to be quite hard. I realize there are issues surrounding coming up with good k's and keeping those k's secret; are these issues at the core of people's objections?
  - lifeisstillgood 13y ago
    As the article pointed out, what if your key (AES_k) is compromised? I mean what is the point of storing `AES_k(p,q) if k is random` unless you keep k somewhere? What do you use that for? I like the idea of a common way of proving one owns certain social identities. It is probably worth pointing out that the level of trust we give varies - Google "trusts" I own the domain when I put their random key on my homepage. Its not the kind of trust we would send (a lot of) money using, but its the level you guys seem to be aiming for - its a good level in a fair society.
    - maxtaco 13y ago
      k is derived from a password in this case, so capture of the password implies capture of k. We give people the option to store their encrypted secret keys on our server to make it easier to manage their key and sync it across their devices.
      - tveita 13y ago
        So when you say "if k is 256 random bytes" it's a flat out lie? e: if k really was 256 random bytes, or bits even, it would mostly be an unnecessary complication. But that's a completely opposite situation from a key derived from a user chosen password.
        maxtaco 13y ago
        It was a thought experiment to encourage people to think about the issue at hand and not dismiss it with a knee-jerk. Your concern is now key stretching and password selection.
        tveita 13y ago
        Well, no, my concern is still to tell people to stay away from Keybase.io, or if they have to use it, to not upload their private key even though it seems to encourage you to, or if they have to upload their key, to use a really strong password and not use the key for anything else. In that order. I think that asking people for their private key is a bad thing that bad sites do. A password derived key isn't random, and no amount of key stretching or pretending will change that.

deleted 13y ago

[deleted]

cortesoft 13y ago
What? Why?
doesnt_know 13y ago
One users "stale" is another's "stable".
lizdenys 13y ago
My machine is going to be upgraded to the next LTS, 14.04, sometime over the summer, but that doesn't change the fact that 12.04 will still be around in 2017. More importantly, 12.04 is the most current Ubuntu LTS. It's definitely still around now.

deleted 13y ago

[deleted]

eik3_de 13y ago

Curious: Why do people choose JavaScript/node.js to write command line apps over traditional languages for that task like python or ruby?

jonny_eh 13y ago
Why do people choose python or ruby to write command line apps over traditional languages like BASH, PERL, and C?
- Crito 13y ago
  The primary argument against node.js (and perhaps ruby) AFAIC is that many users will not already have it installed. Python/Perl/Bash you can count on all users having. C is a fine choice, but of course requires more packaging to be user friendly. I've used zsh as my interactive shell for years, but I always still write bash scripts instead of zsh scripts. You can count on bash scripts running just about anywhere.
- EpicEng 13y ago
  Because they don't know BASH or Perl and writing a Ruby/Python script is more often than not faster and easier than doing the equivalent in C?
- rsync 13y ago
  Exactly - I read: "Why do people choose JavaScript/node.js to write command line apps over traditional languages for that task like python or ruby?" and was agreeing with the first part of the sentence and then laughed out loud at the end ... Are we really in a world where ruby is the old school traditionalist way to write unix utilities ?
  - exelius 13y ago
    I was working with Capistrano almost a decade ago when it was called SwitchTower, so yeah -- it is kind of old school considering most "startup" developers are under 30.
13y ago

shazow 13y ago

I had a similar issue with the verifying process. I opened an issue requesting better documentation on the signing command so that people can write their own clients: https://github.com/keybase/keybase-issues/issues/174 https://github.com/keybase/keybase-issues/issues/174

malgorithms 13y ago
Yeah, thanks for making this issue. (Chris here, one of the two working on Keybase. I commented on that issue recently.) Getting proofs working totally outside our alpha client (and getting them well documented) is something we're working on this week. Keybase will not require running Node at all to interact with it. There will be 2 ways to "prove" yourself as a programmer on Keybase: 1. running `keybase prove github` (or whatever service) which is interactive; the keybase client can generate the nice statement for you and pass it off to GPG for signing. This is already working. 2. running something in your shell which requires nothing but gpg and standard shell commands. The key elements here are that you need to generate a signed statement connecting your two accounts, and you need to post it on github. This is pretty simple and won't require Node at all. Oh, and 3. using some other software of your choice that implements 2. The reason #2 isn't documented yet is that it's a bit more complicated in certain cases. Consider what it takes to perform a twitter proof (click the "show the proof") https://keybase.io/chris/sigs/DZ9rccBD8u-Att6kQzhHHtw-924s7iNt05dB https://keybase.io/chris/sigs/DZ9rccBD8u-Att6kQzhHHtw-924s7i... The signed statement itself isn't hosted on twitter (it won't fit) but needs to be boiled down into an agreeable tweet-sized hash. In order to prove twitter manually, you need to generate this statement, boil it down, make the tweet, and push the statement to Keybase. All this will come, and our goal with Keybase isn't to require Node or npm for anyone.
- 0x006A 13y ago
  Can you document the api calls neede for #2?
  - malgorithms 13y ago
    yes, sorry if that wasn't clear. What I'm saying is that we'll have them documented very shortly. It's a priority for us, which I believe will address the OP's issue. We'll have documentation on: - what needs to be in the signed statement - how to hash the statement for safety on the platform you're posting, if necessary (twitter: yes, github: no, DNS TXT: yes, web domains: no, etc.) - how to tell Keybase about the statement (API call) - how to post the statement on Keybase (API call; this is needed in the scenario where it's hashed, twitter style) These will all be proof specific, which is necessary for reasons you can imagine. Character encodings allowed, where proofs go, what length they can be, etc., what goes into a proof (username?), etc., are all platform specific. But the goal is that someone can do this with software of their choice.

deleted 13y ago

[deleted]

kylec 13y ago
If you don't upload your key to keybase.io, you need the command-line tool to generate the file to upload for you, and then subsequently verify it. She can't install keybase via npm because the version of npm she has with her OS is too old to install it. Therefore, she can't verify.

deleted 13y ago

[deleted]

rdl 13y ago

In reality, the biggest risk for routine comsec with pgp is that no one uses it because it's difficult, but the very specific app of code signing is something where keys need a lot of protection IMO. (I am mostly fine with START TLS for email security 99.99% of the time) The thing which terrifies me is that the npm keybase app asks for my GPG key directly in the same window, and it's impossible for me to (easily) tell when the password prompt is from my GPG binary (which I pretty much trust) vs. the npm binary. I'm using keybase now (rdl), mostly because I trust Chris Coyne personally, and because my key is old. I'm creating a new 4096 RSA key soon, and will be a lot more paranoid about protecting it -- it will only ever exist on read/use only smartcards after initial generation on a secure machine. (sadly, openpgp card doesn't support export and replication, so to be durable, I have to generate it externally and load onto a bunch of cards and then delete the external key; I'm not willing to trust my keys to a single smartcard I carry with me.) Using keybase with gpg agent is maybe a bit safer. I don't really mind being forced to do bad stuff by keybase, due to the risks to them if they're caught, as long as it doesn't expose my keying material. gpg agent plus a hardware smartcard should mostly protect me. The pure-software alternative would be a bunch of text-file messages which I can manually cut and paste and move around between clearly-distinct processes running in separate shells/windows (or machines!). I've been thinking about something a lot better than openpgp card, though, as a secure end-user key management device, with more than just key protections. Unfortunately that means making custom hardware, and that makes little sense in the volumes PGP achieves; maybe if there are other client-side security credentials like ssh or bitcoin, I'd do it.

maxtaco 13y ago
There's one instance in which we prompt for your PGP password directly, since gpg doesn't give us command line access to the needed feature: that's adding the username <you@keybase.io> to your public key if it's not already there. Aside from that, we never need your PGP password and just rely on gpg to prompt for it when needed. If you're seeing other prompts, it could be bug, please let us know!
- rdl 13y ago
  The point is that in a terminal window I have no idea what comes from the keybase binary vs. the gnupg binary it calls out to. You could throw up a convincing looking prompt, steal my passphrase (optionally crashing or passing it on to the real binary to delay suspicion), and then send the key and the passphrase back to your servers. Realistically, I'm not going to validate the keybase binary, npm, etc. every time I update the app. (and even if I am, many users won't). And a "user of interest" could be given a "special" binary pretty easily.

kylec 13y ago

I like the idea of Keybase.io, but I would prefer to use it in a way in which I don't have to trust them at all. As it stands, you need to install their command-line tool and have it directly manage your GPG keychain. For that, I'd prefer to have a platform-neutral tool that's been independently audited and managed by my OS's package manager rather than their keybase-installer tool which seems to want to update very frequently with who-knows-what changes.

oijaf888 13y ago
The changes are all pretty well documented in their git repo.
- kylec 13y ago
  How do I know that the changes keybase-installer is downloading are the same as those in the repo? I'd have to do a lot of legwork every single time I update just to be sure. Better to use a tool I can verify once and use forever, or better yet, not use one at all.
  - maxtaco 13y ago
    Hopefully the pace of changes will slow down once we arrive on the correct core feature set and we sort out the bugs. An earnest thanks to HNers and others for being such great alpha testers BTW.
- deleted 13y ago
  [deleted]
tlrobinson 13y ago
It looks like you can just do this to import a key into GPG: curl https://keybase.io/[them]/key.asc | gpg --import It won't show you the identity proofs though.
- kylec 13y ago
  Interesting, I didn't know that. I still need some way to produce the verification files/tweets for my own account, though, and currently the only way to do that is with the client. (Maybe it works in the browser if you upload your key, I did not do that for the same reason the post author didn't.)

deleted 13y ago

[deleted]

jrochkind1 13y ago

You just have to know that you're placing all your trust in keybase. If keybase says they have verified that `liz` is a certain facebook account, and you are acting based on that in encyrpting something to `liz`, you are trusting that: * keybase acted honestly * nobody compromised keybases software when it was doing the verification * _after_ it did the verification, nobody managed to get keybase to switch out `liz`s key for some other key that wasn't really liz's (either because keybase was compromised, or keybase was untrustworthy... maybe because the government made them be?) That last one is the kicker for me. If keybase catches on, surely they are going to get government orders to swap our one key for another key at some point. The traditional web of trust does not require trusting any of those things, or at least not in those simple forms. On the other hand, yes, there are reasons traditional PGP hasn't caught on, and usability is a big one. But, still, to compromise security for usability... if you go all the way there, you just wind up where we are now, not secure at all, right? So, okay, is there value in going some of the way there, and getting some improved security but not as much as you could, for a more usable experience? Maybe. The danger is that people will think they are getting a lot more security than they are getting, and that situation can be worse than no security at all. One thing Snowden taught us is that if you have to trust a third party to be honest... it's not that the people running keybase aren't honest, it's that the government will _compel_ them to be dishonest if it ever matters to them.

lwf 13y ago
If you trust Twitter/Facebook/Github, you can verify assertions about account ownership by retrieving the signed message from those services and verifying they encode the correct data and that the signatures verify. However, this does not protect against a malicious service provider from modifying the message to replace it with a different user.
davmre 13y ago
It's not correct that you need to trust Keybase. The way that someone verifies their social identity is by posting a tweet (or equivalent) signed with their private key. So you can look up someone's public key on Keybase and then verify that Keybase gave you the correct key, by checking the signature on their original tweet / other social verification posts. Assuming you actually do this level of verification yourself (rather than allowing keybase to do it for you), the only thing you have to trust is that Keybase/Twitter/Github/Facebook/etc aren't all simultaneously colluding to give you a bad key. That seems to me like a reasonable assumption in pretty much all plausible circumstances.

trollingineer 13y ago

Don't worry liz -- you'll always be a whiny little twat to me on Keybase.io.

sp332 13y ago

You can build a newer version from an official Ubuntu source package. Start by adding a line to a file in /etc/apt/apt.conf.d/ that pins all your packages to 12.04, "precise": APT::Default-Release "precise"; Then add a line to your /etc/apt/sources.list to include saucy (or trusty), which has the right version of node. deb http://archive.ubuntu.com/ubuntu saucy main restricted universe deb-src http://archive.ubuntu.com/ubuntu saucy main restricted universe Saucy won't be supported after this year. You can either use Trusty now, or wait for Trusty to be officially released next month and then switch. Next, run these: sudo apt-get update sudo apt-get build-dep -t saucy nodejs sudo apt-get -b source -t saucy nodejs This puts the packages in the current directory. Now just install the one(s) you want: dpkg -i nodejs_0.10.15~dfsg1-4_amd64.deb Edit: wow, I just noticed how many packages that build-dep step pulls in. I hope that doesn't step on anything important :( At that point, you might as well just add a file /etc/apt/preferences.d/01node with these lines: Package: nodejs Pin: release n=saucy Pin-Priority: 1000 Then "apt-get install nodejs" will get the right version and all dependencies, no need to build from source.

theboss 13y ago

There was a keybase security vulnerability reported last week as well. I'm not sure if it is 100% relevant because it had nothing to do with js crypto, but it could have allowed someone to impersonate 'liz' as 'iiz' github report: https://github.com/keybase/keybase-issues/issues/397 https://github.com/keybase/keybase-issues/issues/397 blog: http://ejj.io/keybase-io-vulnerability/ http://ejj.io/keybase-io-vulnerability/

riffraff 13y ago

I just signed up on keybase.io. It seems that I can authenticate, get a few people to track me, than revoke my key and upload a new one. I can also, obviously, recover my password via email. And at the end of the process, people who were "tracking" me will still be tracking me. I am not sure this is supposed to happen.

mey 13y ago
As long as you don't follow the delete account track, this seems correct. People who track you can choose to be notified by Keybase.io of the change in your key (which is the default option). Additionally, if you can re-prove your identity against the same external identities this makes sense as a way to recover from a compromised key.

kbar13 13y ago

ok, the distro has an outdated version of x software. This is a pretty common issue with older distributions. The great thing about debuntu is that you can pin packages to newer versions! http://packages.ubuntu.com/saucy/nodejs http://packages.ubuntu.com/saucy/nodejs

zobzu 13y ago

This talks much more to me, tho: http://gpg.mozilla.org/pks/lookup?search=0x4E8EA664&op=vindex http://gpg.mozilla.org/pks/lookup?search=0x4E8EA664&op=vinde... And of course, I like that it's distributed and not a business. I don't want people to do business on my identity.

dreamdu5t 13y ago

If I connect to a computer which uses some public key, and I verify that key with keybase.io. I could connect again and the public key could change but still be valid. Ultimately you're trusting keybase.io not to mess with the verification process, correct?

exelius 13y ago

Ok, well, keybase is less than a month old. You are refusing to use bleeding-edge software because it's not supported by your Linux distro. That means you're probably not the target user for what is described on the website as alpha software. Doesn't mean you won't be at some point when they've added functionality and extended the APIs, but for now you don't feel comfortable using it. I think that's a fair stance to take on early-alpha software.

mhandley 13y ago

I don't even get as far as being able to verify myself. When I follow their instructions to upload my public key, I get "Whoa: Error: Unknown public key version: 3". Which doesn't really help me know what's actually wrong.

phelmig 13y ago

Couldn't they create a challenge/response type authentication that proofs that liz has the private key for her public key? Liz wants to authenticate. Keybase sends her a challenge, which she encrypts using her private key. Keybase uses her public key to verify that liz owns the private key for her public PGP key. Easy peasy.

dfox 13y ago
Keybase seems to want identity proofs to be independently verifiable, which would not work with challenge/response mechanism.
- phelmig 13y ago
  Yeah, I know this is somehow the point. On the other hand it (maybe?) would be more useful if they would just verify that certain online-personas (e.g. github, pgp, blog) are the same person, which you could do. I want to know that liz, is the liz that blogs and liz who forks on github, not necessary her facebook/linkedin/real name.
  - SomeoneWeird 13y ago
    This is exactly what Keybase does.

chris123 13y ago

Bitcoin blockchain is looking to take market share for "trust" and "verification" type things. The new web of trust.

uaygsfdbzf 13y ago

I never really looked into Keybase, do you really need to give them your gpg private key? That's something I'd never do...

cyphunk 13y ago

> 'Prerequisites: Node.js' No thanks. Not going to install a slew of node packages all from untrusted sources so that i can "claim" my name in some PGP key DB. Key DB's are not the way to go. Name associations are worse. As someone illustrated by pumping snowden@<somedomain> or glengreenwald@<somedomain> keys into gpg servers. The adverse effect of this names system has a heavier weight than the positive. If people want to improve usability they first should start with authentication. That is, authenticating keys. Second they should develop systems that permit for predictable imperfections in a manner that the user can understand.

jcrawfordor 13y ago
Keybase seeks to solve the exact problem you just pointed out by connecting PGP keys to established online identities (Twitter, Github, etc.). You could create a Keybase account for Edward Snowden, sure, but his friends wouldn't trust it when they discover that the Twitter account they know to be his hasn't verified the key. You say that people should start with authentication. That's exactly what keybase is trying to do. Realize that it's a hard problem. How would you implement it?
- cyphunk 13y ago
  I acknowledge that there is positive to this reputation scheme. It lets Alice ratchet up-trust. But Bob has to be able to somehow confirm the attached accounts. Keybase assumes Bob will check this. 1. It assumes that Malory didn't copy paste all the content of Alice's bitbucket/alice account into an unclaimed github/alice. 2. It assumes a state actor cannot change the content on github, twitter, etc at the moment Bob attempts to validate the associates with Alice's keybase name. 3. Many Bob's will misplace their trust in the names on Keybase just as they do with GPG WoT (Web-of-Trust) systems because Bob doesn't really check the assumptions, caveats and things he should before trusting the key is Alice's. This name/key anchoring will work for casual users of PGP who are not worried about malicious users clever enough to copy+paste enough content to attempt a Sybil attack. It works for people that are probably already in communication with each other for some time. But it should not be used for someone needing to retain anonymity, or anyone worried about state adversaries, or anyone worried about an "advanced persistent" adversary, or in the post-snowden world anyone wanting to communicate with a journalist. It's point #3, how people actually use/abuse WoT's like this, that I feel outweighs the narrow positive scenarios. Keybase might be an improvement on absolutely horrific and broken existing WoT's such as http://pgp.mit.edu http://pgp.mit.edu (I cannot believe this thing is still non-ssl only) and it explores imperfect security, which I am a big fan of. I just think WoT's in general have some other fundamental problems.

rhoml 13y ago

Yet another project that will end up at the bottom of the lake like all other digital identity claiming sites.

maxtaco 13y ago

Install-less, hosted-private-key-less Github, Twitter and Web site verifications are now live on keybase.io. Enjoy!