Beautiful Code [154]
It really does help if the problem you're trying to solve is something that personally interests you. This not only makes it possible to flip between user and developer roles easily, but ensures you'll still be interested in the project five years later—because building and marketing a software application is generally quite a long-term proposition.
The development of Cryptonite has been powered in large measure by my desire to create tools to help individuals all over the world achieve practical liberty. And while developing the system single-handedly has been difficult at times, I find that being a single-developer project has also given the code a certain stylistic and structural unity that's rare in code developed by multiple programmers.
Secure Communication: The Technology Of Freedom > Untangling the Complexity of Secure Messaging
11.2. Untangling the Complexity of Secure Messaging
While bringing secure communications capabilities to the world is a whoppingly great idea for the protection of individual human rights (more on this later), getting it right is a trickier task than it may seem. Public-key cryptosystems can, in principle, facilitate ad hoc secure communications, but practical implementations are very often needlessly complex and disconnected from on-the-ground realities concerning who will use such systems, and how.
The fundamental problem to be solved in practical implementations based on public-key cryptography is key authentication. To send an encrypted message to someone, you need her public key. If you can be tricked into using the wrong public key, your privacy vanishes.
There are two very different approaches to the key authentication problem.
The conventional Public Key Infrastructure (PKI) approach, typically based on ISO standard X.509, depends on a system of trusted third-party Certification Authorities (CAs), and is in many ways fundamentally unsuited to meet the real needs of users in ad hoc networks.[] PKI implementations have achieved significant success in more structured domains, such as corporate VPNs and the authentication of secure web sites, but have made little headway in the real-world heterogeneous email environment.
[] The drawbacks of conventional PKI have been concisely summarized by Roger Clarke at http://www.anu.edu.au/people/Roger.Clarke/II/PKIMisFit.html.
The other approach is exemplified by the most popular public-key-based messaging security solution in use today: Phil Zimmermann's PGP and its descendants, now formalized as the IETF OpenPGP protocol. OpenPGP preserves the flexibility and fundamentally decentralized nature of public-key cryptography by facilitating distributed key authentication through "webs of trust" rather than depending on a centralized, hierarchical system of CAs, as PKI approaches do (including OpenPGP's primary competitor, S/MIME). Not surprisingly, S/MIME, which is almost ubiquitously available in popular email clients, enjoys a vastly smaller user base than OpenPGP, despite email clients' general lack of comprehensive support for OpenPGP.
But the web-of-trust approach, which relies on users to build their own chains of trust for certifying and authenticating public keys, has its own issues. Prime among these are the interrelated challenges of ensuring that users understand how to use the web of trust to authenticate keys, and the need to achieve a critical mass of users in order to ensure that any two users can easily find a trust path between each other.
As Figure 11-1 shows, in a web of trust implementation, no third parties are arbitrarily designated as "trusted." Each individual user is her own most trusted certifying authority, and may assign varying levels of trust to others for the purpose of validating keys. You consider a key valid if it is certified directly by you, by another person who is fully trusted by you to certify keys, or by a user-definable number