Wednesday, May 23, 2007

Crypto for Everyone: Scripting and truly transparent systems

The idea of writing tools using standard unix scripting facilities (e.g. sh, awk, sed) may seem like a exercise for idle minds, but it has certain qualities that may make it beneficial to the end user at large.

That benefit is transparency.

For example, consider a simple blowfish encrypt/decrypt application. There are dozens of implementations in C, Perl, Tcl, Python, Ruby, etc. But, each comes with a certain amount of baggage. For Perl, Tcl et al, you have to make sure you have the right version of the interpreter installed as well as the right libraries. With C and C++ you have to make sure you have the compiler on hand with the correct libraries (unless you are willing to install an opaque binary).

However, a blowfish application that is written using always available OS facilities (under the assumption that your OS comes loaded with standard GNU utilities) is both portable and transparent. A blowfish implemented in gawk and bash/sh is very transparent. The user can see what is going on and even make modifications. Beyond that, adopting the "unix way" could make the usage of such an application transparent: it operates as a typical unix filter command where you can use pipes (and redirection).

This is an interesting idea (to me at least). Download and you have an encrypt/decrypt solution (assuming you have gawk installed). Now, just use it. Pipe to it. Put it in /usr/local/bin (or some other convenient path) and use it as often as you would "cat" or "ls". It's not terribly fast, nor is it terribly efficient, but you can see what it does and can change it, play with it and make it do what you want it to.

This is all part of a copious free time deep thinking effort I've been up to. I am trying to figure out how to offer the simplest tools (simple in terms of installation, configuration and modification) to environments that lack such tools. It seems that everytime I (we?) think of an easy (usually GUI based) way of doing things, such as encryption, I (we?) get caught up in trying to provide the most sophisticated solution. Either that solution is never completed or simply doesn't "take".

Sure, has vulnerabilities (mostly regarding typing passwords on command lines and buffering decrypted output), but for most users who do not do encryption, this offers some level of protection.

Now, you could argue that most "users" don't know how to use the unix shell or simply don't use unix (MS Windows is used by most of the computing world). But, you could wrap in a BAT file or simply add a little more scripting to automatically encrypt samba mounted directories from a unix box (see my last post). This too sounds unsafe, but it is much safer than keeping your currently unencrypted list of credit cards, bank account numbers and passwords sitting around on a laptop drive.

No comments: