UrlBlogGrey

I've long been a proponent of using public-key cryptography to secure e-mail communications with digital signatures and encryption. For many years there have been messaging standards to ensure compatibility among e-mail clients when sending and receiving messages secured with public-key cryptography. So, why is it that in 2007 we are still not securing e-mail communications? Do people have a lower expectation of privacy? Are the tools that facilitate public-key cryptography too difficult to use? All of these issues are real, and I think they can be overcome through the careful application of public-key cryptography in all messaging systems.

The S/MIME messaging format allows for a digital signature and public-key to be included along with a plain-text or encrypted e-mail message. The S/MIME protocol was established in 1995, over 12 years ago. At that time, the predominant method of sending and receiving e-mail was with stand-alone e-mail clients, such as Netscape Communicator, Eudora, and Microsoft Outlook Express. Fewer people had access to the Internet in comparison with today. Instant Messaging was also not as popular as it is today, so e-mail was more heavily utilized than today.

S/MIME messaging was available in many of the e-mail clients available in the late 1990's, and is available in most of the popular e-mail clients in use today (Thunderbird, Outlook, Mac Mail, etc). However, a large amount of personal e-mail is handled through hosted web-mail services, such as Google's GMail and Yahoo! Mail. The appeal of these services likely comes from the convenience and reliability they offer. While in years past people may have had Internet access only at home or work, they now have Internet access from their phones, at coffee shops, and on mass transit systems. It's desirable to be able to access one's e-mail wherever the Internet is accessible, and to have an e-mail account that remains the same despite changes in one's ISP at home or work (i.e. switch from AOL to Comcast). But one shouldn't have to compromise the security of their communications in the interest of accessibility; for example, I can securely access my online banking services from any location with Internet access, but I don't (usually) jeopardize the security of my accounts by doing so. Also, I could switch companies used to host this domain (urlgrey.net) without negatively impacting my e-mail service.

So, if S/MIME has been available through stand-alone e-mail clients since the mid-1990's, why isn't it available in web-mail systems today? In my opinion, it's due to the web-mail provider's interest in reducing their culpability in the event that their users conduct illegal business using their services. There is no technical barrier preventing the web-mail providers, such as Google or Yahoo!, from providing e-mail communiques to the U.S. government or to other businesses. What's more, it's possible for e-mail to be tampered with while in transit or archival since there isn't a digital signature to guarantee message integrity. It's also possible for the e-mail message to be tampered with between the web-mail system and the end-user since most web-mail services don't maintain an HTTPS connection throughout the session. Recent publicity of telecoms providing warrant-less wiretaps as part of the U.S. government's electronic surveillance program offers a frightening example of how businesses can be coerced into divulging information about their customer's activities while bypassing the legal system.

My recommendation is that people use standalone e-mail clients that support S/MIME. This will provide greater security for your messages, and will provide less opportunity for your messages to be misused or tampered with. It may not be as convenient as web-mail services, but preserving one's identity and right to confidentiality ought to trump convenience.

Posted by Scott at 11:07 AM | Permalink

Spammers have really caught on to the phenomenon of posting junk-comments in Blogs. I typically wouldn't care much since the volume of junk-comments was low enough that I could clear them out on a monthly basis. I think it's only been a few weeks since I last cleared the junk folder out, and today there were a total of 3,298 junk comments being stored on my web-server. Ridiculous. The disk quota for comments is the same as my disk quota for incoming e-mail messages. I hate to think that incoming e-mails are being rejected because junk Blog comments caused me to exceed my disk quota.

So, for the time being, I've disabled all commenting-facilities on my blog. I'm in the process of looking for a good Captcha plug-in that works with MovableType. If you know of one, please e-mail me!

Posted by Scott at 4:20 PM | Permalink

Everyone's got a blog these days, and my wife, Natalie, is no exception. She recently started a blog at puhmeow.blogspot.com. She blogs about the Internets, cute stuff, and more. Check it out!

Posted by Scott at 9:07 PM | Permalink

I heard an episode of the American Public Media "Futuretense" Podcast in March regarding the launch of a new music trading website called LaLa. What sets LaLa apart from network-based file-sharing systems like Napster or Kazaa is that LaLa participants obtain legal rights to new music by forfeiting legal rights to CDs in their existing music collection. To get new music using LaLa, you must indicate which CDs you own and would like to trade, along with which CDs you'd like to receive. LaLa then connects you with someone else who would like one or more of your CDs. Upon shipping your CD, one or more of the CDs you'd like to receive will be sent. The fee for this kind of transaction is just $1.00, plus $0.75 postage. And, $0.20 of each trade goes directly to the artist. Typically, artists receive nothing from sales of used albums.

I decided to leverage my 200+ CD collection by trading some of my less-played and less-loved CDs by creating an account on LaLa last Wednesday. So far, I've sent 5 CDs, have received one CD, and am expecting 5 more CDs to arrive soon. It seems like a cool system, though there are some areas that ought to be improved. Most notable is the order in which CDs from the "Want List" are sent: semi-random. Once I've sent a CD out, a CD from my Want List will be sent to me, but I have no control over which one. There are over 40 CDs on my Want List and I have no idea which will be sent in the near future.

Also, it's not made clear how to deal with album artwork that's difficult or not possible to ship. Most users indicate that they would like to receive album artwork; however, artwork is sometimes not included or is integrated into the CD packaging. It sucks having to throw away a nicely designed CD case because it can't be sent along with the CD in the pre-formed LaLa envelope.

