Beautiful Code [162]
The practical upshot of all of this is that cmaild can continue to use folders just as it did before, and stash decrypted messages in the shadow folder for the duration of a session. There are a few extra methods in Mail::Folder::Shadow to enable this, including update_shadow, which is used to save the decrypted message in the shadow folder; delete_shadow, used to delete individual shadowed messages at user request; and unshadow, used to delete all messages in shadow folders before session termination.
Mail::Folder::Shadow makes it possible to offer persistence of decrypted messages for a session and to implement search within encrypted messages—both essential features from a user's perspective, but rarely implemented in current-generation OpenPGP-compliant email systems.
Secure Communication: The Technology Of Freedom > Hacking in the Himalayas
11.8. Hacking in the Himalayas
Through 2000 and 2001 I was able to work on Cryptonite only intermittently, both because of other commitments and because the project needed peace and quiet, which was in limited supply when I was traveling around and living in chaotic, cacophonous, polluted Indian cities.
In the summer of 2002, my wife and I took a vacation in the Himalayas, where I finally managed to get the time to finish writing major chunks of the code, including adding important key management abilities to Crypt::GPG, and creating an integrated interface for key management, which is a critical part of the whole web-of-trust mechanism. The core of this management interface, the Edit Key dialog, is shown in Figure 11-5. It enables fingerprint verification, the viewing and creation of user identity certifications, and the assigning of trust values to keys.
I also ported the system over to OpenBSD, which would be the ultimate deployment platform.
We already had all the other major components for a secure email service in place, and as it would still take some time to get Cryptonite ready for public use, we decided to go ahead and launch a commercial secure email service right away. This would enable me to spend more time on Cryptonite development, and to begin building a community of testers immediately.
So in mid-2003, we launched the Neomailbox secure IMAP, POP3, and SMTP email service. In the following years, this proved to be an excellent move that would help fund development, freeing me from the need to take on other contract work and simultaneously keeping me in close touch with the market for secure, private messaging.
In the fall of 2003, we set up a semi-permanent development base in a small Himalayan hamlet, about 2000 meters above sea level, and this is primarily where development has progressed since then. This kept our cash burn low, which is critical for a bootstrapping startup, and gave me lots of time and peace to work on Neomailbox and Cryptonite.
Figure 11-5. The Edit Key dialog
Even though we had our share of trials working on mission-critical high-tech systems from a remote Himalayan village that was, for the most part, still stuck in the 19th century, the words of Nikolai Roerich, the prolific Russian artist, writer, and philosopher who lived in the same part of the Himalayas for many years, did to a large extent hold true for us, too: "In truth, only here, only in the Himalayas, exist the unique, unprecedented, calm conditions for achieving results."
11.8.1. Securing the Code
Originally the code was designed as a prototype, and I didn't worry about securing it too much. But as time to make the system available as a public beta came around, it was time to lock down the code with, at least:
Complete privilege separation
Paranoid input validation
Security audit of Crypt::GPG
Documentation of any potential security issues
Privilege separation was already built in from the ground up, by running