Misspelled nemesis club

Sending a sensitive file, one that should be encrypted, amongst Linux and OSS geeks is doable. Most have heard of PGP, many have a GPG key (here is mine) and some even use it.

Sending an encrypted file to most people is a non-starter. The software may be there (Outlook is S/MIME capable), but the knowledge and the experience definately isn’t. Which is a shame, because I’d like to have my bank statement securely sent to my email account.

PGP Desktop has a feature called the Self Decrypting Archive. To quote the PGP Command Line for Servers FAQ:

A Self-Decrypting Archive (SDA) is an executable containing a file that has been encrypted using a passphrase. A recipient of an SDA runs the executable and enters the passphrase to decrypt the file.

SDAs are an attempt to make encrypted email easier, by making decryption far easier for the recipient. However, Self Decrypting Archives are fundementally insecure. Here is how they’re meant to work:

1. Alice runs PGP Desktop to encrypt a sensitive file, so she can send it to Bob.
2. Bob doesn’t have any encryption software, so PGP Desktop encrypts the sensitive file and appends it to a small decryptor program. The decryptor + sensitive file is the SDA.
3. Alice sends the SDA to Bob, attached to an email. Over the phone she tells him the encryption key.
4. Bob receives the email, and runs the SDA.
5. The SDA requests the decryption key, and decrypts file for Bob.

That sounds great. Alice can encrypt files, send them securely to Bob, then he can decrypt them. Bob doesn’t need any encryption software installed.

Here’s the problem: Bob is running an unverified program. Supposedly it’s from Alice, but he can’t be sure. This is exactly how email viruses spread. Bob cannot trust the SDA, since he cannot be sure what he received was really sent by Alice.

Could Alice sign the SDA, including the decryptor program? Yes, but it won’t help.

All Bob has to verify Alice’s signature on the SDA, is the decryptor program in that same SDA. Here’s how Mallory, an attacker can subvert this:

1. Alice sends the encrypted, signed SDA to Bob, and tells Bob the encryption key
2. Mallory  intercepts the email, replaces the decryptor program with his own. He sends the modified SDA on to Bob, spoofing the from address.
3. Bob receives the email, and runs Mallory’s SDA.
4. Mallory’s decryptor, running on Bob’s machine fakes a signature verification.
5. Mallory’s decryptor requests the encryption key and decrypts the file for Bob. It also sends the decrypted file back to Mallory, and installs a back door on Bob’s computer.

The bottom line, is that you and I must be able to trust our encryption software, or the encryption is pointless. For that we must be able to verify we got it from a trustworthy source. Unsigned email, or email that verifies it’s own signature, cannot be trustworthy.

Here’s an email I received today:

From:     meetYourmessenger <no-reply@meetyourmessenger.com>
Subject:     You have (1) new message from Adam

Hi alex,

You have (1) unread invitation “Hello ” from Adam at meetYourmessenger.co.uk

Click here
Show the message in your temporary inbox at meetYourmessenger.co.uk

I know an Adam on MSN Messenger, he didn’t send it. Mcafee SiteAdvisor says all is well,  the comments are less rosy. Until I see evidence otherwise, I’m treating meetyourmessenger as dodgy.

Putting my timesheets in order today, I finally figured out how to make Excel deal correctly with time durations. The default is to treat values as a date/time, formatted as hh:mm. So a value such as 37:00 – meant as a duration – is displayed as 13:00 (1 PM the following day). To correct this, choose custom cell formatting, and enter the format as [h]:mm.

In OpenOffice Calc, [H]:MM is the default format for a time value (tested with 3.0), so durations work out of the box. For something pre-cooked, the OpenOffice Documentation site has a timesheet template by Vivian Lal.

For months now, I’ve found Firefox on my Linux laptop to sometimes be sluggish and a CPU hogging, particularly when scrolling. T-Mobile UK and Engadget were the worst affected. Visiting t-mobile.co.uk saturated the CPU for several seconds whilst rendering. The result looked horrible – grainy, and badly pixelated.

I’d attributed this to X, Nvidia, browser sniffing, Flash and Javascript/CSS. Of course it was me all along. Firefox 3 has a feature called Full Page Zoom, it doesn’t just resize text, it scales everything on the page. I had zoomed these pages, then forgotten.

If any of this sounds familiar, try reseting your zoom level:

1. Visit the page that scrolls slowly or looks pixelated.
2. Either press Ctrl + 0, or click Edit → Zoom → Reset.
3. If text is now too small to read, enable Edit → Zoom → Zoom Text Only, then zoom in with Ctrl + +.

Firefox should now scroll the site smoothly and quickly. The zoom level is remembered on a per site basis, so repeat this for any other pages affected. If you would like to control zoom from the toolbar, try the PageZoom extension. If you would like to set the zoom globally, try No Squint (courtesy of AncientPC on Al-Osaimi Techlog).

The question remains why Full Page Zoom can be so sluggish, and under what circumstances. Also, why does Try Firefox 3 full page zoom on Mozillalinks performs so poorly for me, regardless of page zoom.