Overview
Calls
- •signup
- •getsalt
- •login
- cors•user/lookup
- cors•<user>/pgp_keys.asc
- •key/add
- •key/fetch
- •session/killall
- •sig/next_seqno
- •sig/post
- •sig/post_auth
- cors•merkle/root
- cors•merkle/block
Other details
getsalt
| GET | https://keybase.io/_/api/1.0/getsalt.json | |
| SAMPLE PARAMS | email_or_username: "chris" | |
| SAMPLE OUTPUT | {
  "status": {
    "code": 0,
    "name": "OK"
  },
  "salt": "32355c2e7843513463263...",
  "csrf_token": "lgHZIDAxNzM1NzR...",
  "login_session": "lgHZIDhlY2I0..."
} | |
| WATCH FOR | "BAD_SIGNUP_USERNAME_TAKEN"
"BAD_SIGNUP_EMAIL_TAKEN"
"BAD_SIGNUP_USERNAME_DELETED"
"INPUT_ERROR" | |
Round 1 of the 2-Round Login Protocol
The Keybase login protocol is two rounds, to prevent replay attacks, and to allow strong randomized salting of passwords.
In the first round of the login protocol, the user presents a username or email address to the server, and the server responds with the salt the user uploaded during signup, and a short-lived random challenge. The salt doesn't change for a given user, but the random challege will always be different, and expires after a few minutes.
  The random challege is called login_session. It's not a trully
  random token, but an unforgeable token cryptographically tied to client's
  user ID (or email) and a timestamp.  This construction saves the server from having
  to keep state, but the client can treat the login_session as
  an opaque random token.
  If the user or email address does not exist, getsalt will
  reply with a deterministic salt, a function of the parameters. This is so /getsalt
  can't be used to test for user membership. (An unnecessary
  precaution with usernames, since Keybase is a public directory...)
 
                      