Live data from Hacker News

Keybase launches encrypted Git

keybase.io

51–60 of 277 posts

Re: Keybase launches encrypted Git

#51
post #10

Earlier quoted context omitted.

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 assu…

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…

This is a fantastic answer, and I wish more folks were this dedicated to making sure they have something great before trying to hawk it. That said, I do wish I could pay for (at least) a TB of Keybase storage right now. :D

Re: Keybase launches encrypted Git

#52
post #47

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...

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.

Re: Keybase launches encrypted Git

#53
post #50

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,…

> Interesting fact: git doesn't check the validity of sha-1 hashes in your commit history. Isn't the commit sha1 determined, in part, by the sha1 values of the tree it refers to as well as the sha1 of the parent commit? If you fetch a branch from a compromised remote, all the sha1 values of the commits that were compromised would be different.

Correct, but git doesn't recompute the hashes locally, so it wouldn't know they are wrong.

Re: Keybase launches encrypted Git

#54

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.

> ~ Anticipated A's ~

> YES. IT'S LIKE THE MATRIX BUT INSTEAD OF ROBOTS IT'Z LIZARD PEOPLE.

> THIS ISN'T A QUESTION BUT GOOD POINT. WE R BEGINNING THE MOVE UNDERGROUND.

Re: Keybase launches encrypted Git

#55

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,…

Thank you and the rest of the Keybase team for your hard work!

Is it possible to use this on the Keybase mobile app for like note-taking?

Re: Keybase launches encrypted Git

#56

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.

https://github.com/kbsecret/kbsecret is Secrets management back by Keybase :)

Re: Keybase launches encrypted Git

#57
post #52
post #47

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...

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 th…

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.

Re: Keybase launches encrypted Git

#58
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!!

Re: Keybase launches encrypted Git

#59
post #53
post #50

Earlier quoted context omitted.

> Interesting fact: git doesn't check the validity of sha-1 hashes in your commit history. Isn't the commit sha1 determined, in part, by the sha1 values of the tree it refers to as well as the sha1 of the parent commit? If you fetch a branch from a compromised remote, all the sha1 values of the commits that were compromised would be different.

Correct, but git doesn't recompute the hashes locally, so it wouldn't know they are wrong.

Ah, so if I were to manually craft a commit in a text editor in the format:

    tree sha1
    parent sha1 of parent I want to attach it to
    author some string
    committer some string

    The commit message
I could add this to the git object store manually under the same sha1 file and a client could just fetch it? Would the client try to fetch the faked objects when it already has the real objects in its copy of the object store?

That is, would it think it has the commit because the sha1 hasn't changed, but the tree sha1 has been updated and it would presumably refer to blobs that the client doesn't already have and try to fetch them. Or would it not proceed because it already has the commit?

Post reply on HN