maxtaco

21 ms·

61.
by maxtaco 12y ago
We'd like to reimplement ICS using ES6, but keep the await/defer syntax and semantics as they are. The current ICS is a big modification to CoffeeScript, and maintaining the patch is tricky. Hopefully ES6 will ease that headache.
62.
Handling errors in IcedCoffeeScript(maxtaco.github.io)
4 points by maxtaco 12y ago|1 comments
63.
by maxtaco 12y ago
SHA1 is the only supported hash algorithm for PGP key fingerprints.
64.
by maxtaco 12y ago
Good suggestion to avoid PKCS v1.5; sadly PGP requires it: http://tools.ietf.org/html/rfc4880#section-13.1
65.
by maxtaco 12y ago
Should be fixed now. The Google End-to-End library uses the 5-byte encoding scheme for signature subpacket lengths, which I hadn't seen used before and was buggy in KBPGP. Most signature subpackets are <192 bytes long and can be e
66.
by maxtaco 12y ago
A lot of the same techniques. No need for proof-of-work since there's no contention for a scarce resource. We might, in the future, periodically write our root block to the Bitcoin blockchain as a further protection against forking at
67.
by maxtaco 13y ago
This feature is now live on keybase.io. You can prove Twitter, GitHub or Web site identities without posting a secret key or installing our installer. We give you a (rather long) pipeline to run at your shell.
68.
by maxtaco 13y ago
Install-less, hosted-private-key-less Github, Twitter and Web site verifications are now live on keybase.io. Enjoy!
69.
by maxtaco 13y ago
We hope to roll out 2FA shortly. If enabled, you'll need to present a token before retrieving your encrypted private key from the server. Though of course it won't help if our server is hacked or subpoenaed. We haven't tried
70.
by maxtaco 13y ago
Many Random Oracle crypto proofs assume a value is random and then substitute in something that's not quite so good, so I think it's a valid thought experiment. And some passwords do have 256 bits of randomness (i.e., ~15 random
71.
by maxtaco 13y ago
Hopefully the pace of changes will slow down once we arrive on the correct core feature set and we sort out the bugs. An earnest thanks to HNers and others for being such great alpha testers BTW.
72.
by maxtaco 13y ago
A browser extension is in our (ever-expanding) todo list. We had one a few months ago, but we have to do a fair amount of work to get it back up to snuff.
73.
by maxtaco 13y ago
Yes, it is, and it's 100% open source.
74.
by maxtaco 13y ago
Hmm, interesting idea. In general, there is only one sensitive operation per keybase invocation (though many signature verifications that use only public keys), so this is doable but cumbersome.
75.
by maxtaco 13y ago
It was a thought experiment to encourage people to think about the issue at hand and not dismiss it with a knee-jerk. Your concern is now key stretching and password selection.
76.
by maxtaco 13y ago
We're definitely worried about the hushmail attack, and we disclaim browser-based crypto on the site for those who want to protect against powerful adversaries. Some users might not have those concerns. You've obviously indicated
77.
by maxtaco 13y ago
k is derived from a password in this case, so capture of the password implies capture of k. We give people the option to store their encrypted secret keys on our server to make it easier to manage their key and sync it across their devices.
78.
by maxtaco 13y ago
Agreed. We wish there was a practical solution to this problem, but at some point, it's turtles all the way down.
79.
by maxtaco 13y ago
We agree this is a problem, all of those who try to access their private key during the compromise would be in trouble. Those who stayed offline would be safe. BTW, this argument does not extend to the CLI or other uncompromised clients. P
80.
by maxtaco 13y ago
There's one instance in which we prompt for your PGP password directly, since gpg doesn't give us command line access to the needed feature: that's adding the username <you@keybase.io> to your public key if it's no
81.
by maxtaco 13y ago
We seem to have hit a real nerve here. I ask everyone to question their assumptions just for a moment. If you post a public key, you are letting the world see p*q. Is it insane to let some people see AES_k(p,q) if k is 256 random bytes?
82.
by maxtaco 13y ago
Indeed, the chicken paper inspired the work of Mazieres and Kohler. They should have cited it, maybe that's why SCI rejected them.
83.
by maxtaco 13y ago
At the time, there was an arms race within the systems community to see who could flip a bigger bird to the organizers of the SCI spamference. David Mazieres and Eddie Kohler started it off when they submitted "Get Me Off Your Fucking
84.
by maxtaco 13y ago
The papers in question were generated by the SCIGen paper generator. Jeremy Stribling, Dan Aguayo and I are the authors of that system, with Jeremy doing the lionshare of the work. The inspiration for SCIgen was TheSpark.com's high sc
85.
by maxtaco 13y ago
Agreed.
86.
by maxtaco 13y ago
If the site went away tomorrow, you'd still have keys in your GPG keychain. You'd also have a local cache of the server-side data relevant to you. All public server-side data is available as a dump ( https://keybase.io&#
87.
by maxtaco 13y ago
As Chris said, we would like to publish everything, just haven't found the time yet. We have bits and pieces in wikis in our various github repositories (almost all of which are open source and public). The high bits are: all crypto i
88.
by maxtaco 13y ago
Cool, I agree no one should use PGP servers the way I described, but you never know what people are doing out there. To do things the proper way, as you described, is difficult in practice for lots of people. To answer the question, the po
89.
by maxtaco 13y ago
Yes, though it might be broken right now. Our plan is to allow this, for sure.
90.
by maxtaco 13y ago
We're not big fans of browser PKI either, but we're using it as scaffolding that hopefully one day can be torn down. `keybase-installer` needs an initial install over https from npm. We unfortunately saw no way around this. Assum

More ›