Here's my view. I recently wrote an article on my blog (http://ledgersmbdev.blogspot.com/2013/06/tangent-design-thou...) which was on the front page of HN for a while. I want to summarize both my thoughts again and things that have occurred to me after writing it.
All of our existing key interchange systems are amazingly brittle. With X509, there's no reason to assume the NSA couldn't order verisign to produce a certificate for any given individual or site which they could then use to orchestrate a MITM attack. Purely synchronic protections (i.e. focused exclusively at the moment of exchange) are obsolete in my view. Similarly purely diachronic protections have problems too, and often aren't well implemented. Suppose you need to rotate ssh host keys. This becomes a problem. I think we need something a lot better.
Regarding PGP, the question is what they can break. Could they get a court order to force MIT to help them present that your key on their directory is visible to you but their key is visible to everyone else (allowing them to step in between and conduct another MITM attack of another variety?
Even if you add endorsements (web of trust model), how easily can that be attacked? It might be harder but not that much harder.
So my thinking is this. Start with a standard PKI model and extend it to require evidence of continuity. The assumptions required to do this are:
1. No external authority issues private keys, and
2. You must retain and continue to use an old private key for an unspecified transition period (possibly spanning several keys). This shows a chain of issuance, and evidence that the same entity controls the same internally issued private keys over time.
So suppose you define a transition period of 2 years and a key rotation period of one year. This means that anyone you have been in communication with over the last three years will be able to check that the continuity of key possession has not changed, and three keys would have to be compromised to force a certificate believably (two of those keys can be stored somewhere else and only used for the certificate resigning process) If a MITM attack starts, anyone who has been in contact in that period knows instantly that something is wrong. Newcomers get alerted when the MITM attack stops.
I would recommend looking into what we can do to implement a system like that. I am thinking of trying to write it up as an RFC and submit it to the various bodies.
Put a better interface on GPG to make managing web-of-trust not a nightmare. The infrastructure has existed for a long time, but using it is amazingly unfriendly.
It gets more interesting when you consider a model like off-the-record encryption, where the goal isn't encryption and verification but deniability. OTR has the great property of ensuring that any time you manage to decrypt or intercept a message, you've also received all the information necessary to forge that message. Identifying keys are transient so you can never really prove any individual, sent any message since if you hold a copy of the message you could just as easily have faked the message.
I wish there was a site to connect open-source projects who need better UIs with the designers over at Dribbble. On Dribbble you see a lot of UI concepts that never come to fruition. What if we could convince some of them to help build a better PGP UI? After all, real world applications look much better on a resume than concepts.
We've tried to write a streamlined UI for GPG keysigning parties in university. The CLI of gpg was absolutely hostile. Fatal errors would still have 0 as the exit code etc... :(
As a designer, throughout this entire scandal I've been wishing for the same thing. I assume there are projects out there that I can contribute design thinking to, but I honestly don't know which ones need it or would welcome it.
Putting a better UX or UI has been considered for PGP/GPG a very long time, and if you really reflect on that topic, you'll learn that a fancy interface or UX won't solve anything.
Foolproof software is operated by fools. Facebook has only proven that to an extent that you simply can't deny it anymore.
If fools use PGP/GPG, they will compromise you by putting the message in the subject and encrypting their disclaimer/footer.
OTR uses, iirc, AES and DH-kex, that are the same basic building blocks like RSA and AES or any other symmetric cipher you like to use for PGP/GPG/SSL. OTR adds deniability which is fancy for privacy but won't do for other scenarios (like business, money, profit), it works fine in one to one sessions, but group sessions are off the record.
We can conclude that OTR is fine for chat, sorry to hear google dropped the interoperability protocol in hangouts, take a wild guess why.
PGP/GPG can sent to group-messages (one message encryped for multiple recipients and may optional provide proof of the sender), does not imply any protocol like XMPP, and stores messags in a secure manner too. The drawback is, you have to take care of your private-key and your friens, partners, business-associates public-keys.
If somebody really inists that key management sucks with GPG/PGP let them do some key management and distribution only with a symmetric cipher.
Key-Managment with PGP/GPG is a light, soft breeze compared to that. Some people even used it as an excuse to party.
I understand why people have dropped privacy and anonmyity, it is no fun to follow procedure and there are so less benefits compared to every other social media app, it is so comfy to state you have nothing to hide and not care about the implications.
With PGP/GPG you won't have 600 friends, that means caring about 600 keys, that is basically one revoke a week if you are lucky and all you friends master crypto and revoking and getting their new key signed.
If you want to understand a bit crypto it may take a good tutor to teach you the very basic concepts and history of using crypto within 2 schooldays, 16h (and they'll hate you afterwards and they won't pay that).
I agree with this, but would also point out that the problems I am addressing though can't be solved by a better user interface. In addition to the issues you describe you also have the question of key infrastructure. Key servers are not adequate as they are, and so IMO you need to have ways of verifying the key is legit, which are not included in the PGP model.
That key infrastructure is something which needs to be thought out and made resistant to a single party tampering with things.
Key infrastructure doesn't even emit security anymore. The P in PKI is for painful, and I really doubt that some CA, owned by big corporate entity (microsoft, oracle, ca) wouldn't manipulate the eternal append-only log-file for any given human factor and just re-roll it.
There is no benefit in auditing it permanently, like rewarding auditing with payment in bitcoin.
A given conglomerate CA would just revoke and reissue client/customer certificates for some reason and that eternal append log-file gets a short restart and everything is fine again, because of OOPPS compromise.
No CA ever, would host a eternal append-only log-file where you can simply point at and tell: I told you so.
It is simply beneficial for any CA to deploy compromising evidence, just in case, of OOPPS compromise. You sure know whom to blame.
It is not beneficial for a given CA (usa) to allow any other CA (china) to forever store their certificates and make you pay for it.
There is no benefit in eternal log-hoarding for PKI, and they make you pay it.
There is no benefit in it for customers even, because you cant even store that log, retrieve that log or even process it as an individual.
I am at a point where I would try web of trust with unicorns, raindows and flying cats before trying again and again with PKI by taking something from virtual currencies and attach it to PKI. Certificate Transparency is like Chrome, it is not build to let you or me delete, or remove CA-Certificates, we may dislike for any given reason, or just because we can.
I am at a point were I really conclude that taking away certificates or keys and delegate them, is the worst idea ever.
Certificate Transparency is baiscally the same wet-hot idea as in 1994 with PKI:
PKI, nearly twenty years ago: In the perfect PKI world imagined by netscape, there would be no war, only love, because secrets would stay secrets forever and the NSA would still chew on their first intercepted message.
Reality check please.
CAs have proven not to be reliable trust providers. It is so easy to find the weakest CA and attack and compromise it.
Certificate Transparency won't change that, its not even beneficial for CAs.
So lets try web of trust, it hasn't failed us yet, it just wasn't sexy enough. May we need that P in PKI pain to gain something after 20 years.
Imagine certificates trust-validated from your nerd friend, facebook group, google circle, 4chan, whom you trust, ymmv.
Everthing is better than certificates from the folks that hold your browser, operating system, data, e-mails or docments hostage and make you pay for some binary data blob and logging their failures.
1. Ensuring that the key belongs to the person you think it does.
2. Graceful changing of keys.
In theory you could do something like what I am proposing with GPG too. You could sign a public key with the previous private key or two. In practice, getting the keys to where you want them is a bit more complex.
As a point I made clear in my blog entry, I am not a fan of X509, because the impedance mismatch of anything OSI and TCP/IP is significant. However, it does a decent job, when combined with LDAP (another monster IMHO) of spelling out the general solutions to problems PKI's suffer. It is therefore a useful reference point and probably the best foundation to build a decent proof of concept on.
I think the problem is the one you're inadvertently recreating here: you're trying to imagine a system which is perfect amongst people who are always in isolation with each other and tries to make keys as perpetual as possible.
Consider the alternative: social keying. A system where the expectation is that you'll change keys frequently, taking advantage of day-to-day social interactions and the like to do so. I see a friend, our phones are in proximity - software takes advantage of this and generates and signs a new key.
Of course, this is where the whole "metadata" issue really crops up: those awesome secure keys, to work, still timestamp and identify you perfectly.
All of our existing key interchange systems are amazingly brittle. With X509, there's no reason to assume the NSA couldn't order verisign to produce a certificate for any given individual or site which they could then use to orchestrate a MITM attack. Purely synchronic protections (i.e. focused exclusively at the moment of exchange) are obsolete in my view. Similarly purely diachronic protections have problems too, and often aren't well implemented. Suppose you need to rotate ssh host keys. This becomes a problem. I think we need something a lot better.
Regarding PGP, the question is what they can break. Could they get a court order to force MIT to help them present that your key on their directory is visible to you but their key is visible to everyone else (allowing them to step in between and conduct another MITM attack of another variety?
Even if you add endorsements (web of trust model), how easily can that be attacked? It might be harder but not that much harder.
So my thinking is this. Start with a standard PKI model and extend it to require evidence of continuity. The assumptions required to do this are:
1. No external authority issues private keys, and
2. You must retain and continue to use an old private key for an unspecified transition period (possibly spanning several keys). This shows a chain of issuance, and evidence that the same entity controls the same internally issued private keys over time.
So suppose you define a transition period of 2 years and a key rotation period of one year. This means that anyone you have been in communication with over the last three years will be able to check that the continuity of key possession has not changed, and three keys would have to be compromised to force a certificate believably (two of those keys can be stored somewhere else and only used for the certificate resigning process) If a MITM attack starts, anyone who has been in contact in that period knows instantly that something is wrong. Newcomers get alerted when the MITM attack stops.
I would recommend looking into what we can do to implement a system like that. I am thinking of trying to write it up as an RFC and submit it to the various bodies.