Introducing Bots on Keybase

Hi Human!

Here at Keybase, we manage our own infrastructure via “chatops.” That is, we collaborate in a chat channel where we discuss and perform deployments. Chatops is great because:

1. the discussion and the actions are coordinated
2. it can be done on the road, from a mobile chat interface

Here's a screengrab from my iPhone's Keybase app:

Above we see @amarcedone asking a bot for a server graph. And @joshblum deploying a program.

And then in our desktop app, a celebration of software well done:

Chatops like this might sound or look familiar. But in our case, there's no dangerous man-in-the-middle.

Why this is better than plaintext

Trusting a plaintext-chat as a devops chat manager comes with 3 monster risks:

1. a breach of it. When a script-kiddie, black hat, motorhead, geek, waistoid, or evil nation state finds their way into the chat company's infrastructure, now they are in your devops, too. As a good rule of thumb, you should act as if your chat provider's servers have been broken into.

2. one of your team members WILL choose a weak password. It only takes one to think "Celtics2022" is secure, or to use the same password as they do on other sites.

3. bugs. If your chat provider can read your messages, then they could give them to the wrong person.

Any team software that isn't end-to-end encrypted and authenticated shares these monster risks.

How It Works on Keybase

You can write a bot in a few lines of TypeScript/JavaScript, Go, Python, or a language of your choosing. In just a few lines, that bot can do plenty of things:

• deploy code
• start a build process
• notify the team automatically when something happens, good or bad
• store and share team passwords
• generate throwaway phone numbers
• be an SSH Certificate Authority
• etc.

These cute little bots you write will have their own keys and sigchain—just like a baby human in the Keybase era! In other words, the bot gets end-to-end device and team management for free.

Part 2: Hosted Bots

Besides writing your own, you might wish to use 3^rd party bots. Here's why:

• you won't have to run them yourself
• you won't have to worry about uptime
• you can add them to any chat in a couple clicks

So Keybase has begun a directory of useful community & Keybase-authored bots. They are available from the info-pane in any chat, starting in this week's release:

And here's one in action, a super-simple bot that generates Google Meet links:

Convenient, right? This bot is a "Restricted Bot", which means it can't read what's happening in your chats—only messages directed at it:

This limits it to certain messages, as the next screen shows:

And that's it. You can add Google Meet Bot, Reminderbot, Jirabot, etc., to your teams, in just a couple clicks, and without exposing your normal messages to whoever's hosting the bot.

This is not server trust

Even a hosted bot lacks the keys to read your other messages.

When a team admin invites a bot into a channel, they announce a bot-specific key in the team's sigchain.

Only messages intended for the bot (say, prefixed with !meet) are encrypted for the bot. All other messages aren't encrypted using the key, so the bot can't read them. It can tell those messages are happening, and who is sending them, but it cannot understand them.

You can tell in the app which messages are readable by a bot, because they get this icon on them:

In short, after a couple clicks, it works.

All without letting any 3^rd party read your private messages,

💖 Keybase

---

FAQ

What's your favorite bot on Keybase?

@hellobot. Say hi, and ask for a puzzle.

What's stopping Keybase from injecting a bot I didn't ask for into my team?

Ahhh, evil Keybase Corp. Your team members won't accept anyone into their team—bot or human—unless an admin adds them. Which, as you can imagine, is a cryptographically-signed statement. If it's a restricted bot, the addition statement says so.

Team changes are appended to an auditable, growing chain for the team.

What's wrong with passwords? And doesn't 2FA help?

⚠️ Password+2FA does absolutely nothing to protect against server break-ins or server bugs by your chat provider.

Also, it only requires one person to write their 2fa “backup codes” into gmail or a Google drive. That would be the same person who's bad at picking passwords. So your weakest link may have their passwords and their 2FA broken into, simultaneously.

But again, even if that's not a concern, it doesn't solve the server problems.

How do I write my own bot?

The easiest way is using one of our packages listed above: TypeScript/JavaScript, Go, Python.

If you prefer to write your own from scratch, you can explore Keybase's bot API with commands such as:

keybase chat api --help
keybase team api --help
# etc

If I install multiple bots in one chat, can they read each other's messages?

No, they get independently derived keys, and therefore can't snoop on each other.

Can you be more specific about the bot's keys?

Behind the scenes, the cryptography is exceedingly simple (we like that!). In Keybase, team members share a symmetric per-team key. This is a random 32-byte key that all members of the team can see. They rotate this key whenever anyone in the team revokes a device (and more frequently for exploding messages). Keybase users symmetricly encrypt all data in a chat channel using this key. When a team admin invites a bot into a channel, she derives a bot-specific key from the shared key (via HMAC-based key derivation), and encrypts this derived key for the bot's public key. Simple crypto ensures this derivation in uninvertible, so the bot learns nothing about the underlying key. You can also check out the docs for some more technical details.

All messages to and from the bot are encrypted using this derived key. People in the conversation will only encrypt messages that begin with bot-specific prefixes (like !meet) for the derived key. All human readers can derive this key from the shared team key, and therefore can decrypt the bot's outputs.