-
I’ve started a github repo for this project (oh, the irony!) at https://github.com/nyarly/simplekey - /cc @englishm @brunov
-
I agree with this: “The best light I can see that in is that they’re well meaning, but simply unqualified to design and run a cryptographic system.”
The aspects of Keybase.io that aren’t reinventing existing OpenPGP infrastructure remind me a lot of ClaimID.
-
Which is shut down now…
-
-
By far the biggest problem with Keybase.io is the suggestion to upload your private keys to their service. This completely breaks security. I like the ability to easily verify via other channels like Twitter and Github; GPG supports varying trust levels so you could trust a key .
I suppose the target audience for this service is technical people who are (excusably) put off by the complexity of
gpg --help. Ultimately, I hope Keybase helps the existing GPG system rather than attempting to create a silo.-
-
It’s not a requirement: you can do everything using their command line client, which is open source and doesn’t require uploading private keys. Private key hosting is a convenience thing for using their webapp to sign things.
I wish they wouldn’t even make private key signing possible, but it isn’t a hard dependency.
-
-
I opened an issue about this: https://github.com/keybase/keybase-issues/issues/160
-
That response is quite concerning – that sort of security/convenience argument is not a strong one, and further it encourages an insecure default to new users of cryptography; which is precisely the sort of user keybase is trying to attract.
In particular, no matter how well encrypted your key, it is possible that an attacker breaks in, downloads all those keys, and attacks them in-bulk using standard attacks against a large keybase. It’s a massive security hazard and no amount of convenience can justify it.
-
-
That suggestion is part of what makes me suspicious of the entire system. I can’t see how any well meaning, moderately competent security person would suggest such a thing.
Building a new centralized directory, because “PKI is hard” makes me think that “building a silo” is exactly what they’re trying to do.
-
-
@judsonlester Regarding the shell scripts you propose, I’d be interested in helping with an effort along those lines.
Everyone knows that GPG has a terrible UI, and we all like to rail against bad CLIs, but does anyone have examples of good design principles applied to a complex command-line application? I’d be very interested in any research that’s been done in that area.
-
Related discussion of usability & crypto tools suggests that there are very few people with a design background working in this space right now.
-
I think there’s a couple of basic principles that could be usefully applied. I think of the difference between (in Ruby-land) Thor and Rake - Thor encourages “command subcommand argument” style command lines, and goes the extra mile to e.g. colorize output, and output only the details a user cares about.
Also: gpg remains a complete implementation of RFC 4880 more than anything else. It’s like the git plumbing - I think there’s a lot of room for porcelain there.
I think you could provide a 5 feature implementation (generate keypair, trust pubkey, sign-encrypt-armor, decrypt-verify, revoke keypair) in the form of well-commented scripts so that users can delve into the deeper applications at their leisure.
-
-
I’ve been working on a game engine that runs over an HTTP API, so you can run whatever humans/machines you want behind the API call as long as it returns in 30 seconds. You can actually play connect four with it at the moment but it’s very much a work in progress at the moment.
-
-
Hey me too!
-
-
-
-
-
One thing I’m still not clear on: is Raft a specialization of Paxos or not? If not, how does Raft differ?
-
It solves the same problem, in a way that is theoretically not as efficient, but is easier to understand. (The paper – which again, I highly recommend – has some evidence for this last claim.)
Given the proliferation of implementations, it also gives some weight to the idea that “easier to understand” means “easier to implement”.
-
Given the structure of the FoundationDB cluster, I was disappointed that they only tested Master and Co-ordinator in particular groups. What happens if both are in the minority?
Also: I followed the Jepsen blogs with some interest and note that the Riak+CRDT case (0% loss) wasn’t listed in their table.
It is there, below “Riak with strict quorum” and above Zookeper.
So it is - don’t know how I missed it.