So, LaLa seems like a good deal and is an interesting business venture, but there's a lot of work to be done in improving the process for users of the service. I'll continue to test out the service for a few more months to see if the time spent has been justified.

Posted by Scott at 8:47 PM | Permalink

Keeping computers cool is a problem that's existed for decades, and doesn't appear to be ending any time soon. High-density CPUs and integrated circuits can generate a lot of heat, typically in proportion to the processing load imposed on them. Because the processing load can vary sometimes unpredictably, it's a good idea to have a cooling solution that keeps your computer components cool in all situations.

I've got a Pentium 4 3.0 GHz PC running Fedora Core 6 that I use for remote access to our home network via SSH & VNC. The computer case sits in a coat closet with very little ventilation. This is good for us in that it blocks that computer noise from being heard throughout the apartment. However, it can contribute to an overheating situation depending on the inside temperature and the computer's processing load.

I recently noticed that the internal temperature on the PC was around 130 degrees Fahrenheit. This is within the tolerances of the Intel P4 CPU; however, I'd like to keep the temperature closer to the room temperature for the sake of safety.

So, I went to Fry's an bought an Antec Super Cyclone fan that installs in two card-expansion ports. It has 3 fan speeds (I'll keep mine on High), and effectively moves air from the inside to the outside of the case. Previously, I just had a case fan blowing air around inside the case, but no means of getting that air out.

After completing the hardware work, I then moved on to the software side. I installed the lm_sensors package by running the usual yum install lm_sensors. I then configured lm_sensors by running /usr/bin/sensors-detect and added the recommended lines to my /etc/modules.conf and rc.d files.

