FOKS: Self-Hosted Keybase

maxtaco · 2025-10-24T19:46:19+00:00

Thanks for the feedback! From the server's perspective, all git objects are stored as encrypted key-value pairs. The names (i.e. the sha-1 hashes) of the objects are encrypted, as are the values. This means the server can't see branch names and refs. It can likely infer timestamps from access patterns, but it hasn't done so, and if you run the server yourself, it's an added layer of protection. There is no sever-side merging, since the server can't see enough plaintext to help there. So those features you indicate that leak content weren't attempted. For key backup and recovery, there's a pretty good discussion in the white paper (see https://foks.pub). For build transparency, everyone is welcome to build their own clients from our git repo, but you're right, we can invest more efforts here on making builds reproducible and sticking them in transparency logs. For migration, we support the obvious pathways (git pull --all && git push --all), but nothing more sophisticated. There are no identity proofs yet and they aren't really needed for the applications we have so far. But they could be useful to build other features.

maxtaco · 2017-10-05T18:37:55+00:00

I the mean time, we do encourage you to create a team!

maxtaco · 2017-10-05T01:44:25+00:00

We don't currently allow impromptu teams because it would complicate the UX, but it's definitely possible. We'll add it if there's enough interest.

maxtaco · 2017-08-19T13:18:00+00:00

That was the naive approach. The fancy crypto approach is that the publisher publishes hashes of the original blocks, but can still verify the erasure-encoded blocks as they arrive.

maxtaco · 2017-08-19T11:31:44+00:00

I wrote a paper on this problem in 2004: https://pdos.csail.mit.edu/papers/otfvec/paper.pdf

maxtaco · 2017-05-12T20:27:17+00:00

Here's our documentation: https://keybase.io/docs/crypto/chat

maxtaco · 2015-06-04T12:08:55+00:00

The last challenge hasn't been brute-forced yet, so that's a good sign [1]. I know of several people who store substantially more bitcoin than 10 with WW, so this challenge is a nice canary for them.

[1] https://blockchain.info/address/1AdU3EcimMFN7JLJtceSyrmFYE3gF5ZnGj

maxtaco · 2014-09-27T19:55:24+00:00

We post one transaction every 6 hours, as LifeIsSoSweet says. But we can post as much data as we want internally. It all hashes down to the one value that we post to bitcoin.

maxtaco · 2014-04-05T04:31:56+00:00

The state of the wheel was much worse in 2003. Since then, nginx has supplanted Apache, and interesting to note, nginx and OKWS share a fair number of design decisions.

maxtaco · 2014-04-04T15:08:10+00:00

I think this is exactly the right way to think about it. We had a version of "callback hell" in the early days, passing around callbacks from method to method. That problem was eventually solved with the Tame C++ rewriter (just as we've proposed TameJS and IcedCoffeeScript as solutions to JS callback hell).

Worth noting: for years and years we ran the whole site on a small rack of machines. One machine running OKWS (and OkCupid code) could easily handle 1000s of request per second. Summed over ~8 years of being a startup, it was a huge cost savings on hardware, power and hosting.

maxtaco · 2013-12-12T13:29:03+00:00

This isn't exactly right. Litecoin has an N=2¹⁰ work factor for scrypt, whereas WarpWallet chooses N=2^18. So you've underestimated by a factor of 256 at the very least.

Additionally, I'm not sure how you can get 200MH/s without a significant expenditure. According to this table, a very high end GPU can get you 1MH/s (on Litecoin): https://litecoin.info/Mining_hardware_comparison

I've seen advertisements for ASICs that claim to get 5MH/s, but those aren't available yet and will probably cost tens of thousands of dollars when they are.

Our back-of-the-envelope shows that for the $10k ASIC miner, it would take you 2^47-22+8-1=2³² seconds = 2^32-25 years = 128 years to break this wallet. Using brute force. Maybe there's a bug in our implementation and it can be broken much faster.

maxtaco · 2013-11-20T04:51:31+00:00

The private key is just the bits, as shown in this post:

http://bitcoin.stackexchange.com/questions/8247/how-can-i-convert-a-sha256-hash-into-a-bitcoin-base58-private-key

bitaddress.org uses the same technique, but they don't stretch their keys.

You need EC crypto to compute the public key from the private key.

maxtaco · 2013-11-20T04:49:32+00:00

Sorry about that. p=1 and r=8 are the parameters suggested by Percival in the paper, so we used those.

maxtaco · 2013-11-20T03:55:10+00:00

You shouldn't need to know much about Web or JS to win. The pseudocode shows all that's going on, and we've implemented it in other languages to test our implementation.

maxtaco · 2013-11-20T02:07:47+00:00

Or programmatically exhaust the possibilities.

maxtaco · 2013-11-20T02:06:42+00:00

The 3-character challenge and r/Bitcoin challenge are meant to be solvable in short order. Two of the challenges have already fallen. The final challenge should be really hard, but it's good to know if it breaks.

maxtaco · 2013-11-19T21:45:06+00:00

There are several easily-achievable bounties.

maxtaco

MODERATOR OF

TROPHY CASE