
Keybase launches encrypted Git - aston
https://keybase.io/blog/encrypted-git-for-everyone
======
malgorithms
Keybase team member here. Interesting fact: git doesn't check the validity of
sha-1 hashes in your commit history. Meaning if someone compromises your
hosted origin, they can quietly compromise your history. So even the fears
about data leaks aside, this is a big win for safety.

From an entrepreneurial perspective, this is my favorite thing we've done at
Keybase. It pushes all the buttons: (1) it's relatively simple, (2) it's
filling a void, (3) it's powered by all our existing tech, and (4) it doesn't
complicate our product. What I mean by point 4 is that it adds very little
extra UX and doesn't change any of the rest of the app. If you don't use git,
cool. If you do, it's there for you.

What void does this fill? Previously, I managed some solo repositories of
private data in a closet in my apartment. Who does that? It required a mess:
uptime of a computer, a good link, and dynamic dns. And even then, I never
could break over the hurdle of setting up team repositories with safe
credential management...like for any kind of collaboration. With this simple
screen, you can grab 5 friends, make a repo in a minute, and all start working
on it. With much better data safety than most people can achieve on their own.

~~~
eropple
So I _love_ Keybase unconditionally and if you guys weren't rolling in
physical offices (and not one in Boston) I'd have been beating down your door
to come work there--I think what Keybase is doing is important and it's
something I'd love to work on. But I have a serious question that maybe you
can answer, and it's something everybody who I've showed this to has asked me:

How is Keybase gonna make money? How am I assured that this, and everything
else in my Keybase storage, is going to be there in six months? Like, I
_still_ have a private server in a closet in my apartment that syncs all the
stuff I trust Keybase with because I don't know what the business-side failure
case is.

You guys should be taking my money, is what I'm saying. Also probably hiring
me. But definitely taking my money.

~~~
malgorithms
We believe the right long-term answer for Keybase is finding a way to charge
large corporations and offer pretty much everything else for free. Obviously
there would have to be some paid tier if you really wanted 10TB of storage or
something, but very few people want that right now. We're still just getting
started.

Of course to achieve our goal, we'll also have to find a way to distinguish
communities - which we'll want to use Keybase for free - and companies.

Many of us on the team have come from ad-supported businesses and we really,
really never want to do that again. I personally guarantee I will never be a
"publisher" again. Fortunately that just can't work with Keybase, so no fears
there.

But charging for anything on Keybase right now would be a big mistake. We only
have ~180,000 users, and we want to bring crypto to _everyone_. That basically
means making products we believe are better.

Another way of looking at your concern: I think if we were charging right now,
it wouldn't actually _decrease_ the odds we disappeared in a few years. It
might distract our attention from working on the best product and cause our
bloody demise. So maybe we're not choosing the path that gives you the highest
impression of safety, but I think we actually are.

~~~
QuinnWilton
Everything you just said makes perfect sense.

That being said, I think Keybase is one of the most important companies around
right now. I would gladly pay $10/month, even if literally all it did was put
a "Supporter" badge on my profile. I'm sure hundreds of other people agree.

Crypto is far too important for it to remain locked away behind GPG.

~~~
malgorithms
The outpouring of positive energy (on HN!) is really inspiring. Everyone on
the Keybase team is feeling good about our work right now, so thanks!

~~~
QuinnWilton
The team seriously deserves it.

For what it's worth, I think my above comment is my highest upvoted comment of
all time. There's a lot of people out there who want Keybase to succeed.

~~~
eropple
My comment that started this subthread is in my top ten, and I have been here
entirely too long, so, yeah. Keybase is good. It staying around is important.
People around here, at least, seem to know it, and that's awesome.

------
zeroxfe
I'm really happy about this. I have private repos for personal information
(e.g., tax spreadsheets going back a decade) that I keep synchronized across
machines, and have to jump through hoops to get an encrypted authoritative
remote source. Right now I do that with an encrypted partition on a private
VM.

And, it really sucks that GitHub does not encrypt data at rest:

