A **key** is the process—basically a ton of math that we won’t get into—that does the encrypting or decrypting.

keybase config set mountdir /media/myfiles/

❯ egrep -r "[a-zA-Z]'[a-zA-Z]" * | grep "\.md" | egrep -v "  #.*?'"
C-guides/01-command-line.md:And if anything about your target has changed since you last followed them, you'll get a meaningful error.
C-guides/01-command-line.md:When you install Keybase for the first time, you'll be asked
C-guides/01-command-line.md:to generate a paper key. It's  a full-powered key, just like a device key.
C-guides/01-command-line.md:If a Keybase user only has a PGP key, or you'd rather encrypt for that:
C-guides/01-command-line.md:# maria, asserting that she's proven her key on both
C-guides/01-command-line.md:# This is unnecessary if we've followed maria, as the command
C-guides/01-command-line.md:Use `keybase help` to learn what's available.
C-guides/01-command-line.md:A team's encrypted files can be found in `/keybase/team`:
C-guides/01-command-line.md:Teams can have chat channels, kind of like Slack.  But unlike Slack, Keybase chats are end-to-end encrypted, and your team's admins cryptographically control who is on the team.
C-guides/01-command-line.md:During this early alpha, team administration is solely done through the command line. If that's ok with you, keep reading.
C-guides/01-command-line.md:# see what teams you're in
C-guides/01-command-line.md:I actually ran the above commands, so now I see the "dingbatz #general" chat channel show up in my UI. Max and crudder do, too, since I added them. We can share files in KBFS, and we can chat. If I add someone else to the team, they'll get access to the files and chat histories, too, as we'll rekey for them.
C-guides/01-command-line.md:keybase chat send --channel '#hr-issues' uber "let's do this"
C-guides/01-command-line.md:We have implemented subteams! For example, if you're the owner of `nike`, you could keep the top team pretty empty and divide your company into `nike.usa` and `nike.marketing` and even deeper teams such as `nike.web.engineering.interns2017`. And if you did a partnership with Apple, you could make `nike.apple_partnership` and put some people who work at Apple into that subteam.
C-guides/01-command-line.md:# assuming you're an admin of nike
C-guides/01-command-line.md:Members of `acme` won't know there's a subteam called `acme.board` unless they're an admin of `acme` or invited into `acme.board`.
C-guides/01-command-line.md:* parent admins have certain admin controls of a subteam, even if they don't join the team. This prevents lost, orphaned subteams. If you're an admin of `acme` and make `acme.interns` without joining it, you won't see its chat or files; even though you have cryptographic keys to the group, the server will refuse to give you the encrypted data unless you explicitly sign yourself into the team, which lets all its members know.
C-guides/01-command-line.md:* subteam members don't need to be parent team members. So `acme.interns` don't need to be members of `acme`.
C-guides/01-command-line.md:* members of a team cannot tell the name or membership of subteams they're not a part of.
C-guides/01-command-line.md:* members of sibling teams cannot see each other's names or memberships. Lowly `nike.interns` can't see `nike.sweatshop`.
C-guides/01-command-line.md:As an outsider, you can't tell who's in a team, so Keybase will reach out to the admins and say you've requested access. They can then add you or ignore the request.
C-guides/01-command-line.md:All that said, there's a protocol to approve by other proven identities:
C-guides/01-command-line.md:2. an admin's client will obey the fellow admin's signed link and perform the action.
C-guides/01-command-line.md:The following is a common desire, so we've made it work:
C-guides/01-command-line.md:Here's what happens when you run this command:
C-guides/01-command-line.md:This is "Trust on First Use" (TOFU) because you're trusting Keybase isn't lying about the email proof...the same kind of TOFU you see when using Signal or WhatsApp to lookup a key by phone number.
C-guides/01-command-line.md:Once wonderwoman is on the team, her identity can't be swapped out. Also, as she adds more devices you won't have to go through TOFU again, unlike when people wipe/install their phones with some chat apps. (That really isn't TOFU, now, is it?)
C-guides/01-command-line.md:Keybase can't abuse this feature to insert extra people on your team. It only works if you start the process off by posting a signed statement that you want it to work, and the admin(s) on your team verify the signed statement, because that statement is checked in step 3. The invitation can be revoked, cryptographically, if you change your mind.
C-guides/01-command-line.md:We'll move this to a table soon. Here's a screenshot of a spreadsheet:
C-guides/01-command-line.md:Any change to a team is signed into a chain, referencing the hash of the last change to the team. This chain itself hangs off a Merkle tree, where it can be found, deterministically. If you'e a member of `acme` you can traverse the tree to the chain. This means you will see the exact same `acme` chain as any other acme user. [We even write the root of our merkle tree to the bitcoin blockchain](https://keybase.io/docs/server_security/merkle_root_in_bitcoin_blockchain).
C-guides/01-command-line.md:This is so you can say or type: "Hey - we're in a team on Keybase called 'lollipops'. Join Keybase and request access." Or "Expect an invitation from the team dunkindonuts...that'll be me." We believe this kind of human discourse without fingerprints or codes is crucial. Just say no to hex strings or 60-digit numbers you're supposed to compare.
C-guides/01-command-line.md:If all your admins lose all their keys, you will permanently lose your team! There's nothing Keybase can do to help, because Keybase can't mess with your team.
C-guides/01-command-line.md:You're among the first testers of Keybase Teams, so there is a small chance we'll screw something up and you'll need to haul your data out and pick a new team name. We hope this doesn't happen. Call it 1% chance of this for July-Sept 2017.
C-guides/01-command-line.md:- you can only make 100 total teams. Don't go squatting names for companies and projects that you know others will want, please.
C-guides/01-command-line.md:**Why can't I rename top-level teams?**
C-guides/01-command-line.md:You can rename subteams, but top-level team renaming is not something we're ready to implement yet. It would require a level of redirection in our Merkle tree and, more important, extensive user experience considerations. So we may never implement it. If you dislike your team name, make a new team and invite everyone.
C-guides/01-command-line.md:**Can people outside my teams know what teams I'm in?**
C-guides/01-command-line.md:**How does this fit into Keybase's business model?**
C-guides/01-command-line.md:We think someday if teams take off, we'll charge for larger teams. Nothing we're offering for free now will flip to a pay model, so if you make a 20 person team now and start using it, you won't someday be faced with a credit card screen to get your files or messages.
C-guides/01-command-line.md:*Please note that the Keybase GUI does not support Tor mode.* If you would like to tunnel the whole application through Tor, we recommend running it inside of a [Tails VM](https://tails.boum.org). Furthermore our Tor support isn't audited, so it's possible that even in strict mode some identifying information might creep in.
C-guides/01-command-line.md:To use the command-line client with Tor, you'll need the Tor SOCKS proxy running locally. See the [Tor project's documentation](https://www.torproject.org/docs/installguide.html.en) for more information on how to set up a local Tor
C-guides/01-command-line.md:If you'd like to use Keybase in Tor mode just for a single session, first run `keybase ctl stop` to shut down the services running in the background, then run `keybase --tor-mode=leaky|strict service`. While this service is running, all `keybase` commands in other terminals will access our servers through the Tor network.
C-guides/01-command-line.md:#### Permanently by changing service's configuration
C-guides/01-command-line.md:And you'll get an output like:
C-guides/01-command-line.md:✔ admin of DNS zone chriscoyne.com, but the result isn't reliable over Tor: found TXT entry keybase-site-verification=2_UwxonS869gxbETQdXrKtIpmV1u8539FmGWLQiKdew
C-guides/01-command-line.md:All network traffic is now protected via Tor, so the server or network eavesdroppers can't discern your IP adddress, but the server can still see your login credentials. This mode of operation is akin to [Tor anonymity mode(3)](https://trac.torproject.org/projects/tor/wiki/doc/TorifyHOWTO#mode3:userwithnoanonymityusingToranyrecipient). It won't protect you from a Keybase server breach, but it will prevent your ISP (or any other nefarious network snoopers) from knowing you use Keybase.
C-guides/01-command-line.md:And you'll get an output like:
C-guides/01-command-line.md:warn: Can't write tracking statement to server in strict Tor mode
C-guides/01-command-line.md:Notice a few new things going on. In the third line of output, there's a warning that the client skipped syncing its local view of your profile with the server's. If it did, someone analyzing traffic on the server could correctly guess that a lookup of Alice directly followed by a lookup of Bob implies that Alice was following or ID'ing Bob. So the lookup of Alice is surpressed. Also note that the client doesn't offer to write a follower statement to the server, which would also divulge the user's identity. Instead, it just settles for writing following information to the local store.
C-guides/01-command-line.md:Some commands won't work at all in strict mode. For instance, if you try to log-in
C-guides/01-command-line.md:You'll get:
C-guides/01-command-line.md:▶ WARNING Failed to load advisory secret store options from remote: We can't send out PII in Tor-Strict mode; but it's needed for this operation
C-guides/01-command-line.md:  <li><strong>Enable Tor "Leaky" Mode</strong>: If you've specifed <em>strict</em> mode
C-guides/01-command-line.md:As part of Tor support, we've also exposed `https://keybase.io` as a hidden address; this is a marginal improvement over standard anonymous Tor browsing, since your traffic need not traverse an exit node.  Our hidden address is:
C-guides/03-linux.md:No matter how you install, you should get updates automatically by running your package manager's update command.
C-guides/03-linux.md:Now that Keybase is running, you'll be able to create an account or log into the GUI. Once logged in, you can make proofs, chat with friends, browse your KBFS files all in the GUI.
C-guides/03-linux.md:The following aren't specific to Linux, but demonstrate many of Keybase's features.
C-guides/03-linux.md:keybase chat send {some-keybase-username} -m "Hey! I'm on Keybase now!" # send an encrypted message
C-guides/03-linux.md:# send a (encrypted) message to a twitter user, *even if they aren't on Keybase
C-guides/03-linux.md:# yet* (they'll get the message when they join)
C-guides/03-linux.md:keybase chat send {some-reddit-username}@reddit -m "Hey! I'm on Keybase now!"
C-guides/03-linux.md:With KBFS running, you'll be able to add files to the magic `/keybase` directory. Everything in this directory is encrypted *on your machine* and synced with all your [devices](https://keybase.io/download). No one else, including Keybase, has access to your files unless you choose to make them public or share them with other users. More information is available at [Understanding KBFS](https://keybase.io/docs/kbfs/understanding_kbfs).
C-guides/03-linux.md:# *even if they haven't joined keybase yet* (they'll get it when they join and
C-guides/03-linux.md:If you're using a package that doesn't provide the keybase redirector, `/keybase` may not exist. In that case, your folder is available at the location given by `keybase config get -b mountdir` ([more on that later](#configuring-kbfs)).
C-guides/03-linux.md:If you're looking for people to talk to, head on over to our [Popular Teams page](https://keybase.io/popular-teams) and request to join a public team from within the GUI (or with `keybase team request-access`). `keybasefriends`, in particular, is a great place to start for general discussion and questions about Keybase. More information on teams is available [here](https://keybase.io/blog/introducing-keybase-teams) and [here](https://keybase.io/blog/new-team-features).
C-guides/03-linux.md:And that's it! There's plenty of more features to play around with in the app and in the command line.
C-guides/03-linux.md:You don't need to go any farther than this if you just want to use Keybase, but the below sections detail advanced topics for users who want to have more knowledge and control over how Keybase runs on their system.
C-guides/03-linux.md:Note that we are not providing package repositories for `.deb` and `.rpm` nightlies (yet): you'll need to manually `dpkg -i` or `rpm -i` to install and update to the next nightly instead of using `apt-get` or `yum`. However, if you're on Arch, you can update by just reinstalling `keybase-git`.
C-guides/03-linux.md:Of course, this won't give you any additional access permissions and some of these features may be server-gated as well, so they may not work correctly or at all.
C-guides/03-linux.md:If you find any bugs or issues with these nightly builds, please [report them](#feedback-and-questions) and we'll do our best to get a fix out soon! Specify `[NIGHTLY]` in the issue title as well.
C-guides/03-linux.md:If you're using a graphical desktop environment like KDE or Gnome, Keybase installs a autostart desktop file into `~/.config/autostart/keybase_autostart.desktop`. If you don't want this behavior, you can disable it in your desktop environment settings, or run
C-guides/03-linux.md:If you're on a headless system, you probably want to use the systemd units instead. If you're using a window manager like i3wm, you can just have it execute `run_keybase` on startup. If you want Keybase to start but don't want the GUI to be maximized, change the command to `run_keybase -a`. You'll be able to open the GUI from the icon in the system tray.
C-guides/03-linux.md:- `keybase-redirector` provides the magic `/keybase` KBFS directory, but isn't required for using KBFS.
C-guides/03-linux.md:your system supports it (Arch, Ubuntu, Debian), but if can't, it falls back
C-guides/03-linux.md:You can see if you're running via systemd with
C-guides/03-linux.md:# (if you don't have that command, you aren't using systemd)
C-guides/03-linux.md:If you don't want to start a background process, you can try
C-guides/03-linux.md:If you're running Keybase on a server, you may want finer-grained control over Keybase than `run_keybase` provides. In this case, you can to configure the systemd units directly without using `run_keybase`.
C-guides/03-linux.md:Among other things, this forwards a few environment variables to the systemd units. If they ever change, you'll need to run this command (or `run_keybase`) again to refresh them. Because systemd units do not automatically forward the user environment, this *cannot* be run automatically in the `ExecStartPre` directive. However, you could choose to have it run on login in a shell profile or rc file. Specifically, this creates a file at `~/.config/keybase/keybase.autogen.env` (or in your `$XDG_CONFIG_HOME`). Environment variables can be overridden by writing to `keybase.env` in the same directory, or by creating a systemctl drop-in configuration with `Environment` directives.
C-guides/03-linux.md:Optionally enable units to autostart on system boot. You can choose a subset of these, but remember that KBFS depends on Keybase (and will start it if it isn't already up).
C-guides/03-linux.md:Optionally allow Keybase to keep running even if you're logged out. If you've SSHed into a server, you can do this so Keybase and KBFS keep working after your session ends.
C-guides/03-linux.md:For this to work, you must have your `$DISPLAY` configured in the environmentfile, which should already be the case if you configured your environmentfile as directed above or executed `run_keybase` in the session. Of course, it won't work in a ssh session unless you've configured X forwarding.
C-guides/03-linux.md:and you'll be able to individually override directives in a [drop-in directory](https://www.freedesktop.org/software/systemd/man/systemd.unit.html). If you run into issues after an upgrade, you may need to merge in changes from the upstream unit file, so only do this as a last resort.
C-guides/03-linux.md:Finally, if you don't want `run_keybase` to use systemd, you can export `KEYBASE_SYSTEMD=0` and it will fall back to starting background processes. It does this automatically if it detects that the systemd user manager is not supported on your system.
C-guides/03-linux.md:Now that you know the basics, let's see how you could run Keybase on a server making a daily backup to KBFS (again, encrypted and automatically synced to all your other Keybase devices, or even a group of users or a team!).
C-guides/03-linux.md:You're done! You can inspect the logs of your timer and check for failures with `journalctl --user`.
C-guides/03-linux.md:We're glad that you're interested in packaging Keybase! There are a lot of moving parts involved, so packaging can get tricky.
C-guides/03-linux.md:Of particular note are `post_install.sh`, and `run_keybase`. You don't have to package these, but you should include the necessary configuration and documentation so users are able to use Keybase.
C-guides/03-linux.md:Let us know if you've created a package and want to be added to the list at the top of this page. In particular, init scripts for SysVinit and OpenRC may be of interest to other package maintainers.
C-guides/03-linux.md:If you believe you've found a security issue or a bug, see our [bug reporting page](https://keybase.io/docs/bug_reporting). Please do a `keybase log send` from the command line when filing a bug report so developers can help you faster.
C-guides/04-pgp-in-javascript.md:*kbpgp* is Keybase's implementation of PGP in JavaScript. It's easy to use, designed for concurrency, and stable in both Node.js and the browser. It's actively maintained and yours forever under a BSD license. This page begins a brief tutorial.
C-guides/04-pgp-in-javascript.md:A KeyManager contains a public key and possibly the secret key and subkeys for a given person. Once you have a KeyManager instance, you can perform actions with the keys inside. For a sign-and-encrypt action, you'll need two KeyManagers: one containing the private key (for the signer), and one containing the public key (for the recipient).
C-guides/04-pgp-in-javascript.md:kbpgp's `box` function performs all the work. Note that it calls back with both a string and a Buffer representation. The Buffer is either a [Node.js Buffer](http://nodejs.org/api/buffer.html) or, a browser-friendly object with similar features.
C-guides/04-pgp-in-javascript.md:Now let's assume instead that we have alice's private key. Recall this includes her public key, so it's all we need.
C-guides/04-pgp-in-javascript.md:The above example ([#2](example-2-a-keymanager-from-a-private-key)) can be performed in two steps. You can create a KeyManager instance with alice's public key, and then add her private key to it afterwards. This will generate an error if her private key does not match her public key.
C-guides/04-pgp-in-javascript.md:At the end of the below process, we'll have a KeyManager instance, alice, which can be used for any crypto action.
C-guides/04-pgp-in-javascript.md:To illustrate a common use case, we'll generate subkeys for both signing and encryption. And, by the way, when kbpgp performs actions with KeyManagers, it automatically picks the appropriate subkey(s).
C-guides/04-pgp-in-javascript.md:    // sign alice's subkeys
C-guides/04-pgp-in-javascript.md:The above parameters are reasonable. If you're happy with them, you can simply call the `KeyManager::generate_rsa` shortcut:
C-guides/04-pgp-in-javascript.md:All kbpgp functions support passing an "ASync Package" (ASP) object, for monitoring. Your ASP can have a progress_hook function, which will get called with info about its progress. This is especially important with RSA key generation, as it can take a little while. If this is in any kind of client app, you'll want to (a) show some indicator that you're doing work, and (b) have a cancel button.
C-guides/04-pgp-in-javascript.md:// oh, heck, let's give up if it takes more than a second
C-guides/04-pgp-in-javascript.md:- `KeyManager.import_from_armored_pgp(opts, cb)`: calls back with `err, key_manager`. If you're importing a private key, you'll want to check if it has a passphrase and unlock it. ([see examples](#loading-a-key))
C-guides/04-pgp-in-javascript.md:- `alice.has_pgp_private()`: returns true if alice's `key_manager` contains a private key
C-guides/04-pgp-in-javascript.md:- `alice.is_pgp_locked()`: returns true if alice's private key is passphrase-protected and locked
C-guides/04-pgp-in-javascript.md:- `alice.unlock_pgp(opts, cb)`: unlocks alice's private key if it's locked; calls back with any error ([see examples](#loading-a-key)); `opts.passphrase`: a string with alice's private key passphrase
C-guides/04-pgp-in-javascript.md:- `alice.merge_pgp_private(opts, cb)`: if alice has been loaded without a private key, this function lets you merge her private key in, after the fact. Once merged, if it is password protected, you'll want to (a) recognize this with `alice.is_pgp_locked()` and then (b) unlock it with `alice.unlock_pgp_key()`; `
C-guides/04-pgp-in-javascript.md:- `alice.export_pgp_public(opts, cb)`: calls back with `err, str`. This generates the standard PGP armored format of alice's public key. ([see example](#generating-a-pair))
C-guides/04-pgp-in-javascript.md:- `alice.export_pgp_private(opts, cb)`: calls back with `err, str`. This generates the standard PGP armored format of alice's key, protected with a passphrase. ([see example](#generating-a-pair)); `opts.passphrase`: a passphrase to protect they key
C-guides/04-pgp-in-javascript.md: The steps to encrypt, sign, or both are all the same in kbpgp. The only difference is what [KeyManagers](#key-manager) you'll need. To sign something, you'll need a KeyManager containing a private key. And to encrypt something, you'll need one containing the public key of the recipient. If your KeyManagers contain subkeys, kbpgp will automatically use the appropriate ones.
C-guides/04-pgp-in-javascript.md:Along the same lines, it's easy to sign a cleartext message. Just provide a `sign_with` KeyManager but leave off the `encrypt_for`.
C-guides/04-pgp-in-javascript.md:Buffers are available in the browser, too, for doing HTML5 things with files. `kbpgp.Buffer` provides a browser-implementation that matches Node.js's.
C-guides/04-pgp-in-javascript.md:// sometime before it's done
C-guides/04-pgp-in-javascript.md:Decrypting and verifying are slightly more complicated than encrypting or signing, because often, you don't know ahead of time which KeyManagers are required. For PGP messages that are signed and encrypted, you only know which verification key is needed after a successful decryption. Also, messages in PGP can be encrypted for multiple receivers, and any given receiver might only have access to one of many possible decryption keys.
C-guides/04-pgp-in-javascript.md: In a more general decryption/verification scenario, you might need to fetch the appropriate decryption and/or verification keys from secondary or remote storage. In this situation, you shouldn't use the KeyRing described above, but should instead provide a custom KeyFetcher.
C-guides/04-pgp-in-javascript.md:*In most of the examples, we've been dealing with string plaintexts and ciphertexts. Of course, sometimes you want to read and write files and convert to interesting strings such as hex or base64.*
C-guides/04-pgp-in-javascript.md:In Node.js we can pass a [Node.js Buffer](http://nodejs.org/api/buffer.html) instead. This could come from a file. Keep in mind this file's buffer and output need to fit easily in memory. (For arbitrarily large files, streams will come soon in kbpgp's future.)
C-guides/04-pgp-in-javascript.md:kbpgp's `burn` function calls back with both a result_string (armored, when encrypting or signing), and a result_buffer (just raw binary data). The latter is either a Node.js Buffer, as discussed above, or, in the browser, a `kbpgp.Buffer`.
C-guides/04-pgp-in-javascript.md:If you want to support file processing in the browser, you can use an HTML5 `FileReader` and convert a file's contents to a Buffer, right in the client side. Depending on the browser, you'll have memory constraints.
C-guides/04-pgp-in-javascript.md:#### There's something missing from this documentation—how do I ______?
C-guides/04-pgp-in-javascript.md:The kbpgp website is brand new, and we're just getting started with the docs. Let us know in the [GitHub issues](https://github.com/keybase/kbpgp/issues).
C-guides/04-pgp-in-javascript.md:Crypto is CPU intensive. The worst offender is RSA key pair generation, when we hunt for big-assed prime numbers. This plus JavaScript's single-threadedness equals a nightmare. Consider this fun thing:
C-guides/04-pgp-in-javascript.md:The above function could take a few seconds in a browser, during which it would be unresponsive - no other JavaScript could run, no buttons or links could be clicked, nothing. It would pause your great life experience. In Node.js, your whole process would lock, and you'd go download Go.
C-guides/04-pgp-in-javascript.md:One solution in the browser is to farm this process off to a web worker. This often works, although web workers are new and somewhat buggy (at the time of this writing, it's not hard to crash Chrome's), and they have very high overhead. On the Node side, you could run a separate process just for performing math operations, and send RPCs to it. (Aside: this is a good idea anyway.)
C-guides/04-pgp-in-javascript.md:Writing code like this - where you call back with an answer - is contagious. If foo calls bar, and bar calls back with an answer, foo can't return that answer. It also must call back.
C-guides/04-pgp-in-javascript.md:#### Why don't you just use OpenPGP.js or Google's End-to-End for Keybase?
C-guides/04-pgp-in-javascript.md:At the time of this writing, Google's End-to-End demands elliptic curve key generation -- and that is not compatible with the most popular PGP implementations. kbpgp can generate and handle both RSA and EC keys, so it's designed to work with the GPG and other PGP implementations.
C-guides/04-pgp-in-javascript.md:As for OpenPGP.js, in late 2013, we looked at OpenPGP.js. Unfortunately, at the time we saw some things we disliked. This has been discussed elsewhere, and Google's team has also commented on it. We have not reviewed OpenPGP.js in its current state.
C-guides/04-pgp-in-javascript.md:These are community projects are using kbpgp. Let us know if you do something cool (email `[email protected]`), and we'll add you. The Keybase team & KBPGP contributors have not audited and are **not responsible** for the projects below.
C-guides/04-pgp-in-javascript.md:We're just getting started with this tutorial and examples. Hit us up [on GitHub](https://github.com/keybase/kbpgp) if anything is missing.
C-guides/02-proof-integration-guide.md:Mastodon has built-in support for Keybase proofs starting with version 2.8.0. If you don't see the instance you're looking for in the Keybase app, contact *[@mlsteele](https://keybase.io/mlsteele)* or email `[email protected]` to have it added to the list.
C-guides/02-proof-integration-guide.md:# This should put them on a page with a form that's got `joans`
C-guides/02-proof-integration-guide.md:# The submit endpoint can be different if you'd like, but for now, I'm just
C-guides/02-proof-integration-guide.md:This is a Python 3 script intended to help you build an integration with Keybase. The idea is, if you've built a complete integration on your side, and lightly edited this script for your specific application, it should pass all the way through.
C-guides/02-proof-integration-guide.md:It takes the path to a [config file](#config), and attempts to make all of the HTTP requests against the site listed in the config. Even if you don't run it, reading the code might help explain how the back and forth works.
C-guides/02-proof-integration-guide.md:# on the `Submit` or `Post` button on your site. It's super specific
C-guides/02-proof-integration-guide.md:# to your implementation, so we'll make a reasonable guess if you
C-guides/02-proof-integration-guide.md:# don't fill this in. But our guess is probably wrong, so just fill
C-guides/02-proof-integration-guide.md:# and so will pass the Keybase check if you're doing it on your side when these
C-guides/02-proof-integration-guide.md:# and here's another existing test user for you to play with (this one on twitter)
C-guides/02-proof-integration-guide.md:"information, please feel free to stop the run, and go hardcode the values we're "
C-guides/02-proof-integration-guide.md:"looking for. They're all right at the top of the file. And if any of the requests "
C-guides/02-proof-integration-guide.md:# We'll plop in our defaults, and if they're still there (please change them above), we'll
C-guides/02-proof-integration-guide.md:# This is super application-specific, so it's very unlikely to be correct.
C-guides/02-proof-integration-guide.md:# But it's hopefully representative enough to get you there without too much effort.
C-guides/02-proof-integration-guide.md:"it's what you expect. There should be a submit button, and the keybase "
C-guides/02-proof-integration-guide.md:# Now that we're done posting the proof, we no longer need the session.
C-guides/02-proof-integration-guide.md:# Let's delete it so we don't use it accidentally below.
C-guides/02-proof-integration-guide.md:# Now that the proof has been posted to your site, we'll check it.
D-docs/12-lockdown/00-index.md:In other words, the user's view of the Keybase Web site when locked down is
D-docs/12-lockdown/00-index.md:mode has no UX inconveniences and won't ask you to go fishing for your phone
D-docs/10-linux/00-index.md:your package manager's update command.
D-docs/10-linux/00-index.md:Now that Keybase is running, you'll be able to create an account or log into
D-docs/10-linux/00-index.md:The following aren't specific to Linux, but demonstrate many of Keybase's
D-docs/10-linux/00-index.md:keybase chat send {some-keybase-username} -m "Hey! I'm on Keybase now!" # send an encrypted message
D-docs/10-linux/00-index.md:# send a (encrypted) message to a twitter user, *even if they aren't on Keybase
D-docs/10-linux/00-index.md:# yet* (they'll get the message when they join)
D-docs/10-linux/00-index.md:keybase chat send {some-reddit-username}@reddit -m "Hey! I'm on Keybase now!"
D-docs/10-linux/00-index.md:With KBFS running, you'll be able to add files to the magic `/keybase`
D-docs/10-linux/00-index.md:# *even if they haven't joined keybase yet* (they'll get it when they join and
D-docs/10-linux/00-index.md:If you're using a package that doesn't provide the keybase redirector, `/keybase`
D-docs/10-linux/00-index.md:If you're looking for people to talk to, head on over to our [Popular Teams
D-docs/10-linux/00-index.md:And that's it! There's plenty of more features to play around with in the app
D-docs/10-linux/00-index.md:You don't need to go any farther than this if you just want to use Keybase, but
D-docs/10-linux/00-index.md:nightlies (yet): you'll need to manually `dpkg -i` or `rpm -i` to install and
D-docs/10-linux/00-index.md:you're on Arch, you can update by just reinstalling `keybase-git`.
D-docs/10-linux/00-index.md:Of course, this won't give you any additional access permissions and some of
D-docs/10-linux/00-index.md:them](#feedback-and-questions) and we'll do our best to get a fix out soon!
D-docs/10-linux/00-index.md:If you're using a graphical desktop environment like KDE or Gnome, Keybase
D-docs/10-linux/00-index.md:`~/.config/autostart/keybase_autostart.desktop`. If you don't want this
D-docs/10-linux/00-index.md:If you're on a headless system, you probably want to use the systemd units
D-docs/10-linux/00-index.md:instead. If you're using a window manager like i3wm, you can just have it
D-docs/10-linux/00-index.md:execute `run_keybase` on startup. If you want Keybase to start but don't want
D-docs/10-linux/00-index.md:the GUI to be maximized, change the command to `run_keybase -a`. You'll be able
D-docs/10-linux/00-index.md:- `keybase-redirector` provides the magic `/keybase` KBFS directory, but isn't
D-docs/10-linux/00-index.md:your system supports it (Arch, Ubuntu, Debian), but if can't, it falls back
D-docs/10-linux/00-index.md:You can see if you're running via systemd with
D-docs/10-linux/00-index.md:# (if you don't have that command, you aren't using systemd)
D-docs/10-linux/00-index.md:If you don't want to start a background process, you can try
D-docs/10-linux/00-index.md:If you're running Keybase on a server, you may want finer-grained control
D-docs/10-linux/00-index.md:units. If they ever change, you'll need to run this command (or `run_keybase`)
D-docs/10-linux/00-index.md:start it if it isn't already up).
D-docs/10-linux/00-index.md:Optionally allow Keybase to keep running even if you're logged out. If you've
D-docs/10-linux/00-index.md:Of course, it won't work in a ssh session unless you've configured X forwarding.
D-docs/10-linux/00-index.md:and you'll be able to individually override directives in a [drop-in
D-docs/10-linux/00-index.md:Finally, if you don't want `run_keybase` to use systemd, you can export
D-docs/10-linux/00-index.md:Now that you know the basics, let's see how you could run Keybase on a server
D-docs/10-linux/00-index.md:You're done! You can inspect the logs of your timer and check for failures with
D-docs/10-linux/00-index.md:We're glad that you're interested in packaging Keybase! There are a lot of
D-docs/10-linux/00-index.md:Of particular note are `post_install.sh`, and `run_keybase`. You don't have to
D-docs/10-linux/00-index.md:Let us know if you've created a package and want to be added to the list
D-docs/10-linux/00-index.md:If you believe you've found a security issue or a bug, see our
D-docs/11-proofs/verify.md:if you've built a complete integration on your side, and lightly edited this script for your
D-docs/11-proofs/verify.md:to make all of the HTTP requests against the site listed in the config. Even if you don't run it, reading
D-docs/11-proofs/verify.md:# on the `Submit` or `Post` button on your site. It's super specific
D-docs/11-proofs/verify.md:# to your implementation, so we'll make a reasonable guess if you
D-docs/11-proofs/verify.md:# don't fill this in. But our guess is probably wrong, so just fill
D-docs/11-proofs/verify.md:# and so will pass the Keybase check if you're doing it on your side when these
D-docs/11-proofs/verify.md:# and here's another existing test user for you to play with (this one on twitter)
D-docs/11-proofs/verify.md:"information, please feel free to stop the run, and go hardcode the values we're "
D-docs/11-proofs/verify.md:"looking for. They're all right at the top of the file. And if any of the requests "
D-docs/11-proofs/verify.md:# We'll plop in our defaults, and if they're still there (please change them above), we'll
D-docs/11-proofs/verify.md:# This is super application-specific, so it's very unlikely to be correct.
D-docs/11-proofs/verify.md:# But it's hopefully representative enough to get you there without too much effort.
D-docs/11-proofs/verify.md:"it's what you expect. There should be a submit button, and the keybase "
D-docs/11-proofs/verify.md:# Now that we're done posting the proof, we no longer need the session.
D-docs/11-proofs/verify.md:# Let's delete it so we don't use it accidentally below.
D-docs/11-proofs/verify.md:# Now that the proof has been posted to your site, we'll check it.
D-docs/11-proofs/index.md:<p>Mastodon has built-in support for Keybase proofs starting with version 2.8.0. If you don't see the instance you're looking for in the Keybase app, contact ****[@mlsteele](https://keybase.io/mlsteele)**** or email [email protected] to have it added to the list.</p>
D-docs/11-proofs/index.md:# This should put them on a page with a form that's got `joans`
D-docs/11-proofs/index.md:# The submit endpoint can be different if you'd like, but for now, I'm just
D-docs/09-bots/00-index.md:1. encrypted for yourself (or for anyone in a team you're in)
D-docs/09-bots/00-index.md:If you're a bot developer who has needed persistent state, you may already be using KBFS for your storage needs. We've implemented the key-value storage feature for more lightweight applications storing small blobs of data - maybe you just need to store a session key, or you're building a team password manager.
D-docs/09-bots/00-index.md:A team has many namespaces, a namespace has many entryKeys, and an entryKey has one current entryValue. You cannot fetch old versions of your data if you've `put` a new revision or deleted it.
D-docs/09-bots/00-index.md:The Keybase server keeps track of the latest revision number for each entry, and it requires the client to specify the correct revision number on every update request. When you put a new entry or update an existing one (deleting works this way too), your Keybase client will first run a `get` for that entry so it knows exactly what revision the server is expecting (e.g. 1 for a totally new entry). This complexity is hidden from the API because you probably don't need it. If, however, you would like to manage your own revisions (e.g. you have two different bots that absolutely need to share and update the same entries concurrently), you can pass in a revision and your Keybase client will use it.
D-docs/06-wallet/00-index.md:1. A bundle of plaintext data, visible to user and server with information about the stellar accounts in the user's keybase wallet.  Name: **server visible**.
D-docs/06-wallet/00-index.md:1. A global bundle of encrypted data containing secret metadata (i.e. the account name) about all the stellar accounts in the user's keybase wallet.  Name: **user private**.
D-docs/06-wallet/00-index.md:The keys used for encryption are symmetric NaCL keys derived from the user's PUK seed and
D-docs/06-wallet/00-index.md:Once you have a Keybase wallet, you can send XLM to any Keybase user even if he or she hasn't established
D-docs/06-wallet/00-index.md:If we detect that the person you are sending to either doesn't have a Stellar account associated with
D-docs/06-wallet/00-index.md:their Keybase account or isn't even on Keybase yet, then we create a temporary holding account where
D-docs/06-wallet/00-index.md:an account merge transaction sends all the funds from `GCYMBZ...` back into the sender's account.
D-docs/04-chat/05-location.md:of this feature requires Keybase to have access to the user's location on the
D-docs/04-chat/04-link-previews.md:   every domain of the URLs the user sends. This way, the user doesn't
D-docs/04-chat/02-ephemeral.md:with the device's long term signing key, and publishes the public half of it
D-docs/04-chat/02-ephemeral.md:ciphertext using these keys is one week. If a device doesn't come online to
D-docs/04-chat/02-ephemeral.md:staleness means that one mothballed device won't compromise the forward secrecy
D-docs/04-chat/02-ephemeral.md:design for managing ephemeral message keys. It's the combination of two
D-docs/04-chat/02-ephemeral.md:mechanisms: hashing keys forward as they're used to provide forward secrecy,
D-docs/04-chat/02-ephemeral.md:quickly as possible for asynchronous senders. There's no week-long window
D-docs/04-chat/02-ephemeral.md:before keys are deleted. Instead, in an active conversation, they're deleted
D-docs/04-chat/02-ephemeral.md:There are two main reasons we aren't using the double ratchet for Keybase's
D-docs/04-chat/02-ephemeral.md:exploding messages. The first is that we're worried about performance in
D-docs/04-chat/02-ephemeral.md:that can amortize that work over many messages, but it's still work that needs
D-docs/04-chat/02-ephemeral.md:- In the "sharing before signup" case, you can chat with someone who hasn't
D-docs/04-chat/02-ephemeral.md:It's conceivable that we could handle all of these cases by adding more
D-docs/04-chat/02-ephemeral.md:Here's the layout of a device EK statement. The corresponding user and team
D-docs/04-chat/02-ephemeral.md:Device EK statements are signed by the device's long term signing key. User EK
D-docs/04-chat/02-ephemeral.md:the user's signature chain. And team EK statements are signed by the current
D-docs/04-chat/02-ephemeral.md:per-team signing key, given in the team's signature chain. Although device
D-docs/04-chat/02-ephemeral.md:copy of the ephemeral secret for every device or team member that isn't stale,
D-docs/04-chat/02-ephemeral.md:clients check the secret's derived Curve25519 public key against the `kid`
D-docs/04-chat/02-ephemeral.md:was used, waiting until there aren't any valid ciphertexts left that might need
D-docs/04-chat/02-ephemeral.md:to be decrypted. That's doable within the key hierarchy with the server's help,
D-docs/04-chat/02-ephemeral.md:but it's impractical when keys are used at the application level. It would also
D-docs/04-chat/02-ephemeral.md:3. "Signing." Sign messages with the sender's long term signing keypair. This
D-docs/04-chat/02-ephemeral.md:The one-MAC approach doesn't provide "sender-specific authentication". That is,
D-docs/04-chat/02-ephemeral.md:are forgeable. Public key signing isn't repudiable. On the other hand, signing
D-docs/04-chat/02-ephemeral.md:message as exploding means the sender doesn't care very much about letting
D-docs/04-chat/02-ephemeral.md:sensitive, and so the sender might care more about repudiability. (We don't
D-docs/04-chat/02-ephemeral.md:sender and each recipient's long term device encryption keys, mixed with a
D-docs/04-chat/02-ephemeral.md:Here's an example message with pairwise MACs, formatted as JSON for
D-docs/04-chat/02-ephemeral.md:    // than the team's long term key decrypt the body.
D-docs/04-chat/02-ephemeral.md:    // section is present, recipients look up the sending device's public
D-docs/04-chat/02-ephemeral.md:    // private key, and the header ciphertext by itself doesn't provide any
D-docs/04-chat/02-ephemeral.md:  // Header metadata is always encrypted with the team's long-term key indicated
D-docs/04-chat/02-ephemeral.md:  // by "keyGeneration" below, even in exploding messages. It's also signed
D-docs/04-chat/02-ephemeral.md:  // recipient must verify that it's the long-term signing key of the sending
D-docs/04-chat/01-crypto.md:  a new encryption key. That guarantees the removed device can't read new
D-docs/04-chat/01-crypto.md:- Alice can send a message to Bob even if he hasn't joined Keybase yet. If she
D-docs/04-chat/01-crypto.md:Even though the server can't forge new messages, there are tricks it might try
D-docs/04-chat/01-crypto.md:to play. For performance reasons, it's the server's responsibility to assign a
D-docs/04-chat/01-crypto.md:messages she's seen before. Bob's device will check that list, to make sure
D-docs/04-chat/01-crypto.md:it's consistent with what he's seeing. That limits the mischief an evil server
D-docs/04-chat/01-crypto.md:That shared context prevents the server from dropping Alice's messages without
D-docs/04-chat/01-crypto.md:her permission, but it's still important that Alice can choose to delete them
D-docs/04-chat/01-crypto.md:Another issue that comes up with large files is that it's helpful to host them
D-docs/04-chat/01-crypto.md:Message encryption is done with NaCl's
D-docs/04-chat/01-crypto.md:In `MessageBoxedV1` header signing is done with NaCl's
D-docs/04-chat/01-crypto.md:- Encrypt the message body with a random 24-byte nonce. We don't need
D-docs/04-chat/01-crypto.md:- `MessageBoxedV2`: SHA-256 hash the encrypted message body's
D-docs/04-chat/01-crypto.md:The fields in the header aren't secret from the server, and it actually needs
D-docs/04-chat/01-crypto.md:the server knows who's talking to whom, because it's delivering all the
D-docs/04-chat/01-crypto.md:messages, it's better that it can't *prove* what it knows.
D-docs/04-chat/01-crypto.md:participants share the encryption key, it wouldn't not enough to distinguish
D-docs/04-chat/01-crypto.md:empty chunk to mark the end and detect truncation. Each chunk's nonce is 16
D-docs/04-chat/01-crypto.md:when they're first provisioned. Those keys live in the user's signature chain,
D-docs/04-chat/01-crypto.md:where they're connected to other other devices' keys by mutual signatures. Each
D-docs/04-chat/01-crypto.md:of a user's identity proofs is also signed by one of these device keys and
D-docs/04-chat/01-crypto.md:A chat symmetric encryption key is 32 random bytes. It's shared by everyone in
D-docs/04-chat/01-crypto.md:the chat, and it's the same key that they use to encrypt files in the private
D-docs/04-chat/01-crypto.md:key, another device that has it will encrypt it with the new device's public
D-docs/04-chat/01-crypto.md:with a key derived from the user's Keybase password. While the user is logged
D-docs/04-chat/01-crypto.md:symmetric key that's derived from the device's `crypto_box` secret key. This is
D-docs/04-chat/01-crypto.md:     the mapping from TLF name to ID isn't totally fixed, since the TLF might
D-docs/04-chat/01-crypto.md:**Tradeoff:** Messages on the server don't have forward secrecy. That is, the
D-docs/04-chat/01-crypto.md:devices on an account. (If you haven't turned on your other phone in 6 months,
D-docs/04-chat/01-crypto.md:and you keep sending messages to it, the ephemeral keys on that phone aren't
D-docs/04-chat/01-crypto.md:very ephemeral anymore.) Finally, deleting keys doesn't help you much if you
D-docs/04-chat/01-crypto.md:encryption keys when you remove a device, so a removed device can't decrypt
D-docs/04-chat/01-crypto.md:**Tradeoff:** Chat messages don't have repudiability. That is, if Alice sends a
D-docs/04-chat/01-crypto.md:message to Bob, it's possible for Bob to prove to other people that Alice sent
D-docs/04-chat/01-crypto.md:and it's even cheaper than signing. But it doesn't scale well to group chats
D-docs/04-chat/01-crypto.md:because old messages can't be reauthenticated until all the senders come
D-docs/04-chat/01-crypto.md:messages, and it's possible for the server to change history in specific ways,
D-docs/04-chat/01-crypto.md:like delaying messages or reordering senders who haven't seen each other's
D-docs/04-chat/01-crypto.md:message references guarantee that the server can't put a message before one it
D-docs/04-chat/01-crypto.md:of metadata. It knows who's talking to whom and how much data they're sending
D-docs/04-chat/01-crypto.md:Decentralized services can also be *easier* to spy on, depending on who's doing
D-docs/04-chat/01-crypto.md:the spying. It's much easier to run a malicious Tor exit node than to break
D-docs/04-chat/01-crypto.md:into Facebook's servers, for example.
D-docs/04-chat/01-crypto.md:than it used to be. It doesn't help much unless an attacker can read arbitrary
D-docs/04-chat/01-crypto.md:files from your disk but can't run arbitrary code. That can happen, but it's a
D-docs/04-chat/01-crypto.md:very specific scenario, and it leaks your decrypted files even if it doesn't
D-docs/04-chat/01-crypto.md:major downside for everyone all the time, especially non-experts who don't know
D-docs/04-chat/01-crypto.md:Keybase's centralized model also makes it easier to recover from leaked signing
D-docs/04-chat/01-crypto.md:account entirely, and you can't publish revocations at all, you can still take
D-docs/04-chat/07-phones-and-emails.md:when users chat, their devices encrypt messages only for the devices they've
D-docs/02-server/04-our-merkle-bitcoin-key.md:We've signed this public key with our <a href="./our-code-signing-key">Code-signing key</a>.
D-docs/02-server/01-stellar.md:Earlier, in [the server security overview](https://keybase.io/docs/server_security) we described Keybase's approach to server security: (1) each user has his or her own signature chain that grows monotonically with each announcement; (2) the server maintains a global Merkle Tree that covers all signature chains; and (3) the server signs and publishes the root of the Merkle Tree with every new user signature. This configuration strongly discourages the server from lying by omission, since clients have the tools to catch the server in the act.
D-docs/02-server/01-stellar.md:There was one point we glossed over. A sophisticated adversary Eve could commandeer our server and fork it, showing Alice and Bob different versions of server state. Eve could get away with her attack as long as she never tries to merge Alice and Bob's views back together, and as long as they don't communicate out-of-band. (See [Mazières and Shasha](http://cs.brown.edu/courses/cs296-2/papers/sundr.pdf) for a formal treatment of fork-consistency).
D-docs/02-server/01-stellar.md:Another way to think of this property is to turn it on its head. Whenever Alice uploads a signed announcement to the Keybase servers, she influences Keybase's Merkle Tree, which in turn influences the Stellar blockchain, which in turn Bob can observe. When Bob observes changes in the Stellar blockchain, he can work backwards to see Alice's change. There's little Eve can do to get in the way without being detected.
D-docs/02-server/01-stellar.md:Yes. Here's how to verify it. We're providing sample [code](https://github.com/keybase/merkle-stellar) in TypeScript. The top level framework is as follows:
D-docs/02-server/01-stellar.md:- `fetchPathAndSigs` - Fetch from Keybase the signatures over the grove that matches the hash we just got from Stellar. Also, include a path from the root of the main tree down to the user's leaf. Note the grove in question might not be the most recent, since Keybase publishes to the Stellar Blockchain only about once an hour, despite updating itself about once a second.
D-docs/02-server/01-stellar.md:- `checkSigAgainstStellar` - Open the signature from the previous call, verify it against Keybase's known signing key, and check that the hash of this signature matches what we got from Stellar.
D-docs/02-server/01-stellar.md:- `fetchSigChain` - The user's leaf gives us the tail of her sigchain. Fetch the whole chain to check it matches the leaf in the tree.
D-docs/02-server/01-stellar.md:You'll get something new, but on Monday 27 Jan 2020 at 11:54 EST, the output was:
D-docs/02-server/01-stellar.md:Now do a lookup on Keybase to find the version of the grove that matches the hash we found in Stellar (recall it might not be the most recent). To save round trips, the server includes specific information about the user we're doing the lookup for, namely a path of hashes from the tree root down to the user's leaf.
D-docs/02-server/01-stellar.md:  // The next 5 lines aren't necessary, since they are already
D-docs/02-server/01-stellar.md:Aha, a match! The check of `expectedHash` versus `gotHash` ensures that the hash of the signature of the root we got from Stellar matches that what Keybase returned to us. Now that the signature matches, we are safe to open it up, to get the root of merkle tree that we'll descend:
D-docs/02-server/01-stellar.md:Now we have the root, we can descend the Merkle tree to get the corresponding user data. The server included the path from the root to the user's leaf in the initial API call to `merkle/path`. We step down it here, ensuring the proper hash inclusion from the layer above. The first such step, recall, was in the signature, which was included in the Stellar blockchain:
D-docs/02-server/01-stellar.md:    // node.type == 2 means that it's a leaf rather than an interior
D-docs/02-server/01-stellar.md:      // The hash of the tail of the user's sigchain is found at
D-docs/02-server/01-stellar.md:      // .[1][1] relative to what's stored in the merkle tree leaf.
D-docs/02-server/00-index.md:We've been working on Keybase.io for a little over half a year now, and we
D-docs/02-server/00-index.md:would like it succeed, but we're a little bit nervous. The more successful we
D-docs/02-server/00-index.md:  1. Server DDOS'ed
D-docs/02-server/00-index.md:We've taken some steps to protect the service from these attacks,
D-docs/02-server/00-index.md:Before we can describe how we protect keybase, we have to describe what it's
D-docs/02-server/00-index.md:   1. **Follower statements**: "I am Joe on Keybase and I just looked at Chris's identity"
D-docs/02-server/00-index.md:   1. **Key ownership**: "I am Joe on Keybase and here's my public key"
D-docs/02-server/00-index.md:signature. Thus, outside observers who want to verify all of Joe's signatures
D-docs/02-server/00-index.md:but now I'm maxtaco there, too, and that I believe the Chris who is
D-docs/02-server/00-index.md:blunt attacker might DDoS Keybase's servers, preventing anyone from accessing
D-docs/02-server/00-index.md:Keybase's data. A more sophisticated attacker might root keybase's server,
D-docs/02-server/00-index.md:all site updates. A client doesn't care where these updates come from, as long
D-docs/02-server/00-index.md:(We're not aware of third-party mirrors *yet*, and our reference client
D-docs/02-server/00-index.md:   1. Selectively rollback a user's signature chain and/or suppress updates
D-docs/02-server/00-index.md:   1. Fake a "key update", and append signatures at the end of a user's chain
D-docs/02-server/00-index.md:chain.  My client prevents a compromised server from changing Alex's key
D-docs/02-server/00-index.md:of Alex's identity and key proofs on other services (like Twitter, GitHub and DNS).
D-docs/02-server/00-index.md:To prevent the server from ["forking"](https://www.usenix.org/legacy/events/osdi04/tech/full_papers/li_j/li_j.pdf?q=untrusted) my view of the site data from Alex's, my client checks
D-docs/02-server/00-index.md:that all signature chains are accurately captured in the site's global
D-docs/02-server/00-index.md:of this tree from the server, and verifies it against the site's
D-docs/02-server/00-index.md:earlier.  My client does the same for Alex's chain.  After all checks succeed,
D-docs/02-server/00-index.md:my client signs my chain, Alex's chain and also Merkle root at the time
D-docs/02-server/00-index.md:A very sophisticated attacker could show my client and Alex's client
D-docs/02-server/00-index.md:They check the site's published Merkle tree root for consistency against
D-docs/02-server/00-index.md:are functioning properly and aren't compromised.  We offer several
D-docs/02-server/00-index.md:to make new clients in different languages if they think we've done a bad job.
D-docs/02-server/00-index.md:of our key.  We keep that private key offline, so that it wouldn't be compromised
D-docs/02-server/00-index.md:We fully understand that users of the Keybase Web client don't get these guarantees.
D-docs/02-server/00-index.md:convince themselves they're seeing a consistent view of the site's state.
D-docs/02-server/00-index.md:And...an update! We're now publishing the merkle root into [the bitcoin block chain](/docs/server_security/merkle_root_in_bitcoin_blockchain).
D-docs/02-server/00-index.md:We call this "follow" around the interface now, but our old word is "track"...so that's what you'll see in your sig chain:
D-docs/02-server/00-index.md:        Hopefully this page can clarify and answer your q's.
D-docs/02-server/00-index.md:        Keybase aims to provide public keys that can be trusted without any backchannel communication. If you need someone's public key,
D-docs/02-server/00-index.md:        you should be able to get it, and know it's the right one, without talking to them in person.
D-docs/02-server/00-index.md:      <p>This is a daunting proposition: servers can be hacked or coerced into lying about a key. So when you run a Keybase client - whether it's our <a href="/docs/cli">reference client</a> or someone else's - that client needs to be highly skeptical about what the server says.
D-docs/02-server/00-index.md:        <li>The server provides maria's info</li>
D-docs/02-server/00-index.md:      <p>Let's go over these three steps.</p>
D-docs/02-server/00-index.md:        Technically speaking, it's a JSON object and there's a little more data in there, but the meat is something like this:
D-docs/02-server/00-index.md:        Keybase has done its own server-side verification of maria, and it won't pass back identities that it hasn't checked.
D-docs/02-server/00-index.md:        Fortunately, the server included a link to maria's tweet. The Keybase client scrapes it.
D-docs/02-server/00-index.md:        All this happens really fast in the client with no inconvenience to you. And it happens for all of maria's identities: her twitter account, her personal website, her github account, etc.
D-docs/02-server/00-index.md:        verified all of them.  Now you can review the usernames it verified, to determine if it's the maria you wanted.
D-docs/02-server/00-index.md:        If it is, the Keybase client encrypts and you're done.
D-docs/02-server/00-index.md:        Ideally, once you're satisfied with maria, you can just do this from any computer:
D-docs/02-server/00-index.md:        But we have a problem: recall, you don't trust the Keybase server.
D-docs/02-server/00-index.md:        So how can you get maria's info when you switch machines, without doing that username review thing again? The answer is following.
D-docs/02-server/00-index.md:        Using your own private key, you can sign a snapshot of her identity. Specifically, you're signing the data from step 1, with some extra info about your own review.
D-docs/02-server/00-index.md:        When you switch computers, the Keybase server can provide you with your own definition of maria, which is signed by you, so it can't be tampered with.
D-docs/02-server/00-index.md:        When Maria is followed by 100 people, and they've all signed identical snapshots to yours, this is helpful.
D-docs/02-server/00-index.md:        This is not a web of trust. You can prove maria's identity, even if there are no other followers. But more followers means more confidence in the age of her account.
D-docs/02-server/00-index.md:        As hinted above, an older follower statement is superior to a new one. It's hard for a hacker to maintain a <i>public</i> compromise of all of maria's accounts over a span of many months. Maria or
D-docs/02-server/00-index.md:        maria's friends would surely notice.
D-docs/02-server/00-index.md:        By comparison, if you started following Maria right now, today could've been the day all her accounts were broken into, simultaneously.
D-docs/02-server/00-index.md:        <b>A gentle conclusion:</b> if you find someone interesting on Keybase - say you know them, or you like to read things they write, or they're a software developer who might sign code - following them now makes sense. This will begin a long and auditable history of following their identity.
D-docs/02-server/00-index.md:    <i>We hope this doc helps. We'll revise it as questions/suggestions arrive in our <a href="https://github.com/keybase/keybase-issues/issues/100">github issue #100 (I don't understand tracking)</a>.</i>
D-docs/02-server/00-index.md:        In the web of trust model, you know you have Maria's key because you trust John, and John signed a statement
D-docs/02-server/00-index.md:        and key fingerprint she reviewed at a party. Your trust of Maria's key is a function of these such connections.
D-docs/02-server/00-index.md:        and it's hard to know what trust level to assign transitively. (Herkimer reports that Carla was drunk; John can't remember, but he was drunk too, and who's Carla again???)
D-docs/02-server/05-merkle-root-in-bitcoin-blockchain.md:Earlier, in [the server security overview](/docs/server_security) we described Keybase's approach
D-docs/02-server/05-merkle-root-in-bitcoin-blockchain.md:tries to merge Alice and Bob's views back together, and as long as they don't
D-docs/02-server/05-merkle-root-in-bitcoin-blockchain.md:a signed announcement to the Keybase servers, she influences Keybase's Merkle Tree, which in turn influences
D-docs/02-server/05-merkle-root-in-bitcoin-blockchain.md:blockchain, he can work backwards to see Alice's change.  There's little Eve can do to
D-docs/02-server/05-merkle-root-in-bitcoin-blockchain.md:Yes.  Here's how to verify it. We're providing sample code for both Python and [IcedCoffeeScript](http://maxtaco.github.io/coffee-script/) - these should work right in your REPL, so go ahead, fire up python or iced,
D-docs/02-server/05-merkle-root-in-bitcoin-blockchain.md:You'll get something new, but on Monday 14 Jul 2014 at 11:33 EST, the output was:
D-docs/02-server/05-merkle-root-in-bitcoin-blockchain.md:signatures under a different key of the `sigs` object, corresponding to that new key's KID.
D-docs/02-server/05-merkle-root-in-bitcoin-blockchain.md:Now that we've verified the hash of this signature was written to the blockchain, we can either verify
D-docs/02-server/05-merkle-root-in-bitcoin-blockchain.md:the signature via `gpg`, or try something quick and dirty to strip out the signature's payload data.  For
D-docs/02-server/05-merkle-root-in-bitcoin-blockchain.md:Now we have the root, we can descend the Merkle tree to get the corresponding user data.  Let's look
D-docs/02-server/05-merkle-root-in-bitcoin-blockchain.md:Next, check that the server wasn't lying about the contents of the block:
D-docs/02-server/05-merkle-root-in-bitcoin-blockchain.md:At this point, we can again check the server isn't lying to us about this block in the Merkle
D-docs/02-server/05-merkle-root-in-bitcoin-blockchain.md:We're almost there! Now let's fetch my whole signature chain, zoom to the last link, check that it
D-docs/02-server/05-merkle-root-in-bitcoin-blockchain.md:In sum, this statement was hashed into my signature chain, which was hashed into Keybase's Merkle
D-docs/02-server/05-merkle-root-in-bitcoin-blockchain.md:tree, which eventually was injected into the Bitcoin blockchain, for all eternity. That's a strong
D-docs/sites/index.md:  If you download something off of Keybase.pub, you're trusting (a) Keybase over https, and (b) that someone hasn't hacked into Keybase.pub. So it's a great site to explore, but if you're downloading something crucial such as a copy of the latest `libssl` or `bitcoind` or `GPG Tools Suite.dmg` from a friend, you should really just look in `/keybase/public` on your own computer. That will verify all the crypto and guarantee you're seeing the same signed bits they are. And it's easier.
D-docs/sites/index.md:  The Keybase.pub website is made by the Keybase team, but it's really a proof of concept. The site isn't privileged. It's kind of dumb - just nginx rewriting some URL's and a basic Node.js website that serves static assets and prints user info.  Keybase.pub demonstrates how easy it is to build things on top of the Keybase filesystem. Other ideas we've heard...feel free to implement:
D-docs/sites/custom.md:under your own domain, with HTTPS certs issued by [Let's
D-docs/sites/custom.md:To delegate traffic handling to Keybase Pages, you'll need to configure your
D-docs/sites/custom.md:A second record is needed to specify the site's root so that Keybase Pages
D-docs/sites/custom.md:Every domain registrar has a different UI for DNS configuration, so it's easy
D-docs/sites/custom.md:Note that this may not show up immediately, since there's generally a few
D-docs/sites/custom.md:an existing record, the existing record's TTL is the upper bound of the
D-docs/sites/auth.md:composed of mainly two parts, a user map for `users` and (bcrypt'ed) password
D-docs/sites/auth.md:`/foo` is also defined, then that's used for `/foo` and everything under it,
D-docs/sites/auth.md:have on the give path. This applies to anonymous traffic that's not
D-docs/sites/auth.md:that authenticated users can get on the given path, in addition to what's in
D-docs/08-crypto/01-key-exchange.md:This document describes Keybase's protocol for using an existing device to
D-docs/08-crypto/01-key-exchange.md:      * The provisionee's new device-specific EdDSA public key
D-docs/08-crypto/01-key-exchange.md:      * The provisionee's new device-specific ephemeral Curve25519 DH public key
D-docs/08-crypto/01-key-exchange.md:      * Data derived from the user's passphrase, used to locally lock secret keys.
D-docs/08-crypto/01-key-exchange.md:      * A signature of the provisionee's new device-specific EdDSA with the provisioner's
D-docs/08-crypto/01-key-exchange.md:        to directly login. The provisionee will need a session to post new signatures to the user's
D-docs/08-crypto/01-key-exchange.md:      * The user's latest [per-user key](/docs/teams/puk) (PUK) seed. These
D-docs/08-crypto/01-key-exchange.md:      * The user's latest [per-user ephemeral key (userEK)
D-docs/08-crypto/01-key-exchange.md:key-exchanges need to be MAC'ed to make sure an adversary who controls the communication channel
D-docs/08-crypto/01-key-exchange.md:isn't MITM-ing the exchange.  Both properties are achieved via authenticated-encryption
D-docs/08-crypto/01-key-exchange.md:Though many device-to-device channels exist, we're going to do the simple and naive thing,
D-docs/08-crypto/01-key-exchange.md:      * the user's latest PUK seed
D-docs/08-crypto/01-key-exchange.md:      * the user's latest userEK seed
D-docs/08-crypto/01-key-exchange.md:      * the user's current passphrase stream (and not an old one that's since been updated.)
D-docs/08-crypto/01-key-exchange.md:    is empty. For V2, we set *T* equal to the user's UID.
D-docs/08-crypto/01-key-exchange.md:NaCl's SecretBox cipher, with the shared secret (either *S<sub>X</sub>*
D-docs/08-crypto/01-key-exchange.md:  send *X* a **Start** RPC to start the protocol. Note we're using an *notify* message here,
D-docs/08-crypto/01-key-exchange.md:       sign itself into the user's sigchain
D-docs/08-crypto/01-key-exchange.md:  **DidCounterSign** RPC.  Device *X* also sends back the user's passphrase
D-docs/08-crypto/01-key-exchange.md:  containing the user's latest per-user key seed NaCl Boxed for the Device
D-docs/08-crypto/01-key-exchange.md:  sent in step 3), the `pukBox`, the `userEKBox` and the device's new
D-docs/08-crypto/01-key-exchange.md:      * Behavior: the (`I`, `sender`, `seqno`) triple must be unique. The server will route the message immediately to the corresponding receiver, or buffer it for about an hour if there's no one receiving yet.
D-docs/08-crypto/01-key-exchange.md:   	 	* `poll` - how long to wait if a message isn't immediately ready, in milliseconds
D-docs/08-crypto/01-key-exchange.md:   	 * Behavior: The server will check for all messages in the session `I` that weren't sent by the given receiver, and whose `seqno` is greater than the one given. It returns all of these messages to the caller.
D-docs/08-crypto/01-key-exchange.md:// Write data to the connection, encrypting and MAC'ing along the way.
D-docs/08-crypto/01-key-exchange.md:Once we have a transport (bounced off the server) that obeys the `net.Conn` interface, it's
D-docs/08-crypto/01-key-exchange.md:It's at the RPC level that the application will handle these exceptions.  In the
D-docs/08-crypto/01-key-exchange.md:first case, a device has sent an RPC but hasn't received a reply, and in
D-docs/08-crypto/01-key-exchange.md:  * passphrase stream — scrypt(N=2<sup>15</sup>, r=8, p=1) of the user's passphrase and a random salt (abbreviated *pps* above)
D-docs/08-crypto/03-kbfs.md:      <li>Say what's in progress on what's implemented.</li>
D-docs/08-crypto/03-kbfs.md:      <li>Last writer isn't encrypted.</li>
D-docs/08-crypto/03-kbfs.md:        <li>Raise Jeremy's objection to MAC-ing TLFs with read-only members.</li>
D-docs/08-crypto/03-kbfs.md:  <strong>Best Effort via Access Control</strong>: If our server infrastructure isn't compromised, we provide only via access control:
D-docs/08-crypto/03-kbfs.md:  In other words, an adversary who has access to Keybase's server data could:
D-docs/08-crypto/03-kbfs.md:  Of course we are mere mortals and don't believe we can indefinitely stave off
D-docs/08-crypto/03-kbfs.md:  <p>Additionally, we don't guarantee availability of data or metadata in the
D-docs/08-crypto/03-kbfs.md:    another device.  Subkeys are signed by an active sibling key but can't
D-docs/08-crypto/03-kbfs.md:   public directories are signed by one of the devices of one of the directory's
D-docs/08-crypto/03-kbfs.md:    responsible for which write, so that users can't put words in each other's mouths.
D-docs/08-crypto/03-kbfs.md:    Keybase keeps public Merkle trees for managing: (1) each user's collection of keypairs
D-docs/08-crypto/03-kbfs.md:    server can't maliciously roll back to previous states.
D-docs/08-crypto/03-kbfs.md:    denoted (\(P_A,p_A\)). But there's nothing special about PGP keys,
D-docs/08-crypto/03-kbfs.md:    Alice's <em>eldest</em> keypair, since it's the first among potentially
D-docs/08-crypto/03-kbfs.md:    For Alice's \(i\)th device, the procedure is:
D-docs/08-crypto/03-kbfs.md:     with NaCL's <a href="http://nacl.cr.yp.to/box.html">Box</a> feature (or Go Crypto's <a href="https://code.google.com/p/go/source/browse/nacl/box/box.go?repo=crypto&r=8fec09c61d5d66f460d227fd1df3473d7e015bc6#60">box.Seal</a> feature). Call
D-docs/08-crypto/03-kbfs.md:    into Alice's signature chain.  See <a href="key-exchange">our doc</a> on key exchange
D-docs/08-crypto/03-kbfs.md:     signature into Alice's signature chain.
D-docs/08-crypto/03-kbfs.md:    Keybase has an idea of a "Key ID".  In the case of PGP keys, it's a hash
D-docs/08-crypto/03-kbfs.md:    of the public key materials.  In the case of ECC keys, it's the public key
D-docs/08-crypto/03-kbfs.md:    it's the most general. Home directories are a simple subcase of general private
D-docs/08-crypto/03-kbfs.md:  Let's say Alice (\(A\)) is creating a new TLF for Bob (\(B\))
D-docs/08-crypto/03-kbfs.md:    <li>Generate a per-TLF Curve25519 DH key pair for inclusion of this folder's
D-docs/08-crypto/03-kbfs.md:        metadata in the site's private-data Merkle tree; call it \((M_f, m_f)\).
D-docs/08-crypto/03-kbfs.md:            That is, run the <a href="http://nacl.cr.yp.to/box.html">NaCl Box</a> function with the ephemeral private key, with the user's public device key,
D-docs/08-crypto/03-kbfs.md:            or replace existing keys, and we'll do so with a new ephemeral keypair.  So
D-docs/08-crypto/03-kbfs.md:        <li>A block of reader keys.  In this case it's just Charlie who is read-only:
D-docs/08-crypto/03-kbfs.md:          A block of writer keys.  In this case it's Alice and Bob:
D-docs/08-crypto/03-kbfs.md:    name, and that readers and writers aren't being dropped maliciously
D-docs/08-crypto/03-kbfs.md:    Readers can change two fields in the folder's metadata: they can push new
D-docs/08-crypto/03-kbfs.md:    keys onto the end of the reader key list; and they can flip the folder's
D-docs/08-crypto/03-kbfs.md:    The idea of some sort of per-block key is one we'll want to keep and
D-docs/08-crypto/03-kbfs.md:    We're not using convergent encryption or anything like it, so a block that's used twice
D-docs/08-crypto/03-kbfs.md:    map hashes of block plaintexts to encrypted block IDs.  So they shouldn't reencrypt/reupload
D-docs/08-crypto/03-kbfs.md:    data is read before it's copied, and many block copies will hit this cache.  We don't
D-docs/08-crypto/03-kbfs.md:    derived from the block's secret key) prevents the server from
D-docs/08-crypto/03-kbfs.md:    but they don't know who.  Alice can try to steal credit for Bob's work, or
D-docs/08-crypto/03-kbfs.md:    statement. If Eve later compromises Charlie's key, she can blackmail
D-docs/08-crypto/03-kbfs.md:    repudiability as in OTR protocols.  However, such schemes didn't work for
D-docs/08-crypto/03-kbfs.md:    just to sign the hash of the root block with the writer's per-device
D-docs/08-crypto/03-kbfs.md:    Unless we're careful, the server can selectively withhold file system updates
D-docs/08-crypto/03-kbfs.md:    Third party monitors are invited to check on the progression of the site's
D-docs/08-crypto/03-kbfs.md:    published in the Merkle trees to make sure the server isn't rolling back
D-docs/08-crypto/03-kbfs.md:    Curve25519 keypair \((M_f, m_f)\). She stores \(M_f\) in the folder's
D-docs/08-crypto/03-kbfs.md:    public metadata, and \(m_f\) in the folder's private metadata.
D-docs/08-crypto/03-kbfs.md:    Every hour, the server makes a new Merkle Tree of the entire site's private data.
D-docs/08-crypto/03-kbfs.md:    When Alice's client goes to fetch TLF \(f\), she gets the most recent
D-docs/08-crypto/03-kbfs.md:  can't assist here, so Alice can only freeze a specific key if she has another provisioned device.
D-docs/08-crypto/03-kbfs.md:  Let's say \(r\) is Alice's lost device, and \(d\) is her currently
D-docs/08-crypto/03-kbfs.md:      <li>Don't bother to reencrypt old blocks, so leave the old decryption materials around
D-docs/08-crypto/03-kbfs.md:    each folder.  It doesn't know which key corresponds to which files, since
D-docs/08-crypto/_account-corner-cases.md:**Important note!** Most of this document isn't yet implemented. We're pretty
D-docs/08-crypto/_account-corner-cases.md:busy over here and haven't completed all aspects of the system. However, the
D-docs/08-crypto/_account-corner-cases.md:    prevent an attacker who just stole a user's phone from deauthorizing
D-docs/08-crypto/_account-corner-cases.md:    the user's other devices.
D-docs/08-crypto/_account-corner-cases.md:    Just `rm`'ing a file does not, since there's still a snapshot of the file.
D-docs/08-crypto/_account-corner-cases.md:passphrase and sets a new one.  Many things about the user's account change,
D-docs/08-crypto/_account-corner-cases.md:like: LKS server-halves; encrypted LKS client halves; and the user's
D-docs/08-crypto/_account-corner-cases.md:server-stored passphrase hash.  However, the account doesn't change into
D-docs/08-crypto/_account-corner-cases.md:passphrase, and aren't in a probationary period.
D-docs/08-crypto/_account-corner-cases.md:in which the Alice recovers Bob's device, and then starts revoking
D-docs/08-crypto/_account-corner-cases.md:(immediately) the Bob's other devices, locking him out of his account.
D-docs/08-crypto/_account-corner-cases.md:Each user should provision a pair of backup keys for their account.  They won't be asked
D-docs/08-crypto/_account-corner-cases.md:crucial that this passphrase has at least 128 bits of true entropy, and therefore shouldn't
D-docs/08-crypto/_account-corner-cases.md:reprove all identities; and re-upload data to KBFS.  It's obviously a case to be
D-docs/08-crypto/_account-corner-cases.md:Users might find themselves in a resettable position if: (1) they've lost all of their
D-docs/08-crypto/_account-corner-cases.md:active devices and (2); don't have backup keys but (3) do remember their
D-docs/08-crypto/_account-corner-cases.md:(2) can prove ownership of an email account (via link-click); and (3) aren't in probation,
D-docs/08-crypto/02-local-key-security.md:We've developed a simple server-aided protocol to do so, in which a server-side
D-docs/08-crypto/02-local-key-security.md:Here's how Alice would encrypt or decrypt on device \\(d\\). Of course
D-docs/08-crypto/02-local-key-security.md:  NaCl's <a href="http://nacl.cr.yp.to/secretbox.html">SecretBox</a>.
D-docs/08-crypto/02-local-key-security.md:\\(k^d_A\\) in the OS's keychain, since those OSes have nice hardware
D-docs/08-crypto/02-local-key-security.md:SSD (which makes it hard to actually delete file blocks), it's still very
D-docs/08-crypto/02-local-key-security.md:One vulnerability of the password change scheme above, is that it's possible to
D-docs/08-crypto/02-local-key-security.md:decrypt secret keys using an old password. If a user's password was
D-docs/08-crypto/02-local-key-security.md:compromised, and an attacker was also able to obtain the user's server-side
D-docs/08-crypto/02-local-key-security.md:mask \\(s^d_A\\), then that attacker would be able to decrypt the user's
D-docs/08-crypto/02-local-key-security.md:be done in a way that's resilient to the device crashing in the middle, so that
D-docs/08-crypto/02-local-key-security.md:there's never a risk that the user could end up in a state where their keys are
D-docs/08-crypto/02-local-key-security.md:server-side mask's passphrase generation corresponds to only one of them. After
D-docs/08-crypto/02-local-key-security.md:Note that a device that's persistently offline (as in, mothballed in your
D-docs/08-crypto/02-local-key-security.md:closet) won't have an opportunity to do a mask reset, and encrypted keys on
D-docs/08-crypto/02-local-key-security.md:device is used again. But it's unavoidable that a disk that hasn't changed in N
D-docs/08-crypto/02-local-key-security.md:years will still be readable with keys from N years ago -- we can't magically
D-docs/08-crypto/02-local-key-security.md:This scheme isn't implemented yet, but here are the changes we will need to
D-docs/08-crypto/02-local-key-security.md:  was originally encrypted with. This will get compared to the user account's
D-docs/08-crypto/02-local-key-security.md:Here's a sketch of what a passphrase update and later mask refresh should look
D-docs/08-crypto/02-local-key-security.md:In the beginning there's one device key and one server-side mask. Note that
D-docs/08-crypto/02-local-key-security.md:we're only seeing the server masks for this specific device key. The same user
D-docs/08-crypto/02-local-key-security.md:keys on one device, but we've implemented it with a unique LKS key for each
D-docs/08-crypto/02-local-key-security.md:adds a new mask to the server, but the device we're looking at here is
D-docs/08-crypto/02-local-key-security.md:unchanged. (There's now a new way to compute the encryption key, but this just
D-docs/08-crypto/02-local-key-security.md:delete old device masks, but the security model here assumes that it can't
D-docs/08-crypto/00-index.md:The Keybase File system (KBFS) is now in active development and will be our first product launch. This [document](/docs/crypto/kbfs) describes the cryptographic decisions in the design.  This document also touches on our plan for organizations, which isn't yet in development.
D-docs/08-crypto/00-index.md:"SaltPack", since it's half [NaCl](http://nacl.cr.yp.to/) and half [message
D-docs/01-cli/00-index.md:And if anything about your target has changed since you last followed them, you'll get a meaningful error.
D-docs/01-cli/00-index.md:When you install Keybase for the first time, you'll be asked
D-docs/01-cli/00-index.md:to generate a paper key. It's  a full-powered key, just like a device key.
D-docs/01-cli/00-index.md:If a Keybase user only has a PGP key, or you'd rather encrypt for that:
D-docs/01-cli/00-index.md:# maria, asserting that she's proven her key on both
D-docs/01-cli/00-index.md:# This is unnecessary if we've followed maria, as the command
D-docs/01-cli/00-index.md:Use `keybase help` to learn what's available.
D-docs/01-cli/00-index.md:If you would like to tunnel the whole application through Tor, we recommend running it inside of a [Tails VM](https://tails.boum.org). Furthermore our Tor support isn't audited, so it's possible that even in strict mode some identifying information might creep in.
D-docs/01-cli/00-index.md:To use the command-line client with Tor, you'll need the Tor SOCKS proxy running locally. See the [Tor project's documentation](https://www.torproject.org/docs/installguide.html.en) for more information on how to set up a local Tor proxy.
D-docs/01-cli/00-index.md:If you'd like to use Keybase in Tor mode just for a single session, first run `keybase ctl stop` to shut down the services running in the background, then run `keybase --tor-mode=leaky|strict service`. While this service is running, all `keybase` commands in other terminals will access our servers through the Tor network.
D-docs/01-cli/00-index.md:#### Permanently by changing service's configuration
D-docs/01-cli/00-index.md:And you'll get an output like:
D-docs/01-cli/00-index.md:✔ admin of DNS zone chriscoyne.com, but the result isn't reliable over Tor: found TXT entry keybase-site-verification=2_UwxonS869gxbETQdXrKtIpmV1u8539FmGWLQiKdew
D-docs/01-cli/00-index.md:All network traffic is now protected via Tor, so the server or network eavesdroppers can't
D-docs/01-cli/00-index.md:discern your IP address, but the server can still see your login credentials. This mode of operation is akin to [Tor anonymity mode(3)](https://trac.torproject.org/projects/tor/wiki/doc/TorifyHOWTO#mode3:userwithnoanonymityusingToranyrecipient).  It won't protect you from a Keybase server breach, but it will prevent your ISP (or any other nefarious network snoopers) from knowing you use Keybase.
D-docs/01-cli/00-index.md:And you'll get an output like:
D-docs/01-cli/00-index.md:warn: Can't write tracking statement to server in strict Tor mode
D-docs/01-cli/00-index.md:Notice a few new things going on. In the third line of output, there's a warning that the client skipped syncing its local view of your profile with the server's. If it did, someone analyzing traffic on the server could correctly guess that a lookup of Alice directly followed by a lookup of Bob implies that Alice was following or ID'ing Bob. So the lookup of Alice is suppressed. Also note that the client doesn't offer to write a follower statement to the server, which would also divulge the user's identity. Instead, it just settles for writing following information to the local store.
D-docs/01-cli/00-index.md:Some commands won't work at all in strict mode. For instance, if you try to log-in afresh:
D-docs/01-cli/00-index.md:You'll get:
D-docs/01-cli/00-index.md:▶ WARNING Failed to load advisory secret store options from remote: We can't send out PII in Tor-Strict mode; but it's needed for this operation
D-docs/01-cli/00-index.md:As part of Tor support, we've also exposed `https://keybase.io` as a hidden address; this is a marginal improvement over standard anonymous Tor browsing, since your traffic need not traverse an exit node.  Our hidden address is:
D-docs/13-client/index.md:separate client process is created and terminated for each command. If there's
D-docs/13-client/index.md:PGP, etc), it's done by the service.
D-docs/13-client/index.md:For iOS and Android, apps can't spawn extra threads, so we'll be using
D-docs/13-client/index.md:standalone mode there. We can't even have an iOS/Android process and
D-docs/13-client/index.md:a separate Go process, so we'll need to embed a Go runtime into the single
D-docs/13-client/index.md:For macOS and Electron desktop GUI clients, we'll use separate processes just
D-docs/13-client/index.md:The service caches the user's passphrase to avoid asking the user for it every
D-docs/13-client/index.md:time a command is run (so if you use `--standalone` you'll have to enter it
D-docs/13-client/index.md:  of the user's Keybase passphrase, cached in the service as
D-docs/13-client/index.md:We try to run crypto operations internally, using Go's `openpgp` module, but
D-docs/13-client/index.md:allows you to see the content of these RPC transactions. (It's "unsafe"
D-docs/13-client/index.md:The reason to use a language-independent protocol is that we're expecting to
D-docs/13-client/index.md:If we wanted to add a new function to the `TrackClient`, we'd add its
D-docs/13-client/index.md:we'd add it to the build-stamp section of [`client/protocol/Makefile`](https://github.com/keybase/client/blob/master/protocol/Makefile)
D-docs/13-client/index.md:Since the service is doing the real work, it's going to be coming up with
D-docs/13-client/pvl.md:Compromising the keybase server and sending bogus PVL could cause clients to accept validations which are not correct. For example, if Eve controlled the keybase server, she could successfully claim Alice's twitter account by posting Eve's own signature of a claim of Alice's username and pushing a change of the PVL for twitter to clients so that they fetch from the wrong user's feed. This is a problem, but is offset by auditing.
D-docs/13-client/pvl.md:If the server does not serve a PVL blob for some (old) `pvl_version` then that causes clients at that version to throw out their existing PVL blob and they will be unable to validate proofs. This means if we find a security bug in proof validation, but can't fix it in that version of the PVL spec, then we can disable those clients immediately.
D-docs/13-client/pvl.md:3. If the PVL is invalid or it doesn't validate against merkle tree, it discards the PVL and aborts. The client is free to try again later.
D-docs/13-client/pvl.md:1. The client finds out from the server the hash of the active PVL blob for its `pvl_version`. In this case it is different or doesn't exist.
D-docs/13-client/pvl.md:    , error: ["BAD_API_URL", "Bad hint from server; didn't recognize API url: \"%{hint_url}\""]} },
D-docs/13-client/pvl.md:    "error": ["BAD_API_URL", "Bad hint from server; didn't recognize API url: \"%{hint_url}\""] } },
D-docs/13-client/pvl.md:DNS is a little special. And will also not change its protocol faster than we can update an app. So here's how it works.
D-docs/13-client/pvl.md:The `hostname` TXT records are fetched. Each DNS script is run against each txt record with the `txt` register set to the record value. If the script succeeds on *any*, then the proof succeeds. If that doesn't work, the process is repeated for `_keybase.proof.domain`.
D-docs/13-client/pvl.md:      , error: ["FAILED_PARSE", "Couldn't find a div $(pre.statement)"] } },
D-docs/13-client/pvl.md:      , error: ["FAILED_PARSE", "Could not find proof markup comment in Facebook's response"] } },
D-docs/13-client/pvl.md:      , error: ["FAILED_PARSE", "Could not find link text in Facebook's response"] } },
D-docs/13-client/pvl.md:      , error: ["FAILED_PARSE", "Couldn't find a div $(div.permalink-tweet-container div.permalink-tweet).eq(0)"] } },
D-docs/13-client/pvl.md:      , error: ["BAD_API_URL", "Bad hint from server; didn't recognize API url: \"%{hint_url}\""]} },
D-docs/05-files/00-index.md:*Every file you write in there is signed.* There's no manual signing process, no `tar`ing or `gzip`ing, no detached sigs. Instead, everything in this folder appears as plaintext files on everyone's computers. You can even open `/keybase/public/yourname<` in your Finder or Explorer and drag things in.
D-docs/05-files/00-index.md:Here's my public folder:
D-docs/05-files/00-index.md:Or maybe you know me another way. In that case you can *assert* I've bi-directionally connected an identity to my keys. These folder names also work:
D-docs/05-files/00-index.md:In my folder you'll find some techie things, such as my SSH public keys, my Signal app fingerprint, and some software I've manually verified and want to distribute safely to friends.
D-docs/05-files/00-index.md:What you put in your folder is up to you: the world will rejoice knowing they're seeing *the exact same bits* you're seeing, without any risk of server-side or man-in-the-middle evil.
D-docs/05-files/00-index.md:When you access a *stranger's* folder (say, [mine](https://keybase.io/chris)),
D-docs/05-files/00-index.md:The popup shows plaintext and plain usernames. Here's the ugly work it hid:
D-docs/05-files/00-index.md:1. requesting that user's info from Keybase (keys + proofs)
D-docs/05-files/00-index.md:1. playing back the user's signed announcements & revocations
D-docs/05-files/00-index.md:### But there's more!
D-docs/05-files/00-index.md:And here's a folder only you and I can read. You don't have to create this folder, it implicitly exists.
D-docs/05-files/00-index.md:*The Keybase servers do not have private keys that can read this data.* Nor can they inject any public keys into this process, to trick you into encrypting for extra parties. Your and my key additions and removals are signed by us into a public merkle tree, which in turn is hashed into the Bitcoin block chain to prevent a forking attack. Here's a screenshot of my 7 device keys and 9 public identities, and how they're all related.
D-docs/05-files/00-index.md:As a reminder, Keybase is [open source Go](https://github.com/keybase/client/tree/master/go/kbfs). And here's [our crypto spec](/docs/kbfs-crypto) on the file mount, which we will gladly change and update as this project evolves. (Feedback desired!)
D-docs/05-files/00-index.md:Soon, you'll be able to throw data into `/keybase/private/yourname,pal@twitter, *even if that Twitter user hasn't joined Keybase yet*. Your app will encrypt *just for you* and then awake and rekey in the background when that Twitter user joins and announces a key.
D-docs/05-files/00-index.md:In contrast, this screenshot was in Keybase's fundraising deck earlier this year:
D-docs/05-files/00-index.md:Our goal: smack-dab in the middle of a public Reddit or HackerNews or Twitter conversation, you *should* be able to say "Hey, I threw those gifs/libraries/whatever in our encrypted keybase folder" without ever asking for more identifying info. If that person hasn't installed Keybase yet, your human work is still done. They can join and access the data within seconds, and your device will quietly handle the verification and rekeying, without ever trusting Keybase's servers.
D-docs/05-files/00-index.md:As discussed in our [blog post about device keys](https://keybase.io/blog/keybase-new-key-model), until our phone app is ready, you'll be asked to make a paper key. This is a full-powered private key. It can be used to provision and even rekey. Carry it in your wallet if you want to provision new Keybase installs. You can make extras with `keybase paperkey` and revoke lost ones with `keybase device [list|remove]`.
D-docs/05-files/00-index.md:![you'll choose `option 2` unless you have two computers side-by-side `option 3` usually won't work (it will for the first computer you set up)](https://keybase.io/images/getting-started/provision.png)
D-docs/05-files/00-index.md:1. what top level folders you're working in (such as `/keybase/private/yourname,pal`),
D-docs/05-files/00-index.md:1. *when* you're writing and reading data, and
D-docs/05-files/00-index.md:The Keybase server *does not know* individual file names or subdirectory names. It could try to guess whether you're writing 100 small files or 1 large file, but it would be a timing-based guess. If you write a 1MB file in a private folder called `/keybase/private/yourname/pics_of_me/thong.jpg`, the Keybase server has no idea this is a folder called `pics_of_me`, or that there's a file called `thong.jpg`, or whether you look good. It doesn't know you're writing pictures, Excel docs, your DNA sequence, or MP3s.
D-docs/05-files/00-index.md:At the time of this document, there are very few people using this system. We're just getting started testing. Note that we could, hypothetically, lose your data at any time. Or push a bug that makes you throw away your private keys. Ugh, burn.
D-docs/05-files/00-index.md:So as one of our first testers: *back up anything you put into Keybase's alpha*, and remember: we can't recover lost encrypted data.
D-docs/05-files/00-index.md:We're giving everyone 250 gigabytes. Our quota model:
D-docs/05-files/00-index.md:- only the writer's quota is affected when writing in shared dirs. Woo-hoo! So you never have to worry about hurting another's quota or disk space (again: friction). Keybase has to work this way, since it doesn't work on the sync model or require approval before encrypting and sharing with someone.
D-docs/05-files/00-index.md:- history data does count towards your quota, and you'll soon have controls for how long to keep deleted blocks around.
D-docs/05-files/00-index.md:There is no paid upgrade currently. The 250GB free accounts will stay free, but we'll likely offer paid storage for people who want to store more data.
D-docs/05-files/00-index.md:We've made no performance optimizations yet. There's a lot of low-hanging fruit.
D-docs/05-files/00-index.md:When the Keybase app offers to install an update, we encourage you to accept it. It'll be signed by us.
D-docs/05-files/00-index.md:I'll add some people above if they're known authors of popular packages or well-known people. Email me if you've got anything interesting ([email protected]).
D-docs/05-files/00-index.md:We're a long way off from worrying about this, but we'll never run an ad-supported business again. And Keybase will never sell data. These are our constraints:
D-docs/05-files/00-index.md:But, as stated above, there is currently no pay model, and we're not trying to make money. We're testing a product right now, and we'd like
D-docs/05-files/01-details.md:depending on the journal configuration (see below).  KBFS doesn't
D-docs/05-files/01-details.md:currently have any optimizations for syncing individual files -- it's
D-docs/05-files/01-details.md:  doesn't affect TLFs that might already be using journaling; you'll
D-docs/05-files/01-details.md:to a particular TLF, this means it's fairly safe to run something like
D-docs/05-files/01-details.md:at the same time, since you're not at risk of repo corruption if the
D-docs/05-files/01-details.md:Our conflict resolution strategy is similar to Dropbox's, but because
D-docs/05-files/01-details.md:we have stronger filesystem semantics than they do, we're able to do
D-docs/05-files/01-details.md:    renames. This is the same way it works in the terminal, if you're
D-docs/05-files/01-details.md:  - If the devices cause a rename cycle, it's resolved with
D-docs/05-files/01-details.md:branched view of a folder, and other devices won't ever see that data.
D-docs/05-files/01-details.md:would require all readers to also be writers. Also, it'd be slow.
D-docs/05-files/01-details.md:Typical POSIX attributes like file owner, group, and permissions don't
D-docs/05-files/01-details.md:any attribute change request that doesn't result in a real change to
D-docs/05-files/01-details.md:ctime for the directory entry.  This is a violation of POSIX, but it's
D-docs/05-files/01-details.md:following a symbolic link - without noticing - by someone you don't
D-docs/05-files/01-details.md:content in someone's `/keybase/public/` folder - with your server
D-docs/05-files/01-details.md:servers can't tell which block belongs to which file or directory
D-docs/05-files/01-details.md:`/keybase/private/you/a/b/c/foo`, you've ended up changing at least
D-docs/05-files/01-details.md:blocks don't count towards your quota.
D-docs/05-files/01-details.md:* `-rev`: This specifies the exact revision number of the TLF you're
D-docs/05-files/01-details.md:  isn't a directory.  It's a file, whose contents contains the
D-docs/05-files/01-details.md:If you're interested in browsing the revisions of a specific file or
D-docs/05-files/01-details.md:recursively.  It does not delete new files that weren't in the old
D-docs/05-files/01-details.md:time.  So it's guaranteed that if you wrote file `a`, and then wrote
D-docs/05-files/01-details.md:see that version of `b`, you'll also the see the same version of `a`
D-docs/05-files/01-details.md:itself) could leave behind new files that didn't exist at the time
D-docs/05-files/01-details.md:directory, one option is to recover via the file system's special
D-docs/05-files/01-details.md:demand, and doesn't store data permanently on your disk by default.
D-docs/05-files/01-details.md:of data (e.g., every Keybase user's public files!), and so syncing all
D-docs/05-files/01-details.md:signed into different Keybase accounts, but that's not a requirement).
D-docs/05-files/01-details.md:Notably, we don't create a `~/keybase` directory, like other file
D-docs/05-files/01-details.md:So, how does the magic `/keybase` path work, if it's not the KBFS
D-docs/05-files/01-details.md:either of which might be unwelcome.  So if you'd rather access KBFS
D-docs/05-files/01-details.md:If you don't like the default mountpoint location, you can override it
D-docs/05-files/01-details.md:might not be desired on systems that don't have any extra RAM or CPU
D-docs/05-files/01-details.md:  this number smaller can help reduce KBFS's memory footprint.
D-docs/05-files/01-details.md:    and may be hard to read by someone who's not a KBFS developer;
D-docs/00-index.md:Every account on Keybase has a public history. "Sigchains" let Keybase clients reconstruct the present without trusting Keybase's servers. And when you "follow" someone on Keybase, you sign a snapshot of your view of the claims in their sigchain.
D-docs/00-index.md:Information about Keybase's encrypted chat product.
D-docs/00-index.md:A description of Keybase's Stellar wallet implementation.
D-docs/00-index.md:Documents describing Keybase's use of cryptography.
D-docs/00-index.md:Keybase's protocol for external services wishing to be added as proof integrators.
D-docs/03-teams/06-crypto.md:and <i>D<sub>i</sub></i> are signed into the team's public sigchain. Whenever a new user is added,
D-docs/03-teams/06-crypto.md:<i>s<sub>i</sub></i> is encrypted for the user's public PUK DH key. This make <i>s<sub>i</sub></i> available on every device for the user. This box is written to the main the DB. The current <i>s<sub>i</sub></i> should have a box for every team member, whether implicit or explicit.
D-docs/03-teams/06-crypto.md:key halves are written into the team's sigchain. Also, whenever the key rolls
D-docs/03-teams/06-crypto.md:<i>c<sub>i+1</sub></i> via NaCl's SecretBox symmetric encryption, just as with
D-docs/03-teams/06-crypto.md:In chat, all messages are encrypted using NaCl's secret box primitive, with the key derived
D-docs/03-teams/06-crypto.md:aren't reencrypted.
D-docs/03-teams/11-ftl.md:server only those team sigchain links that advertise changes in the team's
D-docs/03-teams/11-ftl.md:What's missing in the above process is any checking of signatures made by
D-docs/03-teams/11-ftl.md:server can make a wholesale substitution of a team's sigchain. It can
D-docs/03-teams/11-ftl.md:of the correct admins, since it knows that clients won't bother to check
D-docs/03-teams/11-ftl.md:these signatures. But the server can't perform this swap willy-nilly; it
D-docs/03-teams/11-ftl.md:missing updates, or if users check their current client's view of the Merkle
D-docs/03-teams/11-ftl.md:That is, on even global Merkle sequence numbers, for Alice's benefit, it would
D-docs/03-teams/11-ftl.md:publish version A of *acme*, and on odd sequence numbers, for Bob's benefit,
D-docs/03-teams/11-ftl.md:number of *acme* didn't budge, but the chain tail hash did. However, we
D-docs/03-teams/11-ftl.md:that the first step of loading a team is to request the team's chain team
D-docs/03-teams/11-ftl.md:Then the client requests the rest of the team's chain, whether the
D-docs/03-teams/07-clkr.md:There are 4 important cases in which a Team's keys must be rotated:
D-docs/03-teams/07-clkr.md:a totally different admin. We'll hit both cases below:
D-docs/03-teams/07-clkr.md:When an admin removes a user from a group, he can rotate the team's keys at the same time,
D-docs/03-teams/07-clkr.md:In the other three cases, it doesn't make sense for the user performing the operation
D-docs/03-teams/07-clkr.md:to rotate the team's key, because the user is either no longer in the team, or doesn't
D-docs/03-teams/07-clkr.md:In these circumstances, Keybase's servers orchestrate a key rotation. Keybase
D-docs/03-teams/03-puk.md:/keybase-new-key-model), whose public halves are advertised in the user's
D-docs/03-teams/03-puk.md:Conceptually, the secret half of the per-user key is encrypted for all of a user's
D-docs/03-teams/03-puk.md:active device and paper keys. The public half is advertised in the user's signature
D-docs/03-teams/03-puk.md:public keys *E* and *D* are signed into the user's public sigchain. Whenever a
D-docs/03-teams/03-puk.md:new device is added, *s* is encrypted for the new device's device key. This is
D-docs/03-teams/03-puk.md:previous designs we've consdired and implemented. These NaCl boxes are
D-docs/03-teams/03-puk.md:*c*<sub>*i*+1</sub> via NaCl's [SecretBox](https://nacl.cr.yp.to/secretbox.html) symmetric encryption,
D-docs/03-teams/03-puk.md:The public side of PUKs are written to a user's public sigchain. To demonstrate this
D-docs/03-teams/03-puk.md:for keybase, they have device keys, but they don't have a PUK as
D-docs/03-teams/03-puk.md:described above. New CLI users won't get here, but legacy users and new Web
D-docs/03-teams/08-downgrade-leases.md:simple and general solution, but there's one important corner case to
D-docs/03-teams/08-downgrade-leases.md:an important difference.  Let's look first at step (1), establishing that _a_ <
D-docs/03-teams/08-downgrade-leases.md:roots by accident.  But the clients don't really need to change if they are
D-docs/03-teams/08-downgrade-leases.md:When it comes to guaranteeing that _b_ < _c_, we're not so lucky.   There could have been a race, and this interleaving might be acceptable to the server:
D-docs/03-teams/08-downgrade-leases.md:that we can't use the technique from above for clients to prove that _b_ < _c_
D-docs/03-teams/08-downgrade-leases.md:but can't possibly find a `merkle_path` from <i>t<sub>2</sub></i> down to a sigchain for _b_ that
D-docs/03-teams/08-downgrade-leases.md:contains _b_ since _b_ happens after <i>t<sub>2</sub></i>.  We're stuck!
D-docs/03-teams/08-downgrade-leases.md:any time. So we don't get the nice ordering guarantees.
D-docs/03-teams/08-downgrade-leases.md:Here's the solution called "downgrade leases."  There are two classes of important downgrades: (1) when a user revokes a device; and (2) when a user is removed from a group or downgraded from admin to non-admin.  In both cases, we have to check that _b_ < _c_ but are susceptible to the downgrade race just mentioned. Here's a solution:
D-docs/03-teams/08-downgrade-leases.md:1. All actions that use device B are not valid if there is an outstanding lease for device B's revocation.  So we have to change all signature handlers to not just check if B is still active, but also to check if B isn't slated for imminent revocation.
D-docs/03-teams/08-downgrade-leases.md:1. It's possible for a client to die when holding a lease, so these leases expire after about a minute. The same solution is also employed whenever someone loses adminship privileges from a team, and the analogy holds exactly.
D-docs/03-teams/04-design.md:the team `lets_fire_bob`, the whole world will see it, they just won't be able to get
D-docs/03-teams/04-design.md:are hidden from all who aren't members of the subteam. Thus, if you wanted to create
D-docs/03-teams/04-design.md:As we will see, every team and subteam has its own signature chain that's inserted
D-docs/03-teams/04-design.md:team members can be certain that the Keybase servers aren't equivocating about
D-docs/03-teams/04-design.md:* A **reader** can read the KBFS folders for a team, and he can both read and write a team's chat.
D-docs/03-teams/04-design.md:* A **writer** has all of the permissions of a reader, but can also write to the team's KBFS resources.
D-docs/03-teams/04-design.md:* An **admin** can add or remove admins, readers, and writers to the team, and establish a subteam for the team. An admin can additionally deactivate a team as long as it's not a root team.
D-docs/03-teams/04-design.md:* An implicit admin of a subteam who hasn't been explicitly added to the subteam does not get access to
D-docs/03-teams/04-design.md:* But Keybase can still enforce, for instance, that a sysadmin for Campbell Soup Corp. can't download the C*O team documents.
D-docs/03-teams/04-design.md:(1) the shared key that is encrypted for all user's Per-User Keys; and (2) a
D-docs/03-teams/04-design.md:setup gives the server the ability to break the user's attempt to decrypt
D-docs/03-teams/04-design.md:	<td>root teams (e.g., nike) don't have implicit admins</td>
D-docs/03-teams/04-design.md:	<td>a subteam (e.g., nike.usa) can't have an owner</td>
D-docs/03-teams/05-details.md:team's sigchain unless they have access to the team. For subteams, any observer can see the existence
D-docs/03-teams/05-details.md:of the subteam's ID in the Keybase Merkle tree, and also when it updates, but they will not know the
D-docs/03-teams/05-details.md:observers might be able to guess the team's parent based on corrleated changes
D-docs/03-teams/05-details.md:to leaves in the tree. Though members of the `adidas` teams can't know the
D-docs/03-teams/05-details.md:users to audit the integrity of Keybase's operations.
D-docs/03-teams/05-details.md:Teams live in the Merkle tree alongside of regular users, but they can't collide since user IDs end
D-docs/03-teams/05-details.md:The team section specifies the team's name, the team's ID (determined as above), the initial members of the team, and the initial
D-docs/03-teams/05-details.md:`<uid>%<seqno>`, where `<seqno>` is the earliest sigchain seqno for the user since the user's reset.
D-docs/03-teams/05-details.md:`team.subteam_head` is similar to `team.root`, but represents the first link a subteam's sigchain.
D-docs/03-teams/05-details.md:* `parent` is a pointer to sigchain link in the parent team that authorized this subteam's creation;
D-docs/03-teams/05-details.md:enforces serializability and consistency of the namespace for child teams.  Here's an example
D-docs/03-teams/05-details.md:an admin's permissions come from. And like a `team.root` or
D-docs/03-teams/05-details.md:can add a new user here by just including the user's UID in the appropriate
D-docs/03-teams/05-details.md:should also rotate the team's keys. She can do so by specifying
D-docs/03-teams/05-details.md:`team.rotate_key` specifies that a team's cryptographic shared keys are rotated, but without
D-docs/03-teams/05-details.md:Unlike root teams, subteams can be renamed, but only if their position in the team tree doesn't
D-docs/03-teams/05-details.md:`nike.human_resources.interns`. Here's an example of such a link, which lives in the *parent team*
D-docs/03-teams/05-details.md:Here's an example:
D-docs/03-teams/05-details.md:As with `team.new_subteam` head and `team.subteam_head`, whenever a team's subteam
D-docs/03-teams/05-details.md:the admin has to take Keybase's word for the legitimacy of this proof. Admins who
D-docs/03-teams/05-details.md:don't have open email invitations will never rekey via this server-trusted TOFU
D-docs/03-teams/05-details.md:system, so it's strictly opt-in.
D-docs/03-teams/05-details.md:Here's an example snippet:
D-docs/03-teams/05-details.md:there is this funny notion of a "keybase" invitation. What's happening here is that
D-docs/03-teams/05-details.md:the user `l52701844` is a Keybase user but doesn't a [Per-User Key](puk).  They must
D-docs/03-teams/05-details.md:that we've implented it as a funny sort of invitation.
D-docs/03-teams/05-details.md:* `per_team_key` — The encryption of a new per team key for the team member's PUKs,
D-docs/03-teams/05-details.md: using NaCl's DH primitive
D-docs/03-teams/05-details.md:links in the team's sigchain, and the accompanying encryptions of per-team
D-docs/03-teams/10-seitan.md:/introducing-keybase-teams), and Alice only knows Bob's phone number, she can
D-docs/03-teams/10-seitan.md:trusting that the server doesn't send that token to Charlie instead. So Alice
D-docs/03-teams/10-seitan.md:must trust the server does what it professes, and she doesn't have mechanism to
D-docs/03-teams/10-seitan.md:least ensure that Bob (or Charlie) isn't switched out on her at a later date.
D-docs/03-teams/10-seitan.md:with Bob (via iMessage or Signal, let's say), then she can ensure that Bob is
D-docs/03-teams/10-seitan.md:aren't accidentally sent to the server as team names or email tokens.
D-docs/03-teams/10-seitan.md:be transferred over iMessage or even SMS, so we're slightly space constrained here. Thus, Alice
D-docs/03-teams/10-seitan.md:Whenever Alice wants to invite someone like Bob into a team, and Bob hasn't
D-docs/03-teams/10-seitan.md:invitation. Usually this is done randomly, but in this case, it's
D-docs/03-teams/10-seitan.md:correspond to Bob's iMessage handle or phone number. This way, if she wants to
D-docs/03-teams/10-seitan.md:cancel the invitation later, she'll have a human-readable label to identify it
D-docs/03-teams/10-seitan.md:structure.  To encrypt the `keyAndLabel`, Alice uses the team's secret key,
D-docs/03-teams/10-seitan.md:NaCl's [`crypto_secretbox`](https://nacl.cr.yp.to/secretbox.html). Call this
D-docs/03-teams/10-seitan.md:key `ekey`, for "encrypted key". We encrypt this data so we don't leak the
D-docs/03-teams/10-seitan.md:human-readable label in the sigchain, i.e. Bob's phone number (the  `pubKey` is
D-docs/03-teams/10-seitan.md:#### Step 2c: Sign the pkey into the Team's Chain
D-docs/03-teams/10-seitan.md:generated in the previous step into her team's chain:
D-docs/03-teams/10-seitan.md:of their team's chain, indexing on `iniviteID`. The admins
D-docs/03-teams/10-seitan.md:* That the invite hasn't already been used
D-docs/03-teams/10-seitan.md:* That the invite hasn't expired
D-docs/03-teams/10-seitan.md:* That the invite hasn't been revoked
D-docs/03-teams/10-seitan.md:that system's *TOFU*-based key exchange.
D-docs/03-teams/02-sigchain.md:As we've been building out Keybase, mobile and teams in particular, we've discovered new requirements for the sigchain,
D-docs/03-teams/02-sigchain.md:  * Compression: As is, the sigchain is quite bloated. If you start a conversation with [Chris Coyne](https://keybase.io/chris), you'll have to download his full sigchain, which is ~6MB big (3MB compressed) and growing.  The bulk of it is chris following other users, which is mixed in with his crucial key and device updates.  Each sigchain link is about 6k big right now.  On mobile, this will be especially painful, since you'll have to download a ton of data (potentially over a spotty link) before you can start talking with chris.
D-docs/03-teams/02-sigchain.md:Let's say you had a V1 link of the form:
D-docs/03-teams/02-sigchain.md:You'll note this JSON blob is 2.4k big (after stripping away whitespace).  In sigchain V2, we introduce a new wrapper object:
D-docs/03-teams/02-sigchain.md:  is implied if it's not specified explicitly. The default value for user's chains is `1`, which means `PUBLIC`. The default
D-docs/03-teams/02-sigchain.md:If you run this little program in your node interpreter, you'll get a buffer that's 75 bytes big, a huge savings over the above!
D-docs/03-teams/02-sigchain.md:Now, when a user actually signs a new link into their sigchain, they'll sign the value:
D-docs/03-teams/02-sigchain.md:don't match.
README.md:This repository is a work in progress, and it's our intention for the Keybase Book to be a community project. The target audience is smart people who _aren't necessarily programmers or security folks._
README.md:We'll encourage PR's from the whole community. Help us make this book better.
README.md:We'll accept a PR from anyone, if it clarifies a section. Note that one of the top goals of this project is to make the early chapters of the book readable by non-programmer types. Please don't be overly pedantic; if a cryptographic explanation is good enough, let's not complicate it to cover some technical case most people don't care about.
README.md:## If you're a Keybase staff member
README.md:If you're making subsantial changes, please build the site locally and make sure it all looks good.
api/kid.md:Keybase introduces a new format for public key IDs, inspired by PGP's
api/kid.md:   * **version** — A 1-byte version number, which is set to `0x01` for version 1. If ever we change the representation of anything below, we'll bump to a new version.
api/kid.md:   * **key type** - A 1-byte field describing what type of key we're referring to.  Values `0x00` through `0x1f` are as in the [PGP Spec, RFC 4880, Section 9.1](https://tools.ietf.org/html/rfc4880#section-9.1). Most relevant, we have:
api/lockdown.md:that turns most of the website read-only. It's an extension of Keybase
api/sigs.md:Device-specific keys in Keybase aren't PGP keys, but rather are simple
api/sigs.md:[EdDSA keys](http://ed25519.cr.yp.to/ed25519-20110926.pdf). There's no reason
api/sigs.md:   * **body.hash_type** — Describes which hash function was used to hash the data before it was signed. This field uses the PGP's hash identification scheme from [RFC 4880, Section 9.4](https://tools.ietf.org/html/rfc4880#section-9.4). Only `0x0a` is used so far, meaning SHA-512.
api/02-responses.md:        you'll get a generic <code>"INPUT_ERROR"</code> or <code>"MISSING_PARAMETER"</code>, with a <code>fields</code> dictionary, describing all the errors.
api/02-responses.md:        If the fields are good, but there's a logical error, expect a custom error code. The API documentation
api/ids.md:   * `0x19` — User ID version 2. Since March of 2015, all Keybase UIDs are the first 15 bytes of the SHA-256 hashes of the corresponding username.  There was a bug early on where we didn't call `toLower` on these usernames, that was fixed in May 2015.
api/call/01-signup.md:              It is the client app's responsibility to generate a salt.
api/call/01-signup.md:              passphrase hash.  It's more or less ignored on the server.  The next slice is
api/nist.md:the client doesn't have to wait for a challenge from the server; it can
api/nist.md:made with the user's private device key. The payload of the signature is an
api/nist.md:  "keybase.io", // the host we're authenticating to
api/nist.md:The user's client then generates a signature with the `key` that corresponds to `kid`
api/nist.md:used in other conexts (like signing chats or signing updates to the user's sigchain). The
api/nist.md:Next, we make an abbreviated version of the above signature payload, so that we don't
api/nist.md:`HTTP OK`, then it's safe to use a *short-form* version of a previously-posted long-form NIST,
api/nist.md:string can be specified in a `X-Keybase-Session` header field, where it's synonymous
api/nist.md:with the long-form NIST it's derived from.
api/nist.md:To save some bandwidth, we're only using the first 19 bytes of the SHA256 of the
api/nist.md:enough to be comfortable with. We don't need the full collision-resistence property
api/nist.md:NISTs stay valid until `generated+lifetime`, as computed by the server's clock. If the
api/nist.md:or with a `lifetime` that's too short or long, or with `generated+lifetime` in the past,
api/00-index.md:  Please note we're in alpha and there may be some errors or missing calls in this documentation, and we may change calls without bumping version numbers.
api/00-index.md:  we'll make sure this document aligns better with the client. If you have any questions or notice an error, <a href="https://github.com/keybase/client/issues">visit us on github</a>.
api/00-index.md:  a key on a precise date? Can I sign someone else's key?</em>
api/00-index.md:  <li>there's a bootstrapping problem; if a good PKI existed, more cool software would be built.</li>
api/03-sessions.md:          to be passed to all API's.
api/03-sessions.md:          representation.  This validation will work as long as the <em>auth_token</em> isn't expired
api/03-sessions.md:          or the key that signed it isn't revoked.
api/01-requests.md:You must include a `csrf_token` with all POST requests (except signup). You can send this token either in your post data (as "csrf_token") or in your http headers (as "X-CSRF-Token"). In turn, all requests <i>reply</i> with a csrf token. For example, this is how you'd perform a login. It requires two API calls:
api/01-requests.md:  <li>GET /salt - request a salt for the given user's username (and get a csrf token)</li>