Since Keybase inevitably comes up in these PGP conversations, 2 things in advance:
1. I've really been very slow in letting people into Keybase. The wait time is still 6 months (last night I was letting in people who asked back in August.) But now that we've added HackerNews key proofs, I'll let people in today who notice this post who have more than 1 karma and write "I'm HN: {theirusername}" in the request form.
2. We're not just about PGP keys. It looks that way now, and our first goal was to help solve the very on-the-record type things developers do. Which mostly requires PGP - and PGP is very good at. Signing code and commits, releasing software, etc. But sometime soon each of your Keybase devices will have a device-specific Nacl key, for example. And the process for provisioning devices is something we're taking very seriously - we'll soon have a big blog post about how public sibling key announcements will work. Here's the foreshadowing: with a Keybase account, very soon you'll be able to start with something as simple as a Twitter or HN username, and do some very cool, secure things with files and messages.
[EDIT] We are hiring. There's no specific job page because we've mostly been reaching out to people quietly, but we want help building: the Keybase client (Go), iOS and OSX GUIS (Obj-C), and the site (front end development and back end (Node)). Please reach out to me (chris@keybase) if you like the idea of working on usable security software. We are currently distributed in NYC, SF, and CHI, and ideally you'd work with us in one of these offices.
I was initially skeptical of Keybase, but I was happy to see the comments on HN of letting people use keybase without installing the CLI client were listened to. Seeing how many of my friends are on keybase now, that never had gpg setup before, I can't help but think it's filling a need that's otherwise unserved.
A lot of people are doing it this way: a GPG user can join Keybase via the website, without installing any Keybase client. When it comes time to prove something with their private key (say, their twitter account), the site shows them what to do, using bash/GPG/cURL.
It's pretty straightforward if you already have a key pair / GPG installed. There's no Keybase software to run, and the site basically acts like a todo list / tutorial.
Thanks for the opportunity to try out Keybase. Great work.
The only question, but really important is: What is Keybase's business model? How will you make your living? It's a great service, I'd love to build upon it (my company does email as a service), but that step requires knowing you'll still be here a few years from now.
Technically, not a lot has changed. We're still just putting our own money into it. However, we just added 3 people full-time and 1 person part-time, and so our costs have gone up. I'll admit, we only did this when we got an idea that we thought could turn Keybase into a business.
In a few months we'll be launching a tangential idea - more than just a PGP key directory. This product will let you do some neat things with data backup and signed (possibly encrypted) file hosting and message spooling. It has nothing to do with email, but it requires a real PKI. I'll save the specifics for a big announcement, but the pricing model will reflect our costs with room to make money. More per gig than Dropbox and far less than Tarsnap.
Should the "business" fail, we'll be back to where we were when I wrote the above answer.
I hadn't really heard about keybase yet, but does it solve the only problem worth solving in encryption? Does it allow me to take any email address and give me back a private key that only the recipient can use?
If I wanted to know which public key to use I would just look at the recipients public website or ask that person through a phone.
The problem is that people don't create keys because nobody ever send them anything encrypted and people don't send anything encrypted because nobody ever sends anything encrypted.
But if keybase is just another storage for keys, what is the point? Especially if it is going to add a pointless waiting list that is just going to make the problem of not having a key even worse.
Keybase lets you do some key stuff, but the bigger feature is that it provides a bunch of ways to authenticate the source of a key above and beyond the WoT and getting into the strong set. Authentication is an inherently hard problem. With keybase you can, for example, see that the key that you want to use to send an encrypted email to x@example.com's website is owned by someone who also controls x@example.com's twitter, reddit, github accounts, web-site, etc, making it less likely that there's a MiTM going on.
Easier PGP programs would increase the use of encryption, especially post-Snowden. I've walked people through using GPG4WIN/Kleopatra and it took a good half hour of explaining how everything works. People care about privacy, but unfortunately not enough to go through the hassle of manually encrypting everything.
Not sure I understand what you mean. For some family members I set up Thunderbird+Enigmail, which was very quick including keypair generation.
Now they communicate with me always encrypted, automatically. They don't have to know any details about encryption, except that they occationally have to type in their password.
Hmm... I never knew about you guys. I think I may need to do this. I've been meaning to get rolling again with GPG, in part because I want to move to `pass` for password management. Might need to spend some time today getting my ducks in a row.
Cool, just keep in mind Keybase isn't an email client. So if your goal is encrypted email communications, you'll still need to pick a client for that. Whiteout/Thunderbird w Enigmail/Mail.app w/GPG Tools are all apps to look at for your desktop.
Keybase right now is basically just a directory. It's a different model for making sure you get the right key for the right person. As diafygi pointed out, the traditional PGP keyserver model is busted. There's no canonical ordering of key announcements and revocations, and the gossip protocol is messy. Solving this based on social accounts is our top priority. Every proof or revocation you do on Keybase is put into a chain for you, and in turn that chain is attached to our merkle tree and written to the bitcoin block chain. We want to prove everyone in the world is getting the same answer from Keybase, everything is ordered, and that we're not omitting anything.
My keybase.io account is useless because of an error I cannot comprehend. I've never had a problem with my key, and it was working just fine when I signed up!
Your public key appears corrupted (no valid primary key self-signature)
edit: my self signature is fine, as far as i can tell
I moved this to an issue on Github [1]. The key you uploaded to our server has a UID that expired on 2014-11-09. The key you linked to on the MIT key server has updated self-signatures (and subkeys), so doesn't have this problem.
How hard would it be to add support for RubyGems certs being added to keybase? I’d love to publish the public cert somewhere without putting it in each repo.
I'm not really positioning TextSecure as a secure mail solution, but this article says that the TextSecure protocol can't support asynchronous operations or federated namespaces. To clarify, that's incorrect, the TextSecure protocol was actually designed from the ground up for asynchronous communication, and is designed to support a federated namespace: https://whispersystems.org/blog/asynchronous-security/
That leaves these points for PGP:
> It’s been around for a long time, so it’s cryptographically well understood.
Yes, but it's cryptographically well understood not to provide the properties we need.
> There are a variety of implementations and there is a small but vibrant and highly committed developer community.
> A small but active and committed user community.
Small can't be emphasized enough, and this is the most important part to me. I think people have a tendency to look at PGP and conclude that while it might be painful, we have to put up with it for backwards compatibility. The truth is that it's a protocol with few contemporary redeeming qualities, and an active user base of ~50k. So why bother with backwards compatibility?
> Yes, but it's cryptographically well understood not to provide the properties we need.
If you're talking about perfect forward secrecy, surely that's fundamentally impossible for a protocol that is both asynchronous and decentralized? If one party can only send a single async message to another, then that message necessarily must be decryptable by that second party using only what that second party knows, and you lose PFS. PFS only works for synchronous communications where both parties can use a key exchange protocol, or centralized communications where an asynchronous message can be implemented as a synchronous message to a central authority. No?
> With the initial key exchange out of the way, both parties can then continue communicating with an OTR-style protocol as usual. Since the server never hands out the same prekey twice (and the client would never accept the same prekey twice), we are able to provide forward secrecy in a fully asynchronous environment.
So, my laptop is off-line, and I have access to a recipients public key. How do I encrypt my message, before moving it to a machine that's on-line for sending via smtp?
This isn't really asynchronous in the sense that email is (stop-forwards-stop-forward). Nor does it appear to work for writing and encrypting an sms while on an air-plane (the message will only be encrypted when the pre-key can be retrieved).
It doesn't seem quite fair to claim (or rather imply) that the scheme does for email what pgp does.
It also carries more state around (on the "server" and on the "client") so it's not decentralized. It might be closer to pgp than classic otr, but it's not really a replacement for pgp as far as I can tell.
> (the message will only be encrypted when the pre-key can be retrieved).
The pre-key is needed when you have never talked to someone (I guess it's also needed when the last conversation is really old, I haven't dug throuh the code); it's a necessary bootstrap step. After that all you need is inside your client.
> So, my laptop is off-line, and I have access to a recipients public key. How do I encrypt my message, before moving it to a machine that's on-line for sending via smtp?
You encrypt it on your laptop, transfer the encrypted blob to your online machine and send the blob through it. All state is managed by your laptop, intermediary machines are just forwarding the message (which is merely an opaque blob at this point, possibly with a "destination" to ease routing to the recipient(s)).
> Nor does it appear to work for writing and encrypting an sms while on an air-plane
From a user pov, there is no difference between:
- I type the message and hit send, the message is encrypted now and sent when I have connectivity
- I type the message and hit send, the message is encrypted and sent when I have connectivity
The problem here will not be technical but purely UX (the software has to allow deferring encryption and sending when resources are available)
> It also carries more state around (on the "server" and on the "client") so it's not decentralized.
The little state there is on the server really doesn't sound centralized to me in that it is really simple (the server must be able to store a given list of blobs sent by the client, and the server must not send twice the same blob, ever) and a client can choose any server (there is no concept of "registration", but the client has to trust the server it will not misbehave).
The state on the client is really client-specific, it wouldn't make sense to share a client's ratchet state: as a comparison you wouldn't share the current bucket list of your DHT client with other machines because it doesn't make sense, you would rebuild it from scratch on another machine. Effectively this means every device of yours is considered another independent "peer".
I think it's important at this point to say that this mechanism is the Axolotl ratchet (more details here: https://github.com/trevp/axolotl/wiki). It only describes how to exchange encrypted messages between two DH keys, asynchronously, and with forward secrecy. It doesn't care about :
- what is the relationship between DH keys ("should I encrypt to 2 DH keys because they belong to the same user ?")
- how do get someone's key, and is it the good one (the key distribution management)
- how can I have a coherent message history between my phone and my computer
These are all real problems that TextSecure aims to solve, but they're a whole another thing.
> The pre-key is needed when you have never talked to someone (I guess it's also needed when the last conversation is really old, I haven't dug throuh the code); it's a necessary bootstrap step. After that all you need is inside your client.
Well, no. It's needed when you client has never talked to someone. If you have a pad, a phone and a laptop, they all need a pre-key to talk to the same person. If the person's server is down, the system breaks down (you can't have just anyone mirror the pre-keys).
> From a user pov, there is no difference between:
>
> - I type the message and hit send, the message is encrypted now and sent when I have connectivity
>
> - I type the message and hit send, the message is encrypted and sent when I have connectivity
Perhaps not. But there's a difference between being alerted that you can't reach the recipient securely before you type the message, and getting that message (no pre-key available) after you've taken the time to write the message.
Not to mention that hopefully the device has FDE, so there aren't any plain-text messages around for when you go through customs, or when someone steals your phone etc. But I'll concede that device security is probably outside the realm of what a message system should deal with.
Don't get me wrong, I welcome improvements like this -- I just don't think it's comparable to pgp (which is both good and bad).
So yeah, you're relying on a central authority to maintain the prekeys and only give out each one once. The within-session ratchet is cool but I'm not sure if it's relevant to an async use case like email where messages can be sent months apart (would you ever even use a session for more than 1 message?) and the user /wants/ to retain the ability to read their old messages. Likewise the non-repudiation aspect of PGP is by design: it's meant for a use case where you want to "get something in writing", it's supposed to behave like a signature on a letter. (And by the same token it's very much an inappropriate protocol for e.g. IMs, which is why even big fans of GPG will use OTR or some such for those instead).
There's maybe a case for a protocol that offers both (though in practice I've just seen people sign their OTR key fingerprints with their PGP key), but that goes against the simplicity that you're emphasising.
It is not fundamentally impossible. It has been shown [1] that forward-secure public-key encryption can be done without the key size blowing up with the expected number of encrypted messages, though it's not very practical. The trivial case of §3.2, in which the key is simply a tuple of N keys which are erased as messages are encrypted/decrypted, seems similar to what TextSecure does.
He doesn't have one. Sometimes I wonder how difficult would be to sneak a sabouteur into the crypto community, who advocated for ditching proven and safe crypto tools, wanted his solutions on top of centralized servers owned by others, opposed distribution of signed binaries in FOSS markets, recommended the people to use stock OSs with binary and who-knows-what google libs inside, instead of installing the free counterparts, etc..
Is like people have forgotten that they should trust only the algorithms and the implementations, not the persona behind them. And that persona, should be the first saying "don't trust me! trust my algorithms!".
The 50k number comes from the number of people who can reach each other through the web of trust.
If you take every key uploaded to the key servers ever, then it's more like 4 million. However most of those aren't active.
TextSecure, in contrast, has vastly more users than PGP has ever had, despite being a lot newer.
Sometimes I wonder how difficult would be to sneak a sabouteur into the crypto community, who advocated for ditching proven and safe crypto tools
Sometimes I wonder if the best way to sabotage the crypto community would be to fill it with people aggressively advocating for obsolete technologies that have zero chance of any meaningful impact :)
Moxie is unusual in the strong crypto space, in that he is willing to make pragmatic engineering choices in order to ship a working product. That is why he and his team have had a lot more impact than most others have.
Having it installed doesn't mean using it, like you said, for the PGP keys being generated but not necessarily in use.
On textsecure usage
In my experience, very very few people actually sign keys, and few people upload them on keyservers.
Also, I know very very few people who use textsecure. I used it for a few month, trying to get others to talk to me with it and gave up. And I'm in the bay area working with IT people, most of my friends are IT people mind you, we're exactly the people who try that stuff all the time.
It doesn't mean its bad tech or a bad attempt at all, heck, I would LOVE for it to catch up. But I seriously doubt it has 4 millions active users or more.
On PGP usage
From a key server perspective there are still a large number of keys being downloaded, refreshed and updated daily.
Let's look at Mozilla's stats and they just seem to peer with one low traffic guy and themselves... http://gpg.mozilla.org/pks/lookup?op=stats
that's 1k new keys a day, and about 500 updated a day. We're far from the 50k claim since it would reach that in 50 days no matter what.
Of course saying there's only, say a few millions PGP users doesnt mean AT ALL the same as 50k.
On misinformation
Thus I'm calling bullshit. Purposefully misrepresenting data (large order of magnitudes, at that) is a big minus in my book. Being well-known shouldn't mean you can tell people bullshit - if anything, you have a greater responsibility when you do.
> It doesn't mean its bad tech or a bad attempt at all, heck, I would LOVE for it to catch up. But I seriously doubt it has 4 millions active users or more.
The 4 million figure was total users of GPG ever, not TextSecure. TextSecure for Android has had about 1 million installs.
However, it's also been integrated into the Cyanogen mod which added about 10 million users, and the tech has been integrated into WhatsApp, which got the underlying crypto code (though not the UI) to about 400 million+ users.
So if by "TextSecure" we mean the technology rather than the actual UI widget code, which is generic anyway, then it's in a whole other league by orders of magnitude.
You compared the total of PGP users to textsecure saying textsecure has more hence my reply on that (just clarifying)
Or least, that was my understanding of your previous comment
You're basically kinda saying there is between 11millions and 400 millions users, and, you know, i dont trust that at all and would compare it to notepad/paint being installed on windows but not actually used.
Anyway, whichever tech really catches up would be a good thing. I just dislike the manipulation of information for marketing of one tech over another for fame, money, power etc.
Specially when that means bad mouthing free and open source projects :)
Quoting Dan Geer: "Convenience, freedom, security - choose two."
Solid cryptography concepts were never easy to implement and use.
My main problem lies not with the Gnu/PG or PGP software implementations, but with the actual platforms. Do I trust my iPhone/Android/public internet cafe computer/the family computer? Is it compromised? What about your computer manufacturer? Lenovo, perhaps? Or Apple?
The problem of information safety does go far beyond software. Neglecting this is not an option.
There is certainly life in the old dog called pgp, but I am yet to be convinced of a mass market software concept that allows me to have the same level of confidence in its security as the open source packages I have installed on my offline computer.
Choose two? How do I pick security and convenience without freedom? I can't think of any way giving up freedom makes those easier. Blind trust can make me ignore security problems, but I can have blind trust and freedom, or lack of freedom without blind trust.
I feel like "security or convenience" is a better representation of the choice, even if it's not as cute. Freedom is off to the side.
I probably shouldn't go around and disagree with quotes from people I have never heard about, but there is no law that means encryption has to be ackward, user-unfriendly or badly designed.
HTTPS: You can give up freedom and some security for convenience of 3rd party registrars! You can roll your own which is less convenient and likely less secure… Not really sure of the 3rd option here.
Let's put things in context. Would you trust WhatsApp to be part of the US nuclear launch chain? Or talkes between the leaders of US, France, China, and North Korea.
The type of encryption used in whatsapp is not something I want to authenticate in anything that has to be dormant and used in an emergency without a network, but that doesn't mean it is bad crypto.
Yes, why not? You still need to ensure that the people involved with whatsapp can be trusted, but even the NSA can't do that in every case (ie Snowdon).
It's actually quite simple. PGP/GPG is the equivalent of the S in HTTPS. It's a trust model + ciphersuite + tools and libraries for using it. Would you ask your users to use TLS directly? No, you would not. Would you be surprised if the users hated using TLS directly? Nope.
What PGP/GPG actually needs is a nice UI. What's been holding it back is webmail. PGP and webmail are incompatible. Now that mobile is starting to take over people are using non-web based mail clients again and PGP becomes viable again. Imagine integrating Keybase with Mail.app. Now when you send an email to people it's automatically encrypted and verified. As you compose your message you can see that <igor@example.com> is known on Twitter as @exampleIgor and on Facebook as /exampleIgor and on HN as exir.
This is where we should be heading: building on top of the PGP protocol (and fixing the protocol where 20 year old warts are popping up, such as issues with forward secrecy).
The problem is that, on the whole, users simply don't care. They have more important things to worry about than email encryption (you know, stuff like spouse, kids, mortgage, partying, etc).
The only way I can see end-to-end crypto really being adopted is if it's turned on by default everywhere. The selling point can't be the security, because people don't care about security -- the selling point has to be something else. Anything that requires a manual adoption step is going to automatically limit itself to a very niche audience.
Which is why I proposed that UI: it works automatically. While using the system, it simply indicates to you as you compose the message "Yes, the email address you are sending mail to belongs to the person you intend to message" or "No, that email address belongs to someone else" or "This is a brand new email address." This way when you are emailing your lawyer to set up a will, or you email your accountant with your tax info, you can be sure that (a) you are emailing just the right person and (b) that only they can read the communication.
While setting up the system, you are simply required to link your identity. Twitter, Facebook, LinkedIn, GMail, HN, the government all should allow you to easily link your identity. This should be a normal part of your account creation (this can tie in nicely with another change: getting rid of passwords and using a browser UI for identifying yourself a la Persona, but PGP based). Basically when signing up for Twitter, it should optionally let you upload one of your public keys (via a nice browser UI no less). Twitter (Facebook, GMail, etc.) would then expose a nice API for querying by public key fingerprint: "Who has 0xDEADBEEF?" => "@DeadBeef". Revocation, key updates, all that should be automatic: you revoke your public key and issue a replacement, all your services update automatically.
This is the point where lots of people will raise concerns about privacy: "This means Twitter now must have access to my GMail account! WTF?!". No. This process must be voluntary and optional. If you want to have 200 different identities online, go for it. I don't care to know your real name, I just care to know that I am talking only to the person I intend to talk to. Think emailing a well known developer on GitHub, having never met them. You don't need their real name, you are only interested in them in so far as they publish OSS on GitHub. This allows you to prove that github.com/example is @example on Twitter, example@example.com, example@gmail.com, and HN user "example".
And the benefit to "regular Joe" is that when he emails his accountant, he can now send his credit card number and SSN without fear of eavesdropping.
Addressing the Moxie Marlinspike post - PGP being flexible and comprehensive is not the problem. The implementations/libraries (including GPG) being a fossil from last century are.
From my own experience I can say that the libraries are not well designed - they couple things together (like key management and decryption) and make some things hard to do even if they are conceptually simple (like checking a signature without first building a key-ring data structure with all keys from a file).
Progress comes from many experiments, going in all kinds of directions in UI design, infrastructure building etc. You need a comprehensive fundations to base on these experiments on.
>You need a comprehensive fundations to base on these experiments on.
The problem is that people build this huge, powerful libraries, but nobody seems to write the "limiting" libraries that take a subset of the powerful base library and create an easy to use experience from the user.
I suppose this largely stems from "implicit knowledge": People who can write cryptography apps likely know enough crypto that they can't themselves identify usability problems.
Libraries are more powerful if they are decoupled. For example I wanted to build a website that would let you check message signature against public keyservers. This sounds trivial - but unfortunately the libraries that I've reviewed don't provide a 'check_sig( message, public_key)' function - but only a 'key_ring.check_sig( message )' function. This complicated the matter a lot - because I would have to download the public key and save it into a temp file and then build a key_ring out of that file (with some other complications that I don't remember right now). Enough to discourage me.
Huge does not mean powerful when it is hard to mix and match (and limit) the functionality.
we're using and contributing to openpgp.js and so far this has worked pretty good for us, because it provides a sane API, properly documented, coherent code style, CI tested. here's a snippet for decryption and signature checking in Whiteout Mail: https://github.com/whiteout-io/mail-html5/blob/master/src/js...
1) libraries are often too complex for the avg dev: well, crypto is complex and there is rarely a one-size-fits-all solution. however, there are high level APIs that address your issues in openpgp.js (https://github.com/openpgpjs/openpgpjs). problem is that a lot of people try to roll their own crypto if the library does not offer those high level #box() and #unbox() functions. and THAT is a real problem down the road.
OS X is also missing, isn't OS X a relevant platform?
Of course both are relevant, they just went for the most popular platforms first, plus FF OS, which probably was a kind of low handing fruit due to its HTML5 apps.
The main crux of this whole post is that PGP is still good it's just that it's hard to use and there's no mobile support. Unfortunately for whiteout, there are many different mobile PGP implementations that do everything these guys are planning to (like automatic key lookup) that already exist today. Notably among them K9 + OpenKeychain, which already support keybase.io and HKPS.
People who say that security is meant to be hard are missing the point, OTR has been around for a long time and is not only much more secure than PGP but more useable. If you want truly secure asynchronous messaging you should checkout Pond by Adam Langley, which is arguably the only traffic analysis and metadata resistant messaging protocol on the planet. Unfortunately PGP has been designed in a way that careful key management is pretty much a requirement if you want. PGP key verification is extremely painful on every implementation I've ever seen, and unless you do it you are vulnerable to extremely potent attacks which are the result of plaintext key sharing algorithms like HKP and LDAP.
I'm with moxie on this one, I get sad that people are still trying to build modern 'secure' architecture based on a ~20 year old cryptosystem. It sets everyone who cares about useable security back because you are continually encouraging people to cling on to the old paradigm. Unfortunately there is no clear, universal successor to the PGP kingdom... yet.
Is it possible to have a PGP-powered layer that requires close to no setup from the end user?
This seems to be the issue, and until the encryption is, in effect, totally invisible to the average person on the street, I'm not sure we'll see widespread deployment.
your no setup scenario would be when security is handled on the host, which is not really an option for email w/ PGP. if you want gmail to do your de/encryption, you might as well use what you currently have with TLS
Would you trust your life on a protocal such as HTTPS?
How often is https broken? It seems like every six weeks OpenSSL comes out with a new advisory full of vulnerabilities. I'm assuming that the world powers out there have zero days in OpenSSL, they attack SSL and VPNs all day long. People will be harmed if they trust HTTPS to secure their correspondence.
It is great that you're trying to give PGP a new life, but you're weakening it by using a vulnerable protocol with it. The weakest link will always break first.
Assuming you have access to your mail server to make the necessary configurations, wouldn't something like ciphermail's (https://www.ciphermail.com/) pgp /smime gateway make it easy for joe user to have encrypted email?
I've used it in my own setup and think it works quite nicely so far but then again I only have 8 people using it.
On thing that always wonders me. Assuming NSA or whatever spying agency is sniffing mail in the Internet, I'm pretty sure that once you use PGP, you are basically a strong suspect for them. Obviously the situation would be different if mail was encrypted by default, but now such people just stand out. Not sure if this is a situation I want to be in...
are you playing devils advocate? this is exactly why it's a good idea to use this stuff even for your normal everyday traffic, so that the ones that really need to use it don't stand out. same goes for pretty much every form of encryption.
your point is well taken, but it's not what we're discussing here. lots of people have written lots of essays about this :)
they have openly said that people who use encryption are of interest to them, or at least their communications are. however this is easily solved if there is wide enough adoption. If I encrypt the shopping list that I send to my other half, or I encrypt the text messages i send siblings or any text communication to anyone, and there are 100's of 1000's who do the same it becomes impossible to store/monitor and decrypt all that information. it would essentially overwhelm them with data, which even if they managed to decrypt (through the theft of private keys or a serious brute force attack) would be of no value other than to prove the task a waste of time.
I have Exchange/Outlook (w/Gpg4Win) at work and OS X Mail w/GPGTools) at home. I can't send GPG signed/encrypted emails between work and home. But I can with the S/MIME implementation built into Outlook (w/certificate from Comodo, hmmmm). Add-ons for email programs just don't seem to be the answer, at least so far.
Hi Tom,
gpg4win is really awkward in terms of compatibiltiy (beside other lacking features).
I exchange a lot of encrypted mails with different people - among them Apple users.
Take a look at gpg4o (http://www.gpg4o.com) which is my preferred solution.
1. I've really been very slow in letting people into Keybase. The wait time is still 6 months (last night I was letting in people who asked back in August.) But now that we've added HackerNews key proofs, I'll let people in today who notice this post who have more than 1 karma and write "I'm HN: {theirusername}" in the request form.
2. We're not just about PGP keys. It looks that way now, and our first goal was to help solve the very on-the-record type things developers do. Which mostly requires PGP - and PGP is very good at. Signing code and commits, releasing software, etc. But sometime soon each of your Keybase devices will have a device-specific Nacl key, for example. And the process for provisioning devices is something we're taking very seriously - we'll soon have a big blog post about how public sibling key announcements will work. Here's the foreshadowing: with a Keybase account, very soon you'll be able to start with something as simple as a Twitter or HN username, and do some very cool, secure things with files and messages.
[EDIT] We are hiring. There's no specific job page because we've mostly been reaching out to people quietly, but we want help building: the Keybase client (Go), iOS and OSX GUIS (Obj-C), and the site (front end development and back end (Node)). Please reach out to me (chris@keybase) if you like the idea of working on usable security software. We are currently distributed in NYC, SF, and CHI, and ideally you'd work with us in one of these offices.