\--- SNIP from [https://help.github.com/articles/github-
security](https://help.github.com/articles/github-security) \---

We do not encrypt repositories on disk because it would not be any more
secure: the website and git back-end would need to decrypt the repositories on
demand, slowing down response times. Any user with shell access to the file
system would have access to the decryption routine, thus negating any security
it provides. Therefore, we focus on making our machines and network as secure
as possible.

\--- SNIP ---

Encrypted disks are now the norm across various cloud providers, as is HTTPS.
The crypto overheads are really low, and their benefits significantly outweigh
the risks of leaving clear-text data on disks.

Also, defense-in-depth is always worth pursuing. The claim "it would not be
any more secure", is so far from true, it's almost insulting to their target
audience.

Keep killin' it, Keybase! Great job!

~~~
Remed
Out of curiosity: why do you keep such documents in repositories instead of
simply in a filesystem (on an encrypted volume, backed up and possibly synced
across devices)? Tax spreadsheets usually don't change, so there's no need for
version history (if anything, new rows for new years are added, but without
changing past data).

I ask this because I'm trying to figure out a solution for myself for keeping
sensitive personal information and I never thought about storing such
documents in a repository. Maybe I am missing something and your use case will
open my eyes. Thanks!

~~~
Too
For me one big benefit is that it's distributed. I like to keep my important
documents backed up on all the computers i have, on a USB drive stored in a
safe location and also store the data with a cloud provider.

Now, if i update one document on computer A, and another document using
computer B, i have to sync it to all other devices which is a PITA without
git. You get into the situation where you don't know if the version on the USB
drive was newer or older than the one on computer B etc, whereas with git all
this is available in the version tree and there are nice merge tools
available.

I've been planning to do this even for photos, for all the reasons above, but
haven't taken the full step yet.

~~~
dx034
Wouldn't encrypted files with a service like Dropbox help? Containers usually
sync well (only syncs changed parts). Only downside is that you can't access
files without decryption software.

~~~
Too
Dropbox, as all other "just-works" sync services, don't handle merge conflicts
very good. Suddenly you have thousands of Filename_EditedByX(3).txt in every
folder and dont know which one of them is the newest and don't have their most
common ancestor version easily available for a 3-way merge.

~~~
dx034
To be fair, they cannot handle merge conflicts with encrypted containers. I
find that merge conflicts almost always cause more trouble than the work of
avoiding them from the start. As long as you don't share data (with containers
unlikely), merge conflicts should be extremely rare (and anticipated).

------
theptip
Has anyone seen a security audit of the Keybase platform? I love the product
from a usability perspective, but have no idea if it's actually a safe
repository for my team's key material.

------
jack12
This is exciting, but I'm new to Keybase and don't entirely understand it yet.
How can I clone a Keybase-hosted repository on a remote server? Can gpg-agent
proxy through ssh similarly to ssh-agent to allow access to GPG keys (and is
that what keybase uses?), without having to store my keys on the remote
server? Or would I need to create a new Keybase account just for the remote
server, with that account's private keys stored on the server but at least
segregated from my account's full access to communication, team-management,
etc? Or would the best approach be to clone the Keybase-hosted repository
locally and then push it to the remote server over SSH?

~~~
ptspts
Yes, probably you need a new Keybase account just for that remote server if
you want the remote server be able to do git pull after the initial git clone.

If all you need is a single git clone, and you already have a Keybase account,
just do a git clone locally, and use rsync to upload the result to the remote
server.

------
chishaku
In case you're wondering...

> ~ Anticipated q's ~

> What if we're living in a simulation?

> Keybase offers no guarantees against sophisticated side-channel attacks by
> higher-level entities.

~~~
seanlane
It appears that this may no longer be an open question:

[http://www.pbs.org/wgbh/nova/next/physics/physicists-
confirm...](http://www.pbs.org/wgbh/nova/next/physics/physicists-confirm-that-
were-not-living-in-a-computer-simulation/)

There was a Hacker News post about this a few days ago, likely from a
different source, but I can't find it.

~~~
qudat
This only applies to classical computers not quantum, some combination of
both, or by some means of computation we haven't discovered yet.

