Previously, we reviewed Google’s Certificate Transparency efforts, and observed that while it does not prevent MITM attacks, it might detect at least some of them. We compared it to blockchains, and described what a Decentralized Public-key Infrastructure (DPKI), which uses blockchains, might look like.

Today we compare these approaches with two new systems: Key Transparency and CONIKS. Of these four approaches, we find that CONIKS and DPKI are the most promising and secure.

Our findings are summarized in the table below for easy reference.

Note: because the generic terms “certificate transparency” and “key transparency” can apply to various systems, we specifically reference Google’s particular implementations as “Google’s CT” and “Google’s KT”.

In the table below:

• ✅ — the system should have this property if correctly implemented
• 🤔 — the system might have the property under some circumstances
• ❌ — the system does not support this property at all

	Google’s CT	Google’s KT	CONIKS	DPKI
MITM-detection	🤔	🤔	✅	✅
MITM-prevention	❌	❌	✅ (*)	✅
Internet scalable	✅	✅	✅	🤔
Economically backed security	❌	❌	❌	✅
Censorship resistant	🤔	❌	❌	✅
DoS resistant	✅	🤔	🤔	✅

(*) MITM-prevention in CONIKS depends on novel zero-knowledge proof cryptography¹ that few have verified. Assuming it Works As Advertised, and assuming gossip is successful, and assuming a single entity does not control the server and all messenger implementations using it, it should be capable of preventing MITM attacks.

MITM-detection + MITM-prevention

• Google’s CT — As we covered previously, Certificate Transparency might detect MITM attacks after they occurred. We emphasize that this protection mostly applies to large businesses like Google who can afford to monitor the various logs out there for mis-issuance.
• Google’s KT — Although Google says that Key Transparency is inspired by CONIKS, the two systems are fundamentally different from a design and security perspective. In Key Transparency, the server is trusted by all users and manages their keys for them. Because of this, just like with Apple’s iMessages, client software cannot distinguish when they are being man-in-the-middle’d, or their software is simply being updated. It might notify the user of a new device, but most users (if not all) will be entirely unequipped to tell whether they’re being MITM’d.
• CONIKS — Assuming client software has not set a flag (that shouldn’t exist) to allow the server to reset the user’s keys, and assuming that the client software is able to successfully gossip with others, and assuming the system is not centralized (meaning, the server and all client software is not owned/controlled by one entity), then CONIKS should reliably detect and prevent MITM attacks.
• DPKI — Assuming a secure thin-client protocol is used to communicate with a blockchain, or assuming two randomly chosen independent servers are queried for a user’s key, DPKI should reliably detect and prevent MITM attacks.

IMPORTANT: implementations of DPKI and CONIKS must support decentralized key recovery to really address MITM attacks. The original DPKI document did not cover this as well as it could have.

Internet scalable

All of the described protocols should, when properly architected and implemented, be capable of supporting all Internet devices.

However, there is still a non-trivial amount of work that needs to be finished in order to scale blockchains—along with any namespaces within them—while maintaining their decentralization and security properties. Techniques that can help include:

• Off-chain transactions (e.g. Blockstack).
• Thin-client protocols. Namecoin still leads the way here.
• Sharding. Ethereum is doing great work here.
• State channels. Again, Ethereum leads the way.
• Zero-knowledge proofs, especially STARK (lecture).

Furthermore, there is still the adoption issue of users needing cryptocurrency to update blockchain data (unless it is subsidized by a company). It wouldn’t be difficult for new ISPs to come along that turn a portion of your monthly Internet bill into the fees necessary to perform these and other operations (such as micropayments for online content).

Economically backed security

Of the protocols mentioned, only blockchain/cryptocurrency-based protocols like DPKI have built-in economic incentives that attest to their security.

In other words, all of these systems could have bug bounties for discovering security holes in their implementations, but only cryptocurrencies have that bug bounty built into their very protocol.

There is little reward in compromising CONIKS compared to compromising Bitcoin. That massive incentive (approaching $17 billion) gives users a monetary reason to have faith in the system’s security.

Censorship resistant

• Google’s CT — Although Certificate Transparency appears to have the potential effect of centralizing the CA system, there are still many independent CAs today who will issue you a certificate in the DNS/ICANN namespace. And, even if a government seizes your domain, there are still many other TLDs that you will likely to be able to re-register your name under. Therefore, the overall system provides some amount of censorship resistance through the existence of its many namespaces. However, within any single namespace, there is no censorship resistance.
• Google’s KT — In Key Transparency, a single server is responsible for controlling one or more namespaces. This centralized design means it offers no censorship resistance.
• CONIKS — Like Key Transparency, in CONIKS a single server will have total control over a namespace, and therefore it too provides no censorship resistance.
• DPKI — In DPKI, each namespace exists within a decentralized database managed through consensus by independent entities, with money on the line should they misbehave. This decentralized design means the system provides users real data ownership, and therefore extremely robust censorship resistance.

DoS resistant

• Google’s CT — Because there is no consensus on what the DNS/ICANN namespace actually is, certificates can be logged in any one of many logs. If a DoS attack (or otherwise) takes down a log, only the certificates that were registered with that log will be affected, and only if they weren’t registered in other logs. Since a certificate can be registered with multiple logs, the system is reasonably resistant to DoS attacks.
• Google’s KT and CONIKS both represent centralized namespaces. Whether they’re capable of withstanding a DDoS attack depends entirely on the infrastructure of the centralized entity running those servers.
• DPKI — A namespace within DPKI (typically) exists within a blockchain, which is powered by a global network of independently run nodes. The decentralized nature of the system means permission is not required to participate in this network. Anyone can spin up a node, and therefore it doesn’t matter if one goes down, there are thousands more you can count on to secure the same exact namespace(s).

Potential DPKI Implementations

Many players are starting to appear in this field, but two promising candidates (whom we hope to evaluate for compliance at some future date) include:

• Blockstack (Bitcoin)
• uport (Ethereum)

Thanks

Thanks to the CONIKS team for answering our questions, to the Key Transparency team for their helpful documentation, to Simon Grondin and Andrea Devers for reviewing drafts of this post, and to you for reading.

You can follow the author and okTurtles on twitter.

Donating = Loving!
Writing these posts takes time and money!
Please support our work by donating.

Footnotes

1. Thankfully it does not use a trusted setup. See Appendix A of this CONIKS paper for details on the VRF used for the proof. ↩