Beautiful Code [156]
The UI's Key Ring view, illustrated in Figure 11-2, shows the validity of all user identities for each key, both in text and by color-coding. It also shows the key type, using icons, and owner trust values for each key (both in text and by color-coding). Full details for any key are available through the "edit" link for the key.
Warnings and feedback about security implications of user actions
Giving users the power to manage keys brings the risk that they will use their abilities in ways that weaken the security of the system. So, it is also the application's job to educate the user about security implications of actions such as certifying a key, altering a key's trust level, or signing a message.
All screens in Cryptonite that allow for actions with security implications contain short, highlighted warnings about these implications. And they're right on the same screen, not in irritating pop-up boxes.
Figure 11-2. The Key Ring view exposes information on keys and trust
Built-in associations
Cryptonite's concept of a user's identity is strongly tied to the private keys in the user's key ring. When sending mail, users can use any "From" address that corresponds to a private key in their key ring. This helps the user grasp in an intuitive and inescapable way the idea of a private key. Public keys can be tied to contacts in the user's address book, so they can be picked up for automatic encryption whenever available.
Full-featured email client
Cryptonite is primarily an email client that just happens to have complete support for OpenPGP-based security and key management built in. An important usability goal was to provide the user with a full-featured email client without letting the security functionality get in the way of its usability for email. This required not only providing the full range of features a user would expect to find in an email client but, most significantly, enabling users to search through their mail folders, including text within encrypted messages, without much more complexity than a regular email client where all messages are stored unencrypted.
Secure Communication: The Technology Of Freedom > The Foundation
11.4. The Foundation
Application software today, of course, is many levels removed from the bare hardware and builds on top of many layers of existing code. So when starting a new project, getting the foundation right has to be the crucial starting point.
For a number of reasons, I chose to write Cryptonite in Perl. The rich pool of open source reusable modules on CPAN (http://www.cpan.org) helped minimize the need to write new code where existing solutions could be leveraged, and also allowed a great deal of flexibility in interfaces and options. This was borne out well by prior experience with the language as well as by later experiences with the Cryptonite project.
The ability to interface to C and other libraries through Perl's XS API allowed access to even more libraries. Perl's excellent portability and robust support for object-oriented programming were other important advantages. Cryptonite was intended to be easily modifiable by licensees, which would also be facilitated by writing it in Perl.
So, the Cryptonite system is implemented entirely in object-oriented Perl. The project has led to the creation of numerous open source Perl modules, which I have made available on CPAN.
GNU/Linux jumped out as the obvious development platform, because code developed on a Unix-like environment would be easiest to port to whatever deployment platform it would be used on, which could only be another Unix-like platform. No Windows or Mac system at the time (OS X was in pre-beta) had what it took to run mission-critical software to be used concurrently by thousands of users. Linux was my preferred desktop environment anyway, so it was also the default choice.
In 2001, development and deployment moved to OpenBSD, and since 2003, development has proceeded