After restarting, I was able to see the status of my CPU and fans (but not the new Antec fan, it's not powered off the motherboard). Here's some output from running /usr/sbin/sensors -f:

fan1:     2393 RPM  (min = 30681 RPM, div = 4)

CPU Fan:  2596 RPM  (min = 2616 RPM, div = 4)

fan3:        0 RPM  (min =   66 RPM, div = 128)

M/B Temp:    +86°F  (high =   +16°F, hyst =   +55°F)   sensor = thermistor

CPU Temp:  +97.7°F  (high =  +176°F, hyst =  +167°F)   sensor = thermistor           

Everything is looking good!

Posted by Scott at 10:31 AM | Permalink

One of my favorite uses of the Internet is to look up product reviews and how-to's. Unfortunately, discovering such information is difficult using traditional search engines such as Google because they cover such a broad range of content sources. They cast such a wide net that it's difficult to narrow results with search terms alone.

Online retailers typically do not offer the objective, in-depth reviews that I'm interested in. This is why I love searching blogs. But searching blogs with the main Google engine is tough since search results for blogs are chaotically intermingled with those from retailers.

So, I often use the Google Blogs Search and Technorati engines to identify content coming from blogs. They offer a window onto the personal side of the Internet. I think that it's the left-field commentaries published through blogs that those opposed to Network Neutrality would love to squash.

Posted by Scott at 12:01 AM | Permalink

Since upgrading from a dial-up connection to a broadband connection, I abandoned the practice of keeping copies of software freely available on the Internet. This includes applications like web browsers, e-mail clients, and similar tools. My reasoning was that it's easier to download the most current copy of an application if I need it in the future because a new version will probably be released by that time, storing the program can be expensive and tedious (where do I put it?), and high-speed connections can download a 10 megabyte file in a couple of minutes. So, why keep local copies of such tools? Let it exist in the ether like any other piece of the Internet infrastructure.

Unfortunately, software applications are not immune to motives of business-minded individuals. I recently needed to download the XCode IDE for Mac OS X in order to conduct Java development on my Mac at work. The Mac uses OS X version 10.3, which is not the most current release of the OS (10.4). The most current version of XCode (2.4) works only on 10.4 systems, which mine is not. I expected to find a link to the 1.5 release of XCode for 10.3 systems, but found none. Fortunately, I remembered having stored the 1.5 release of XCode on a CD in April 2005, and had the CD conveniently located in a CD wallet in my briefcase. So, I used my backup copy of XCode and was in business. But had I not kept a local copy of XCode 1.5, I would have been screwed.

So, why might Apple choose to not make XCode development tools available for older versions of it's operating system? My suspicion is that Apple is forcing developers to build products for the most current version of it's OS, and carries this out by pulling development tools for older OS releases out of circulation. If this is their goal, then I believe they have been successful so far.

Relying on the ether to be storage medium for infrequently-used files such as application installers makes a person vulnerable to the software vendor's release and support schedule. Since disk space is cheap and broadband connections are nearly ubiquitous, it's like having an enormous storage pantry with a convenience store located next-door. Do you stockpile food in the pantry, or run to the convenience store anytime you need an item? These choices represent a double-edged sword that is tricky to handle.

Posted by Scott at 4:14 PM | Permalink

My wife has the luxury of working from home which permits her to set-up camp on the couch with laptop and cell-phone. I imagine it's a comfortable place to sit, though it lacks the organizational features of a traditional office desk. While browsing the MAKE Blog, I came across a really interesting design for a coffee table that includes a hinged tabletop that can extend up-and-out to a person seated on an adjacent couch. This allows the coffee table to serve multiple roles, thus saving cost, space, and preserving the casual appearance of a living space.

Posted by Scott at 3:11 PM | Permalink

A security vulnerability was discovered in the RealVNC software in mid-May 2006 that exposed a means of bypassing the authentication step while connecting to a RealVNC server. VNC is a network protocol that allows multiple clients on a network to remotely interact with a computer running a VNC server program, such as the RealVNC software affected by the vulnerability. Being able to avoid authentication means that anyone might be able to connect to a computer running a RealVNC server, regardless of whether they have the authority to do so.

There are a lot of programs that handle authentication in an insecure way; however, most of these programs rely on secure transport protocols (i.e. SSL) to keep the authentication credentials safe while in transit. However, this vulnerability means that even if you tunnel the unencrypted VNC traffic through a secure channel (i.e. an authenticated SSH session), the VNC server is vulnerable if the port it's listening on is open to the public. This vulnerability can be patched by operating a firewall on the machine and exposing only the SSH port to the public. Once authenticated using SSH, a client can tunnel their VNC traffic to the VNC server port on the same machine from behind the firewall (over the loop-back device).

This vulnerability is pretty serious, but I think that it provides a good incentive for people to follow better security practices when using VNC servers. The value of firewalls and SSH cannot be emphasized enough.

Posted by Scott at 8:43 AM | Permalink

Recently, I've been working on a problem similar to the following: a client accepts a digital certificate associated with a piece of remote code (ActiveX, Java Applet, etc.) The code signed using the certificate might be designed to do something benign like download weather information to the client's web browser. Sounds harmless. But what if a malicious party takes the remote code, leaves it intact, serves it to a client who has accepted the certificate, and then tricks the remote code to download to the client's system something other than weather information - say, spambot software? This produces an outcome far different from what the user had in mind when they accepted the digital certificate to view their local weather.

The problem here is that digital certificates are rarely restricted to a specific operation. The client can't say "Yes, I trust company XYZ, but only to download weather info." Rather, they can only say "I trust company XYZ." In this sense, the trust relationship is very ambiguous. As an analogy, I trust my auto mechanic to work on my car, but I don't trust him to prepare my taxes.

Computing applications, particularly those that are networked, need a more precise method of defining and restricting trust. The consequences of not doing so can lead to horrible surprises for software vendors and customers as they begin to see their trust relationships exploited by people with malicious intentions.

Posted by Scott at 1:52 PM | Permalink

Plug-ins extend the capabilities of Movable Type when formatting and associating entries in a site. I've been looking for a plug-in to format Java source code that I occasionally post on my site, since source code can often be difficult to read without language-sensitive formatting.

While browsing the Movable Type plug-in directory, I came across the MT Colorer plug-in. It uses the colorer library for the Perl scripting language to format designated sections within a Movable Type entry. Perl is the language that the Movable Type software is written in, so the MT Colorer plug-in takes advantage of other facilities within Perl to make text formatting simple.

The MT Colorer installation was simple, though I had to download and install the Syntax::Highlight::Universal Perl module that's required. This was possible only because I have shell access to my web hosting provider and know the machine architecture (Linux x86) used by the web servers. People without shell access must request that their hosting provider install the module if it is not already present.

Once the installation was done, I reformatted several of my previous posts and have been pleased with the outcome. As with all Movable Type plug-ins the work is performed at the time of publishing, so all content is rendered up-front. Here's an example, in the form of a simple Hello World! Java class:

public class HelloWorld
{
  public HelloWorld () { }

  public static void main (String [] args)
  {
    System.out.println("Hello, World!");
  }
}

Posted by Scott at 9:25 PM | Permalink

Really Simple Syndication (RSS) has had a profound effect on my life in a fairly short period of time (about 1 year), and has probably impacted many more people in a similar way. RSS makes tracking blogs, news stories, e-mail, and podcasts easy and automated. And it's really a wonder that nobody thought it sooner.

RSS falls into the "meta-data" category - it is data about data. The information an RSS document contains varies, but there are a few constants:

a list of records, each containing:

• a date/time


• a title or subject


• a Uniform Resource Locator (URL) where the entry can be accessed via the Internet

Most people read RSS entries chronologically. They know the date/time when they last read the RSS "feed", and want to know if any new entries have been added since then. This is a very easy request to fulfill. Instead of constantly polling your inbox or your friends blogs, you can use an RSS reader to check the status of them all in a single glance.

Software can automate this task, and poll the feed at any interval you want. This isn't as easily done with traditional information sources. Consider a department store: there is a ton of meta-data sitting idle that could be tapped in ultra-valuable ways. Imagine an RSS feed for the newest additions in your favorite clothing department, or a listing of the most recent sales promotions, or a listing of the most recent transactions for the store manager. All of this information is available but is not organized and processed in a unified way. I think that RSS and similar technologies have the ability to bring all of that information to those interested in a simple, convenient medium.

Posted by Scott at 9:23 AM | Permalink

Last Sunday, I installed the OpenWRT firmware on our Linksys WRT54GS Access Point. It's pretty sweet, especially since there is a large assortment of software available to run on this little consumer device. Because the Access Point is on 24x7, I figured it might be useful to have it turn on our other computers using the Wake-On-LAN (WOL) feature present in most Ethernet cards these days. The system I had in mind was the Linux box stuffed in the closet. I typically press the pow-pow button every morning, except for those mornings on which I forget and have to ask Natalie. Per usual, I decided to spent 4 hours automating a task that takes 5 seconds.

The Linux box includes the Asus P4C800 Deluxe motherboard, which has a built-in 10/100/1000 Ethernet adapter. Since the Ethernet adapter already works well in Linux, I figured it would just be a matter of configuring the card to generate a Power Event when it encountered the appropriate WOL Magic Packet (yes, that's the correct term). I issued the following command as 'root' to configure the Ethernet adapter:

ethtool -s eth0 wol g

I was able to confirm my changes by again invoking 'ethtool':

ethtool eth0

I then learned that WOL settings are only active for one boot-cycle. So, after configring the adapter using ethtool and powering-down, the computer should respond to WOL and boot but then need to be reconfigured using ethtool. This wasn't a huge hurdle since I could easily create a script in the /etc/init.d directory to automate the ethtool command during boot-up.

But WOL didn't work. It simply did not work. I googled the problem a bit and learned that the Ethernet NIC in my motherboard is not well-supported by the stock Linux driver. I even went so far as compiling a custom kernel with the vendor driver, but had no luck. It looked like WOL was a wash.

So, I went with the old-school solution of configuring the BIOS to generate a Power Event at a pre-determined time every day to start the system, and a CRON job in Linux to shut-down the system at the end of the day. Total time spent on that solution: 15 minutes. The joy experienced in fooling with NIC, kernels, and Linux: priceless.

Posted by Scott at 9:04 AM | Permalink

About a year ago, I installed OpenBSD on my spare PC and opened up a hole in our residential firewall to allow SSH traffic from the Internet to pass to the BSD system. My goal was to be able to securely access the BSD system from Internet-accessible systems, such as from work or on the road.

SSH (Secure Shell) is an Internet service suitable for controlling computers remotely through a text-based console. It can also be used to tunnel traffic for other services the the secure channel it establishes between the client and server machines. The SSH service I was running on the BSD system was now open for business, which meant that anyone, including attackers, could access the machine at any time and from anywhere.

I didn't expect to be the target of automated-attacks, but within a matter of hours a couple of machines located in Brazil began a brute-force dictionary attack on the SSH service. The attacks continued for as long as the service was left accessible through the firewall. I kept the BSD system running for a few more days, and then discontinued my experiment mostly due to a loss of interest. Still, the intensity of the attacks left an impression on me.

Recently I opened a hole in our residential firewall to allow external access to the SSH service running on a Linux box I own. However, this time I chose to expose the service on a different Internet port, one not typically used for SSH. A simple port-scan on the firewall would reveal the open port, but it wouldn't be obvious that the port was being used by an SSH service. Surprisingly, there haven't been any attacks launched against the machine since using the non-standard port. Running a service on a non-standard port does not improve the security of the service, but it dramatically reduces the obviousness of the service to people who have no business knowing. If someone else requires access to the SSH service, I can simply inform them of the port number on which it is running.

Posted by Scott at 11:20 AM | Permalink

I heard a segment on the KUOW show "The Works" about the role of web-based Wikis in the growing popularity of online collaboration. A Wiki is a great way for multiple parties to asynchronously contribute information and ideas to a shared, outward-facing medium. They differ from Blogs in that Blogs are usually maintained by an individual, while Wikis are cooperatively maintained by a group with the occasional involvement of editors.

I had experience with Wikis when working for a start-up company in 2004. The engineering team was geographically-distributed, so it was incredibly valuable to have a Wiki server as a global repository for information that could be accessed via the Web. It was most effective because we were dealing with "hard", factual data. There wasn't much need for an editorial role since the data posted to the site was hard to dispute.

Many Wikis aren't so factual; or, if they are fact-based, the facts can be interpreted in many ways (such as with the edit-wars that occur on Wikipedia). So, an editor might be needed in order to provide direction and stability to the collaborative work occurring on the Wiki.

Some people wonder if the popularity of Wikis and group-think is heralding the end of the autonomous, lone writer. I don't think so. Collaboration through a Wiki is appropriate when direction among a group is required. When a person's goal is to simply express their opinion with the non-essential goal of interesting or persuading others, writing a Blog or individual column is perfectly fine. I think that individual authors might serve as a catalyst for Wikis. You don't know the popularity of a topic until you begin to see a lot of individuals expressing interest in it. Once the topic is recognized as important, discussion can be facilitated using Wikis. Blogs and Wikis are hardly mutually-exlusive; instead, they go hand-in-hand.

Posted by Scott at 9:45 AM | Permalink

I've got a PC running the Fedora Core 5 distribution of Linux. Running the Secure Shell (SSH) daemon and VNC servers on the machine turns it into a wonderful terminal-server. The distribution of VNC that I use is RealVNC, developed by a team at AT&T. I could use TightVNC, which features better compression characteristics, but I've experienced weird display behavior with it in the past and prefer RealVNC's stability.

When using my PC from work, I use the RealVNC client to access any of my RealVNC servers and always experience excellent performance. I should also mention that I always tunnel my VNC connections through a secure SSH connection. Because the VNC protocol lacks encryption, it is critical that VNC traffic be tunneled through a secure channel to shield it from snoops.

When using my Macs, I use the "Chicken of the VNC" (cotvnc) application to connect to RealVNC servers. I always see greater lag over a cotvnc client connection than a RealVNC connection. I've tried matching the encoding algorithms and display characteristics on my PC and Mac, but never see the responsiveness on the Mac that I do on the PC. I'm going to continue experiementing with VNC settings, but in the meantime the difference in performance has got me scratching my head.

Posted by Scott at 2:16 PM | Permalink

My employer has an Internet gateway that limits Internet access to HTTP and HTTPS. Other services, such as e-mail (POP, IMAP) and remote shell (SSH), are not allowed to travel out based on the ports they use. This is not to say that one couldn't conduct those operations on the HTTP and HTTPS ports; however, those service ports are not designed for protocol tunneling.

This got me thinking about the futility of port restrictions. Imagine you are an evil-minded person intent on traveling to a remote destination. The authorities know your true identity, which would give you away if you used it while traveling. So, you assume a false identity while traveling and revert to your true identity once at your destination in the company of other evil-minded people. No matter what restrictions are placed on travel, evil people (or data) will be mobile so long as an alternate identity can be assumed.

The evil traveller may be discovered if the authenticity of their identity is questioned. What if, in the case of SSH and HTTPS traffic, there are no means of fingerprinting the data because it is encrypted? The interrogator could question the trustworthiness of the traveller and their source/destination. I suppose this is what happens when a person tries to travel from the U.S. to an untrusted contry (i.e. Afghanistan, Iraq). The problem on the Internet is that there is no such thing as an "untrusted site." They are all equals in the eyes of an Internet gateway. So, should there be multiple Internets to better serve corporate/government interests?

Posted by Scott at 2:01 PM | Permalink

I am used to working with the complex communications networks employed by digital computers. In order for such networks to function, a strict set of rules must be followed by all participants in the network. A collision occurs when two or more parties attempt to transmit on a shared channel at the same time. In such a case, the parties must then attempt to re-send their information at different intervals to ensure receipt.

While driving to work last week, the signal from my iPod FM transmitter was overshadowed by a stronger signal nearby. We both had were attempting to broadcast on the FM frequency 87.9. I disconnected the transmitter from my iPod and began listening to an FM broadcast emanating from a nearby car. I could hear the broadcaster skipping songs until they settled on one they liked. It was a fun, voyeuristic-like experience.

In this case, two parties were attempting to broadcast on a shared channel and caused a collision. If the other person had a stronger signal, they may have had no idea that a collision was even occurring. Because my signal was weaker, I was plenty aware that a collision occurred - my music wasn't audible through the car stereo.

The amazing thing about analog networks is the inherent imbalance of power between participants. The one with the strongest signal wins. End of story. But, in a digital network everyone is on an even playing-field. The later is a much simpler environment to work in, and it's obvious why businesses and governments rely on digital networks for their most important operations. So what are analog networks good for?

Posted by Scott at 6:26 PM | Permalink

I'm currently researching different packet capture utilities available for Documentum's supported platforms to aid us in diagnosing customer problems. I'm familiar with the Ethereal program, which offers a nice graphical interface capable of capturing, displaying, and reporting on captured traffic. However, installing Ethereal on some platforms can be difficult. For instance, Mac OS X requires Fink to run Ethereal. Installing additional programs such as Fink might not be acceptable in our customer's high-security environments. This is why using existing tools is highly desirable.

There are two tools available on most UNIX-based systems (including Mac OS X) effective at capturing and recording network traffic. They are 'tcpdump' and 'pcap'. Pcap stands for "Packet Capture", and is responsible for interfacing with the network adapter to sniff Ethernet traffic. Tcpdump can use pcap to capture traffic and report the information to a file or the console. The tcpdump file format is recognized by Ethereal, so customers using tcpdump can supply us with the dump file which we can then analyze in Ethereal. The network traffic can reveal many critical details explaining why the product is not working as desired.

Posted by Scott at 11:23 AM | Permalink

I listened to an interesting "Security Now!" podcast while driving to work this morning. The program covered the technical fundamentals of the Internet with a focus on packets and the role they play in Internet traffic and routing.

The paradigm-shift which made the Internet possible was to start thinking in terms of packets instead of circuits. Prior to the Internet, all communications (voice & data) links were made using dedicated circuits. There was a dedicated wire path between your phone and the party you were calling. It belonged to you, and nobody else. This proved inefficient because much of the bandwidth of that dedicated circuit was wasted on empty pauses, and was overkill for the low-bandwidth requirements of voice communications. So, the packet was introduced as a routable piece of information that did not require a dedicated link between the two parties; rather, the packet containing the source and destination information and relied on intermediate nodes to ensure its safe and expedient arrival. This is directly analogous to the postal service, where the sender and recipient information is emblazoned on the envelope and an amorphous infrastructure is used to route the envelope to its destination.

The most amazing aspect of Internet Protocol Version 4 (IPV4) is that it was designed in the mid-1980's before anyone knew that it would be used by devices ranging from million-dollar servers to fifty-dollar mobile phones. The creators of the Internet envisioned networks on a national or regional level (i.e. US Internet, Canada Internet, etc.), not the global, singular network that it is today. The physical span of the Internet (global) introduces a lot of intermediate nodes, of which there is a maximum of 255 ((2^8)-1) in IPV4. This limitation is like saying that your envelope may pass through a maximum of 255 postal offices on its way before it is deemed non-routable and returned to the sender. The reasons why 255 nodes are acceptable can likely be explained through statistical analysis, but the reasons for 255 being chosen are simply circumstantial: 255 is the number of permutations of an 8-bit byte, which is the space allocated for the Time-To-Live (TTL) component of a packet. One fewer byte would have meant an intermediate node maximum of 127. The number of nodes decreases by half for each bit removed from the TTL component.

In all, I am just amazed at the effectiveness and scalability of IPV4. It is a wonderful example of the use of real-world analogies and simple design to produce a technology that is scalable, efficient, and practical.

Posted by Scott at 10:50 AM | Permalink

I listened to NPR's Technology podcast this morning while driving to work. There were a couple of interesting stories, one of which addressed the use of the Wikipedia online encyclopedia by American politicians to present themselves in a favorable light. Some politicians or their staff have edited entries to remove records of questionable activities (i.e. campaign contributions, divorce, etc.) There have also been cases of "edit wars" where Internet users repeatedly modify each other’s entries in the Wikipedia to reflect their personal views on a subject.

What really caught my attention was the stance of the Wikipedia founders - to allow this selective editing to continue. The Wikipedia is backed by a version control system that records the identity (IP address) and content of every post to the system. By looking at the IP addresses of Wikipedia contributors, it can easily be determined how many of the changes are originating from government networks. Also, it provides an interesting perspective on the social interaction taking part on the Wikipedia pages. The NPR reporter likened it to writing graffiti on the bathroom wall at school; however, this "wall" knows the identity and actions of every person who has every written on it. I think that the false impression of anonymity encourages people to contribute inaccurate or biased content to the Wikipedia. If they ever realize that their identities are completely known, the online encyclopedia or forum may cease to be a magnet for candid commentary.

Posted by Scott at 9:28 AM | Permalink

I read an interesting article on Bruce Schneier's blog regarding a possible solution to the problem of "trusting trust". The basis of the problem is that a chain of trust is formed between source code compilers, and has the potential for exploitation if the first compiler in the chain contains malicious directives. The first compiler could modify all compilers and debuggers it builds to propagate any of its malicious directives.

The role of a compiler is generally to produce a machine-readable form of human-readable source code. The compiled output can take the form of machine-code (native binary), or intermediate byte-code (as in the case of Java and its Virtual Machine). A Java program represented by byte-code is interpreted at run-time by a machine-code program. Frequently, Java programmers will adopt a false sense of security because their programs are represented by byte-code running in a Virtual Machine (VM); however, the VM is a machine-code program that is as vulnerable as any other machine-code program. The difference is that a higher degree of trust is placed on the VM machine-code than on one's own program. The merits of this outcome are debatable. Because the operating system is built using a source code compiler, it is vulnerable, too.

Schneier suggests that having two root compilers with equivalent functionality and different sources can remedy the problem. It's sort of like having two separately-designed factories responsible for producing a widget; if both factories receive the same specifications from the widget designers, there is no need to trust one factory more than another since their output must be the same. If it is not the same, then at least one is incorrect. It is possible for both factories to be wrong, but not in identical ways.

Posted by Scott at 9:35 AM | Permalink

There's a great extension called Enigmail for the Thunderbird e-mail client that provides integration with the GNU Privacy Guard implementation of PGP. Enigmail makes encryption, decryption, and signing activities incredibly easy. It also provides a great tool for searching and importing public keys into a local truststore. I'm going to start using PGP to secure e-mail communications whenever possible. I've published my PGP public key to the PGP Global Directory, and can be referenced directly using the identifier E80DCE23. Here are some screeshots of Enigmail in action:

Posted by Scott at 10:35 AM | Permalink

While reading the book 'Crypto' by Steven Levy, I became enamored with the idea of writing a tool to simplify the use of Pretty Good Privacy (PGP) to secure e-mail communications. I should have known better after having read about the pitfalls that dragged down PGP, RSA and others. I'm sure that the NSA is pleased with the outcome: the Common Access Card (CAC) has achieved widespread use in the U.S. Department of Defense with strong crypto for e-mail, while no such solutions exist in the public domain.

In any case, I came upon a nice set of cryptography APIs from Bouncy Castle for Java that perform common PGP operations such as key creation, signature verification, and stream encryption. Next, I set about to create a Java Swing GUI for creating a PGP keychain and key. This was pretty easy, but I have not been successful in verifying message signed using other PGP tools. Hopefully, I'll be able to solve the problem of verifying messages tomorrow. The next step I'd like to take is to provide for the specification of the PGP keyring filesystem location, and the importing of other people's public keys. Here's a screenshot of the 'keyring creation' dialog:

At this point, I'm afraid of wasting more time in pursuit of a convenient tool to encrypt & sign messages since it seems that after 15 years PGP is still not ready for prime-time. I don't think it's the result of a design flaw in PGP; rather, it seems that the infrastructure and standards aren't firm enough to ensure compatibility and ease of use.

It's really a shame that the continued lack of a Certificate Authority for PGP keys has been the downfall of secure e-mail. Without a CA, the dreaded "web of trust" as described by Bruce Schneier prevails. Users are required to trust one another based on credibility of a mutually known and trusted third-party. The credibility of the web’s connections decreases as it grows.

Posted by Scott at 4:25 PM | Permalink

I recall seeing the Squeezebox v2 wireless network music player on Amazon about a year ago, and marveling at the sleek and refined appearance of the unit. Today, I came across a review of the third version of the Squeezebox. I must say that Slim Devices has done an excellent job of expanding the capabilities of the device without complicating the interface. I like how the server software that runs on one or more computers on your local network is Open Source and multi-platform. I'll be sure to add this to my Amazon Wishlist!

Posted by Scott at 1:52 PM | Permalink

We own two Macs (12" Powerbook, Mac Mini) at home, and I've come to enjoy the convenience and security of storing account credentials (usernames, passwords) in the OS X "Keychain" application. I prefer to use the Keychain instead of a commercial third-party product mostly because it is integrated with the OS and is free. However, it's difficult to securely share a keychain file containing credentials across two or more computers. Putting this information on a network-accessible location is a bad idea. So, I've decided to follow the paradigm of the traditional keychain by purchasing a USB flash drive that I can attach to my real-life keychain. This will ensure that the digital keychain is bound to my physical keychain, which should always be on or near my person. But the question remains, how do I secure information on the keychain so that if someone gains physical access to it they won't be able to view to my digital credentials?

I would prefer to encrypt the entire contents of the drive since I may choose to store other sensitive information on it besides my keychain. This is akin to carrying a "digital safe" attached to one's keychain. If the keychain is lost, the information on the drive stays safe unless the password is discovered. Since I use a Mac, I can take advantage of the encrypted disk image capability present in Mac OS X Panther and Tiger. The disk image is encrypted at the OS-level using Advanced Encryption Standard (AES) military-grade encryption with 128-bit keys. Mac OS X also offers the ability to encrypt all of the files in your home directory automatically with AES using the FileVault feature.

I asked Natalie about the difference between using 128-bit and 256-bit keys. Obviously, a 256-bit key is more difficult to break than a 128-bit key. But is it overkill? She said that many security experts think that information security requirements are dependent on whether the information is "at rest" or "not at rest". When at rest, such as on a hard disk or flash drive, it is less vulnerable to attack. If it is not at rest, such as being transmitted over a local network or the Internet, it is more vulnerable to attack or theft. Natalie said that the issue of "rest" is intensely debated in the security field since one could argue that information is never really at rest.

I looked at different USB flash drives on the market and noticed that Lexar offers a Secure Jumpdrive model featuring 256-bit AES encryption. Lexar's software drivers must be installed on the computer in order to access or manage a secure flash drive. I find this a big negative since I don't know Lexar's reputation as a software manufacturer, especially with regards to encryption. Also, it is not possible to install drivers on machines that are part of a managed environment (i.e. work, internet cafe, etc.). It turns out that Lexar has made some serious errors in the security implementation of their 1.0 release. This doesn't bode well for the Secure Jumpdrive. What good is a 256-bit key if the password can be accessed by an attacker within a matter of minutes?

Since the encryption is bound to be in software, I've resolved to use a software feature implemented at as low a level as possible, such as with Apple's encrypted disk image. I'm guaranteed to be able to securely access the image on any Mac without installing additional software. Plus, the odds are that if the drive got into the wrong hands, they wouldn't have access to a Mac and thus couldn't access the drives contents to begin with. I've purchased a Sandisk Cruzer Micro flash drive which should discreetly fit on my keychain, and will use an encrypted disk image to secure my keychain and other personal data.

Posted by Scott at 8:58 AM | Permalink

I added the web pages I posted on-line in 1995 referencing my TI-85 programs. They certainly gave my girlfriend and I a good laugh. The content is completely unmodified, and in many ways reflects the make-up of the Internet at the time. Here are links to the two sections I maintained:

• Math
  
• Games
  

The links from the images reference UUEnconded files containing my TI-85 programs. UUEncoding was a popular means of transmitting binary files in ASCII-only mediums like USENET newsgroups. I posted many of my programs on USENET, and learned a lot about programming from other programmers on USENET. Unfortunately, now it's the domain of spammers and porn sites.

Posted by Scott at 11:00 PM | Permalink

I also found the program I wrote as my final project for the CIS-1 class I took at Hartnell Community College during my Senior year of high school. It is an encryption program that is ridiculously easy to break - it just shifts the characters by a fixed amount. This way, an 'a' becomes an 'f', and a 'b' becomes a 'g'. Hey, I was 17. I also remember getting a computer virus on our home PC, and then accidentally transferring the virus to my friend Jason Liao's home PC via this program. He was pissed! What's even more funny is the README file I created to accompany the program. My god, I was arrogant. Here are the contents of the file:

Help for Encrypt 2.0!

**************To start the program, use 'new' for your password**********
	Thanx for downloading my little proggie here.  I know it's not
much but it's kinda fun to encrypt stuff even though it's not a really
complicated algorithm (go ahead, look at the source code!).  I have included
a cool icon I made, too.  

	This program was designed using Borland Turbo C++ for Windows, 4.5.
It's got a few cool features like:

- encrypts your password, so nobody will peek at it
- keeps reacords of the time/date of encryptions/decryptions
- allows you to change your password
- views text files
- lots of other cool stuff.....

Any suggestions are welcome, just so long as you don't trash on my 2 hour
hack......

Scott Kidder
Gumby123@aol.com

Scooter B Software motto: "World domination, here I come!"

Posted by Scott at 12:49 PM | Permalink

For the last four months, I've been subscribed to Comcast Broadband Internet at home. Service has been very good, but occasionally my connection is extremely slow without a discernable pattern. This afternoon, I heard on a Security Now! podcast that frequently users of file-sharing programs will routinely have their IP addresses re-assigned to new users, and those new users with the old IP address become subjected to large volumes of file-sharing requests intended for the original user of the IP address. This could result in severely degraded network performance for the new user for no apparent reason.

This reminded me of a security tip I've seen for operators of home Wi-Fi networks which is to consider connecting your wireless access point (AP) to a power outlet timer. These are the timers that people often use when on vacation to activate their home's lights at predetermined times. Similarly, a timer can be used to shutdown an AP during times outside the normal usage windows (i.e. 1AM - 6AM). This is in line with the old security tenet that the only safe computer (or network) is the one that's turned off. Shutting down a computer network during off-hours will reduce its exposure to snoops, and provide your Internet access provider to assign your AP a new IP address. Using the same IP address over a prolonger period increases the likelihood of attack since your traffic is coming from a semi-permanent source. I'm going to experiment with this in the near future and will post my results on this blog.

Posted by Scott at 12:48 PM | Permalink

A couple of days ago, I started reading the book "Crypto" by Steven Levy. Natalie has owned the book for several years, so it was a spontaneous decision on my part to pick the book up and begin reading. I read Levy's book "Hackers" in 1996, and it had a profound effect on my understanding of computing history and culture. "Crypto" seems to be written in a similar fashion as "Hackers". So far, it has covered the history of modern public key cryptography through the eyes of its creators: Diffie, Helman, etc. I love reading narratives, particularly when they involve computing :)

Posted by Scott at 8:27 AM | Permalink

I have a lot of RealAudio files containing recordings of my radio show while I was a DJ at KDVS in college. I've wanted to port them to a more portable format like MP3 for a long time. I came across a message board post a while back and was able to accomplish the task pretty easily. On my Mac OS X 10.3 laptop, I downloaded and built the Lame MP3 encoder, mplayer, and mencoder and was off to the races. Now I can listen to the streams in iTunes, yay!

Posted by Scott at 7:29 PM | Permalink

I've been trying to decide what sort of hobby project I'd like to work on next. Remote applications have fascinated me for a long time, and it seems to be a really hot area right now given the growing popularity of 802.11 wireless.

I think that it would be really cool to take photos from a remote-control plane. There are a few people who have already done this, and published the process for others to learn from. Unfortunately, their instructions refer to an outdated camera model, and don't transmit images in real-time. X10 cameras might be able to solve this problem, but I'm not certain of their image resolution or signal strength.

Posted by Scott at 1:23 PM | Permalink

The default Movable Type output format is plain HTML. This works great if you don't want to include dynamic content. However, I'd much rather use PHP to make this site more dynamic.

I happened upon a good tutorial for converting Movable Type sites to PHP. I followed the steps to-the-letter, but none of the PHP pages loaded in my browser. Instead, I received an HTTP 500 error code, indicating an error during loading. I was puzzled.

I then considered the possibility that the permissions on the generated files were being rejected by the PHP engine. Sure enough, that was the problem. I solved this by editing the mt.cfg file to set the default file permissions to '0644' (i.e. HTMLPerms 0644).

Hopefully this will allow me to bring more dynamic content to the site!

Posted by Scott at 3:23 PM | Permalink

On Monday we had Comcast Broadband Internet installed, along with cable television - hello 20th century. The downstream performance with cable internet is marketed as being 4.0 Mb/s. We saw about 3.1 Mb/s while the technician was performing the installation, which more than exceed my wants or expectations. Our old DSL line delivered a steady 1.5 Mb/s downstream, which was great.

But last night (Tuesday), web browsing performance ground to a halt. I haven't experienced such lag since dial-up. After performing some ping's and traceroute's, I figured that the delay originated in the hostname lookup. Hostname translation involves querying a Domain Name Service (DNS) server to obtain the Internet Address (IP) of the host in question. This operation occurs a lot during web browsing, since most popular websites include content served from multiple hosts. So why was hostname lookup taking so long (>100ms, or timeout)?

I googled the problem and learned that many Comcast users complained of similar problems. The Comcast DNS servers generally have horrible response times, particular during peak residential hours (5-10P during week). Most of those who responded remedied the problem by statically setting their DNS server IPs to other provider's DNS servers rather than using the Comcast DNS servers set during the Dynamic Host Configuration Protocol (DHCP) client registration. I've been using the Verizon DNS servers, since they yield consistently better performance:

• 4.2.2.2


• 4.2.2.3

Comcast, what's the story? How could such horrible DNS performance be 'ok' with a residential broadband provider? Most of their customers use broadband strictly for web browsing. Browsing response times are critical to customer/user satisfaction. Hopefully they'll improve DNS performance soon.

Posted by Scott at 1:47 PM | Permalink

I've deployed my first publicly-available Objective-C application for Mac OS X. It's called 'Improved Outlook' and is capable of importing address book records from Microsoft Outlook into the Mac OS Address Book application. I love working in Objective-C, and this application has been a real joy to develop. I'm amazed by all of the API's made available by Apple for interfacing with their applications (Mail, Address Book, etc.).

Improved Outlook on SourceForge.net

Posted by Scott at 9:30 AM | Permalink