------
falsedan
Nice to see people work on git remote helpers, a shame that there's already a
fine remote helper that is not tied to a specific hosting provider & uses
GPG[0] already.

0: [https://spwhitton.name/tech/code/git-remote-
gcrypt/](https://spwhitton.name/tech/code/git-remote-gcrypt/)

~~~
zeveb
I came here precisely to see how this compares to git-remote-gcrypt (which I
use to protect my password-safe filenames).

Anyone from keybase prepared to comment?

~~~
ptspts
I'm not a Keybase developer, but I'm a user of Keybase Git, git-remote-gcrypt
and git-gpg, and I've just written a comparison of the 3. Here you are:

[http://ptspts.blogspot.com/2017/10/comparison-of-
encrypted-g...](http://ptspts.blogspot.com/2017/10/comparison-of-encrypted-
git-remote.html)

If I missed some of the aspects, please let me know.

------
RKlophaus
For anyone interested in alternatives, we built a utility (creatively named
git-gpg) with the same goal: end-to-end encrypted git. It works over ssh, is
self-hosted, and requires no additional software on the shared server.

[https://github.com/glassroom/git-gpg](https://github.com/glassroom/git-gpg)

------
ericfrederich
This removes the ability for collaborating, browsing online, basically any
feature of GitLab/GitHub/BitBucket.

... I think I'm in favor of this. I think of the things that those services
provide on top of Git should actually be ported or mapped to Git itself.
Branches, pull requests, comments, etc... should all be Git objects of some
sort.

~~~
quadrangle
Branches are Git objects. Incidentally, here's a distributed VCS that includes
bug tracking: [https://fossil-scm.org](https://fossil-scm.org)

~~~
falsedan
> _Branches are Git objects_

That's not how I understand refs, they don't even live in the .git/objects
hierarchy.

~~~
ericfrederich
You're correct, they're just files. To create a new branch off of master you
can just...

    
    
      cp .git/refs/heads/master .git/refs/heads/WTFFF
    

... no SHA-1 involved at all, no parent, history, etc.

~~~
swsieber
However what they point to are git objects. And being pointed to prevent them
from being garbage collected (pruned).

------
ams6110
_Remember, it is impossible to delete cloud data with any kind of confidence,
and your host may already be compromised._

Should be the epitaph of the current era of computing.

------
notheguyouthink
As an aside, does key base offer tools to encrypt data from code, lets say
from Python/Go/Rust/etc, that is moron proof?

I say tools, because while a library would be cool, I'd understand if it was a
binary/application to provide the functionality/user-experience that key base
is aiming for.

I know this likely doesn't sound like something key base _should_ be aiming
for, but to me, programmers need encryption just as much as users. I'd like to
write my libraries/programs with encryption, but I also want to be able to
trust it and not fear some inherent vulnerability I'm adding.

To me, Keybase is aiming to solve/reduce these complexities for users, and I'm
hoping they also aim to solve it for developers to.

Thanks for all the hard work folks @ Keybase, it's definitely appreciated!

~~~
ofek
This is a perfect use case for
[https://github.com/ofek/privy](https://github.com/ofek/privy)

------
Walkman
I have a private repo on GitHub which contains my dotfiles with SSH private
keys, tokens, secrets and all kinds of secret stuff. I was uncomfortable
storing it there, but my laziness/lack of time kept it there. Finally I will
be able to encrypt the entire repo, yay!!

~~~
philsnow
if you're uncomfortable storing them there, you're going to rotate all the
secrets after you move the repo to keybase, right?

~~~
Walkman
Yes, I will. That's a long overdue also :D

------
OrangeTux
Keybase has quite a few interesting and unique features. But I'm cautious,
because it's not clear to me how they are going to monetize it.

------
NikolaeVarius
My first initial gut thought is, could this be as a good ol cross platform
method of password management? I've never been able to properly manage keepass
due to syncing between different platforms being a pain.

~~~
tehno
Maybe combine Keybase git with gopass, that one stores data in a git repo:

[https://www.justwatch.com/gopass/#features](https://www.justwatch.com/gopass/#features)

~~~
NikolaeVarius
That sounds promising. I can't be the only one with this problem. (aka secure
cross platform synchronized password management without requiring
personal/managing cloud infrastructure.

------
ex3ndr
Was expected one question but haven't found one: how it is actually encrypted?
Any whitepaper or information how diffs could be handled over encrypted data?
Or it is a just encrypted .git folder?

~~~
pfg
Looks like it's built on top of kbfs[1].

[1]:
[https://keybase.io/docs/kbfs/understanding_kbfs](https://keybase.io/docs/kbfs/understanding_kbfs)

~~~
FullyFunctional
The "actually encrypted" part is NaCL (ED25519 + sha256) as supported by Go
[2]. Interestingly, the common way to use NaCL applies Curve25519 to encrypt a
symmetric key which is the used for the payload. They don't do that. AFAICT,
everything is using the ECC curve.

[2] [https://keybase.io/docs/crypto/kbfs](https://keybase.io/docs/crypto/kbfs)

------
kazinator
These benefits can be obtained by sharing a remote encrypted _filesystem_ , in
which sits an ordinary git repo.

Then simply check out that git repo using a _file: //path/to/repo_ reference,
creating a clone on a local drive out of the encrypted volume.

The encrypted filesystem can then reside on an untrusted server in the cloud.

Ultimately, this is a cleaner solution than the whack-a-mole approach of
hacking every application one by one to retrofit it with crypto storage
capabilities.

~~~
timerol
This question has a FAQ entry near the bottom of TFA:

> Why not just make a bare repo in KBFS?

The Keybase filesystem journals changes and syncs them after writes, kind of
like Dropbox. Which means you and another team member could be fighting each
other and make a conflicted HEAD, where there'd be 2 copies side by side.
Similarly, you shouldn't put git repos in Dropbox.

Keybase's git prevents this by locking.

Also: it's nicer to use the Keybase app to discover and manage your teams'
repositories.

------
phren0logy
I really like keybase, and I wish they could issue certs for me to sign PDFs.
I would pay for that.

------
elahd
This is excellent. I've been looking for practical uses for my Keybase account
-- it's been sitting around, verified but idle for years. The chat app is
nice, but none of my friends or co-workers use the service (or understand
crypto, for that matter).

------
FullyFunctional
Let me be unoriginal and sing your praises also. I'd LOVE to replace my use of
Dropbox with Keybase, but I pretty much use every single feature of the iOS
Dropbox App [1] and Keybase really isn't an alternative right now.

Also, one unique design choice of Dropbox is to use the underlying file system
which means that working out of a Dropbox folder is native speed, even for
high intensity IO. Keybase is a lot better than, say, Wuala was, but it's
still noticeable.

[1] In prioritized order: camera uploads, viewing and editing plaintext, show
photos, playing music and video, uploading to Dropbox from random other iOS
apps, and finally selective offline access.

------
ptspts
On Linux, you can try this encrypted Git without installing Keybase or using
the Keybase GUI. You need the following Go binaries from keybase*.deb:
keybase, git-remote-keybase and kbfsfuse.

Start kbfsfuse (specify a directory as a mount point); put get-remote-keybase
to your $PATH; run keybase git create myrepo; you can stop kbfsfuse now; then
this works (after substituting $KEYBASEUSER):

    
    
      git clone keybase://private/$KEYBASEUSER/myrepo

------
ericfrederich
Awesome... any plans to support LFS? I know with LFS you can write custom
backend handlers.

~~~
sridvijay
Was just thinking that as well, the hard part about changing GitHub hosts like
bitbucket/github is the feature parity between them. This is really enticing
though.

------
patrick_haply
Nice, this is perfect timing for me to see this actually. I've been slowly
building out a little cli tool that I use to track .env files (and other files
that you don't want to check into source) in a git repository that is parallel
to your project's git repository.

The way it works is you identify a file that you don't want to check into
source. The cli moves it to a parallel repo, commits the file to the parallel
repo, and symlinks the file back to the original location.

From then on, you get all of the normal source control features like local
changes, revision history, etc... that you get with every other file in your
project. I basically got fed up with "crap what was that value I was using
before? Let me dig through my credentials store" or resorting to commenting
out old lines just in case I needed to revert.

So far, I've just been keeping those parallel repositories local for lack of
an encrypted remote to push to. Definitely checking this out.

------
rcthompson
It's amazing how many new features and even new complete products Keybase has
been able to build on top of their core in such a short span of time. Even
more so considering that a large part of that core is "just" a much better UX
for a technology (GPG) that has existed for decades.

------
AdrianRossouw
The two most interesting companies in crypto for me right now are KeyBase, and
Wire. I kind of wish there was some way for them to interact with each other,
because it feels like they each have a piece of some bigger puzzle.

~~~
choosegoose
Are you not concerned with the data Wire collects?

[https://news.ycombinator.com/item?id=14069674](https://news.ycombinator.com/item?id=14069674)

Versus the data Signal collects:

[https://signal.org/bigbrother/eastern-virginia-grand-
jury/](https://signal.org/bigbrother/eastern-virginia-grand-jury/)

Although I agree Wire looks like a much more (visually) polished chat service,
it seems like they (Wire) collect more data than is necessary.

~~~
AdrianRossouw
Wire has open sourced it's server code (gplv3 even) and is working on
federation support :

[https://medium.com/@wireapp/wire-server-code-now-100-open-
so...](https://medium.com/@wireapp/wire-server-code-now-100-open-source-the-
journey-continues-88e24164309c)

So you can run your own copy of it, and be in complete control of any
information it collects.

~~~
choosegoose
That seems really exciting. When that occurs I will most likely switch over.
Unfortunately you can't quite host it your self yet:
[https://github.com/wireapp/wire-
server/issues/2](https://github.com/wireapp/wire-server/issues/2)

------
payomdousti
is there some way to verify what was actually uploaded, and that it was indeed
encrypted properly?

~~~
ptspts
You can ask the same question about copying the .git directory with rsync over
SSH, and the answer for that one applies to your original qustion as well:

* You can take a look at the packets (using e.g. tcpdump). * You can take a look at what the binaries (rsync, ssh vs. keybase and git-remote-keybase) read and write (using e.g. strace). * You can read the source code. * You can read the white papers and other analyses about the crypto used, and decide if you trust it.

The average user probably won't bother with these, because they need time,
effort and experience.

If you can imagine a fundamentally better possible way for the average user to
verify crypto, please let us know.

------
TomasHubelbauer
This is amazing. I've been aware of KeyBase for some time now, but never
really explored it. This is the push. Typing this comment as I am setting up
my proofs.

------
jboynyc
I made a test repository and proceeded to clone it using the keybase:// uri,
expecting it not to work, but by some dark magic, it just did. Impressive!

~~~
pqs
Not in my case.

$:~/projectes$ git clone keybase:// [uri] Cloning into 'something'... fatal: I
don't handle protocol 'keybase'

I'm on an ubuntu machine. What can I do to solve the problem? Keybase version
1.0.34-20171006000413+5fe91ae13

~~~
jboynyc
Have you installed and are you running the keybase client software? I start it
on my system (Arch Linux) using the run_keybase command.

------
philip1209
Some hypothetical questions:

\- How could CI/CD be set up? (Is read-only access possible to the repo? Would
Keybase work on a Jenkins box? Could a deploy server verify signatures before
deploying?)

\- Could one set up mirroring to GitHub? How would this work? (I could see the
signing without encryption as a value-add)

\- What happens in the event of a force push? Could certain users destroy
history?

\- Could protected branches eventually be added, eg only certain users can
push to master?

~~~
strib
> \- How could CI/CD be set up? (Is read-only access possible to the repo?
> Would Keybase work on a Jenkins box? Could a deploy server verify signatures
> before deploying?

You could have a deploy/CI user as a "reader" in your team. But we don't yet
support hooks or anything (as that implies running arbitrary code on endhosts
without their knowledge), so it would have to pull the repo.

> Could one set up mirroring to GitHub? How would this work? (I could see the
> signing without encryption as a value-add)

You can of course continue to use Github as a regular remote, but you'd lose
all the encryption and signing unfortunately.

> \- What happens in the event of a force push? Could certain users destroy
> history?

We do currently allow force pushes. Being able to turn that off on a repo-by-
repo basis is something we'll consider in the future, definitely.

> Could protected branches eventually be added, eg only certain users can push
> to master?

Yes, but again, as with any "server"-side feature, this is complicated by the
fact that it has to run on the client itself, and thus isn't really strictly
enforceable against modified clients.

As we get more experience with people using this, we will definitely be
thinking about how to make it better by adding power features like these.
Thanks for the feedback!

------
iamthirsty
This actually got me to signup for Keybase today.

------
ryanqian
I have a long running vm on Google cloud with only tiny configuration. I
communicate to it with strong crypt way to access my 'pass' s git repo. So far
so good, but I'm good to see what keybase's good work on how to improve the
personal data safety, that's a good choice.

------
earlybike
I could basically store all my sensitive data there? Passwords, SSNs, private
keys of ETH wallets, etc.?

~~~
aeorgnoieang
Yes

------
j7ake
Hi security newbie here, I have private bitbucket repo for storing my pass
data. One problem is that pass often leaks some metadata like headers of
directories. From security standpoint does this mean it is more private to
host the git repo on keybase versus bitbucket ?

~~~
jredmond
That depends - is that data encrypted on your system? Since git is
decentralized, there's a chance that any plain-text copy (such as a clone on
your system) could be compromised. Keybase even addresses this in the FAQ, to
an extent:

> What if my computer is compromised?

> Your work is only as safe as your endpoints, so we can't help you there.

This applies regardless of host or protocol, BTW, and it isn't even specific
to computing. (It doesn't matter how many locks you have on your front door if
you leave the back door propped open.)

~~~
j7ake
Hi pass uses gpg encryption on the text files my only concern are the file
names which can leak meta info, for example just searching GitHub
[https://github.com/zurchpet/pass](https://github.com/zurchpet/pass) shows
this person has passwords in a public repository but encrypted. Nevertheless I
can see that the file names are credit card info and other sensitive info.
It's like having a safe with a label "important stuff inside" ! Does keybase
solve this problem ?

~~~
tanderson92
Yes, the contents of the git repository holding your pass files are encrypted,
meaning that the file names are not visible to anyone without the private key
(you).

You may also want to look at [https://github.com/roddhjav/pass-
tomb](https://github.com/roddhjav/pass-tomb)

~~~
j7ake
Thanks for that I'll consider it.

------
ValentineC
From the article:

>> _What are the limits?_

> _You can have as many repositories as you want, but the total for your
> personal repositories can 't exceed 100GB. Each team also gets 100GB._

Is there anything stopping people from creating team after team just to hoard
data in Keybase?

------
tln
This is pretty cool. I've used git-crypt before to encrypt parts of a repo,
but this approach seems much easier to manage.

[https://github.com/AGWA/git-crypt](https://github.com/AGWA/git-crypt)

------
gwenzek
I don't really understand how it works. Are the git objects encrypted before
being pushed? In that case how are they handled by the server? Does it accept
them even though they make no sense? What Github is going to show?

~~~
mrsteveman1
Keybase is just another Git remote you can push to, one that transparently
encrypts whatever is pushed to that remote.

The Git repo itself is completely normal in every other respect, so if you
push to Github, everyone can still see the entire repo.

This is a good design as it lets people move repos easily and avoid too much
lock-in, but it may (will...) come back to bite people soon, who push things
to Github thinking they were "encrypted by Keybase", which is not what's going
on.

------
WindowsFon4life
If only their app did not have so many pages marked writable and executable...

------
ris
Keybase, please just support web of trust already. In _some_ way. Not everyone
I want to be able to authenticate necessarily has public social media
accounts.

~~~
JBiserkov
Do they have a website/server?

#1. Host a file on your site

You can host a text file, such as yoursite.com/keybase.txt. This is preferred,
if you have a website.

#2. Set a DNS TXT record

Instead of hosting a web page, you can place a keybase proof in your DNS
records.

~~~
ris
> Do they have a website/server?

Not necessarily. I'm talking about people who want to remain anonymous (or
pseudonymous) and might want to keep as low a public online profile as
possible.

------
ryanpcmcquen
This is amazing and convinced me to install Keybase on all my comps. I would
like the ability to browse the repo in the Keybase app though.

------
squashmode
My thanks to the keybase crew, I've waited for a practical PGP solution for
nearly 20 years. Keybase delivers, thank you!

------
jancsika
> Keybase team member here. Interesting fact: git doesn't check the validity
> of sha-1 hashes in your commit history.

Not sure I understand.

git clone blah

cd blah

git fsck

What am I missing?

------
hollander
Does this work for a local repository?

------
dorfsmay
I'm confused. Is the entire repo encrypted, or some files only?

If the former, what are case where this is needed?

~~~
aeorgnoieang
The entire repo is encrypted.

Consider a repo containing passwords. It's easy enough to encrypt the files
containing the passwords but the names of the files or even the directories in
which they're located are also info you might wish to hide, e.g. that you
_have_ an account at some-site-you-do-not-want-anyone-to-know-you-visit.com.

------
gigatexal
This is really friggin' cool! Best of luck to you guys, hope the work
continues.

------
payomdousti
is there a way to view / verify that the payload has actually been encrypted?

------
voanhduy1512
Thanks for nice product. From now on I will move all my git repo into keybase

------
zrg
I give gitlab 2 months before they implement and launch encrypted git

------
paule89
just to clarify: 1\. Do you need a private git repository? 2\. Is everything
really encrypted? 3\. If everything is encrypted how can i access it through
Git Desktop?

~~~
strib
You can have team-based or private repos hosted by Keybase. Everything is
encrypted and signed before it leaves your computer, and decrypted and
verified when your computer downloads it. But your local checkout of that git
repo is unencrypted. It's just a normal repo. So Github Desktop has full
access to it, like it does for all files in your local filesystem.

------
Zynjec
This is awesome, thanks for the heads up.

~~~
simonRedwards
Yup!

Definitely not just posting this to verify myself.

------
daveheq
Just wait til the government bans this because people will store kiddie porn,
terrorist communications, and copyrighted media into it.

~~~
sorokod
"Just wait til the government bans this because people will store kiddie porn,
terrorist communications, and copyrighted media into it."

More precisely, the government will _claim_ that ...

------
LeicaLatte
Fantastic!

------
hasenj
Wait, what exactly _is_ keybase?

The home page says:

> Keybase is a new and free security app for mobile phones and computers.

ok, so, what does it do?

> For the geeks among us: it's open source and powered by public-key
> cryptography.

Still have no idea what it does ..

> Keybase is for anyone. Imagine a Slack for the whole world, except end-to-
> end encrypted across all your devices. Or a Team Dropbox where the server
> can't leak your files or be hacked.

ok, so what is it? what does it do?

> [picture that looks like a chat app]

So it's an encrypted chat server?

What is it?

How can you have a homepage for a product that doesn't talk about what the
product is and what it does?

Why so obscure? Are you trying to hide something? Is this really a home page
for a product aimed at people who care about security?

Compare it to, for example, tarsnap's[0] homepage, which explains exactly what
the product does and doesn't leaving you wondering about anything.

[0]: [https://www.tarsnap.com/](https://www.tarsnap.com/)

~~~
OJFord
It's a lot, isn't your third quote a pretty good description?

> Keybase is for anyone. Imagine a Slack for the whole world, except end-to-
> end encrypted across all your devices. Or a Team Dropbox where the server
> can't leak your files or be hacked.

It's not much of a reach to assume familiarity with Slack and Dropbox; the
message is clearly that Keybase is those (via Keybase Chat & FS) but
encrypted.

For what it's worth, it's also a keyserver, and (now) git remote.

~~~
hasenj
> isn't your third quote a pretty good description?

It's not. I think the person who wrote it think it's good marketing, but even
that, it is not.

Here, try to see if this makes any sense as a product description:

> FeedHamster is for anyone! Imagine a Yelp that's customized just for you! Or
> a YouTube feed that only shows you interesting videos that _you_ would like!

> Install FeedHamster now!

Now, can you guess what FeedHamster does? Maybe it curates content? Honestly I
have no idea. I just made it up. It doesn't really say anything useful at all,
but I think it makes more sense that that description on Keybase's website.

~~~
kinoshitajona
Tarsnap was a good example of a service selling to technically apt customer
base. Guys who have years of IT training would love to read about
deduplication and picodollars.

Keybase isn’t charging money to begin with, so “sales pitches” are not their
primary concern.

Also, they are marketing to “the masses” with the idea that more people should
have secure e2e encrypted communication and collaboration solutions where
identity is cryptographically proven.

But if their welcome page started showing diagrams of encryption pathways and
key derivation algorithm names with server client relationship diagrams, I
guarantee no one besides people in tech will download it.

I still think they need to do better selling the idea to the masses, I in no
way think their current front page is sufficient, but I understand that right
now they aren’t concentrating on sales pitches.

------
adiosdfisndf
Tried to create an account and no matter what I tried to name my devices all I
got was "keybase has reserved this name."

Welp.

~~~
cjbprime
Ah, it's not the device names that are reserved, it's the username itself.

------
feelin_googley
Does it use libgcrypt?

[https://www.theregister.co.uk/2017/07/04/gnupg_crypto_librar...](https://www.theregister.co.uk/2017/07/04/gnupg_crypto_library_cracked_look_for_patches/)

Maybe it only uses the Go crypto libraries?

------
aauthespian
[http://www.aauthespian.news/2017/10/why-are-some-nigerian-
mo...](http://www.aauthespian.news/2017/10/why-are-some-nigerian-mothers.html)

------
hdhzy
Sounds intriguing but I'm missing the deep technical info on how it works.

> All data you push is signed by your device's private key, which never leaves
> your device.

For the reference git already supports signed pushes (git push --signed):
[https://github.com/git/git/commit/a85b377d0419a9dfaca8af2320...](https://github.com/git/git/commit/a85b377d0419a9dfaca8af2320cc33b051cbed04)

~~~
welder
Signing a commit does not encrypt that commit's contents, just adds a
signature to prove you wrote that commit.

From the Keybase FAQ:

> So is this signing my commits?

> No, this is happening at a lower level, (1) to allow encryption, and (2) to
> ensure no unsigned or unencrypted data makes it in. Intuitively you can
> think of it as you and your teammates using a cryptographic secure storage
> layer for your git origin that doesn't really understand git.

> Your commits themselves are untouched from git's perspective, so if you
> mirror your repository elsewhere, it'll be a regular checkout.

~~~
hdhzy
I did not mention signing commits but signing push requests and that was a
reference to:

> All data you push is signed by your device's private key, which never leaves
> your device.

------
therealmarv
If you go crypto don't use git. It's not designed for cryptography in mind and
the Keybase approach looks nice IF I can control every chain or can keep using
github (or any other git server) with it. But for the storing part alone I
would not trust Keybase. I would even say if you do crypto and need cloud
storage then store it in multiple places and avoid git. Better flat file and
some daily backup strategy with e.g. encfs as the bottom layer. In worst case
you get your data back.

Sorry keybase.... you are not a trustable cloud storage for me.

It feels like betting on your company... I want to bet on your company without
feeling dependent on worst case restore scenarios (computer dying while your
company dies).

~~~
eridius
> _But for the storing part alone I would not trust Keybase._

Why not? You're making a bunch of claims about this being bad but you're not
providing any reasoning for it.

~~~
therealmarv
It's basically new closed source one bucket crypto on one company which is not
known for storage. A little bit too much of uncertainty for my taste.

~~~
kristianp
A large portion of their code is open source:
[https://github.com/keybase](https://github.com/keybase)

~~~
sigjuice
How easy is it to build and run my own copy of this code, especially the
server side stuff?

