Wednesday, August 25, 2010

Windows Security (part II)

Well it's been about a year since I looked at the Windows security problems:

I thought I'd check in again to see how much progress has been made in securing the operating system.

In a nutshell, not much. Looking at Secunia, Windows XP is now rated at "highly critical" vs "extremely critical." I suppose that's some progress. :)

This week, there's been a "new" line of attack discussed, focused on insecure dll loading. Though it's not exactly new. Microsoft has been sitting on it for ten years without fixing.

On Monday, Microsoft confirmed reports of unpatched -- or zero-day -- vulnerabilities in a large number of Windows programs, then published a tool it said would block known attacks. At the same time, the company said it would not patch Windows because doing so would cripple existing applications.

So in summary, despite having 80,000 employees and billions of dollars in revenue rivaling a small country, Microsoft won't be fixing this security problem. Instead, they will stick a bandaid on it. Predictably, this bandaid won't work any better than the hudreds of other bandaids it's stuck on top of. But since they started off with a bad idea, fixing the bad idea would break backward compatibility. :)

I would predict some real trouble for Microsoft in the future. As a tech company, they've pretty much stagnated.

As far as their core products go, a lot of alternate software is being developed that is both free and in some cases works better. How are they going to be able to compete against "free" in the long run? Can Microsoft Office really do much more than OpenOffice anymore? And each year, the free software gets better, the proprietary software not so much. How much more can a word processor do? What more can an operating system do, besides provide a little clicky button to launch an application, and not be a virus magnet?

I don't see this improving any time soon. Their stock price summarizes it all:

Monday, August 16, 2010

Pythagorean Puzzle

I like wooden toys, puzzles, and mechanical devices. The other day, I was looking at a simple proof of the Pythagorean Theorem. The idea behind the proof was incredibly simple, but the simplicity was obscured with the mathematical notation and formalism. But I noticed it could be directly translated into a mechanical device. So, I thought I'd make a toy out of it. The idea is it might make the concepts a little more clear, without the clutter of notation.

The general idea behind the proof is this:

Suppose I have a rug and place it flat on the floor of an empty room. If the rug is too small for my tastes, can I cover more of the floor by moving the rug around (on the floor)? Not really. Regardless of where I put the rug, the same total area of floor will be covered, the same total area will be uncovered.

So, imagine four rugs that are all the same size, and shaped like right triangles. The black space is the uncovered floor:

Now, I can rearrange the rugs, in another pattern:

But either way, the same area of floor is uncovered, regardless of how I move the rugs. So, the black area a2 + b2 has the exact same area as black area c2. So,

a2 + b2 = c2

But also, the axa, bxb, cxc squares are formed directly with the sides of the triangles. In other words, a and b are the length of the triangle's legs, and c is the length of the hypotenuse.

So, this is a visual, mechanical demonstration of the Pythagorean Theorem, for an arbitrary right triangle. :)

Below are the steps I used in making the prototype:

First I started with a large sheet of 1/8" hardboard, and cut a 1" strip. Though, in hindsight, it would have been easier to just find a precut, plained 1" x 1/4" strip.

Now, there will be three basic layers: top middle and bottom.

The top layer can all be cut from the long 1" strip. I used 2"x1" triangles. So the inside of the frame will be 3" and the outside 5". The four small 1"x1" squares will be corner supports between the bottom and top layers. The three small 1/2" x 1" rectangles will be used for sliding tabs (handles).

The middle layer (left bottom) will need to be slightly thinner so that it can slide freely between the corner supports. I just took off a hair with a flat file. The bottom layer (right bottom) will need a slot cut that intersects points (0,0) and (2,1), if the origin is at the lower left. I just used a drill and coping saw. Any thickness for the bottom is fine.

Roughly assembled:

The yellow triangle will slide along the slot in the bottom layer. The back tab will connect to the yellow triangle with screws (passing through the slot). These will need to be attached at the same angle as the triangles:

Glue the green and yellow triangles to their middle layer supports. Use two small screws to prevent rotation. It's probably best to drill pilot holes for these small pieces.:

Also, I cut a thin strip of felt, and glued to the insides of the slot. This smooths the slide mechanism, and looks a little better. After dry, then cut flush with a razor blade.

The sliding yellow triangle can be attached first. This will determine the position of the frame and other pieces. (backside)

Then add corner supports (which will be cut to size at the end). The only thickness that really matters, is that the middle layer is slightly thinner than the corner supports.

The side tabs and red blue triangles will sit on top of the middle layer, and allow the pieces to slide vertically and horizontally. Glue both tabs and triangles to the middle layers.

Personally, I like the natural wood toys better. But, since this is a wooden toy for kids, I picked bright simple colors. :)

For a children's toy, I think the squares should have been purple, and the frame should have been black. Since I think it's easier to focus on purple than black (a void), and is often a favorite color. But I didn't have any purple felt on hand. Though, black doubles as a chalk board.

(I actually painted everything at the first step, but had to touch up scratches afterwards.)

After painting everything, use a flat bastard file so that edges are clean and sharp.

Then, apply drips of glue to the corner supports, and adjust the frame so that both triangle positions are flush. Cut excess off when dry. I rounded the tabs off with a Dremel tool, and painted the white labels on the black background. These labels are obscured by the resting position of the triangles. A hole can be drilled in the back for hanging somewhere.

And that's it. Now, even a five year old can demonstrate this fundamental theorem of mathematics. :)

Thursday, August 5, 2010

File Encryption on the Command Line and a Secure Text Editor

Update: I added this script to github at:

A while back I needed a really simple way to encrypt a password file on the command line. I wanted to be able to write quick, simple scripts, with no more than one line of code handling the file encryption part. So, in Linux or Windows (using cygwin), I used these aliases:

# for simple encryption methods, use:
#     echo "text" | encrypt
#     echo "U8askj123lkjasdflkjasdlkjargoi+/==" | decrypt

alias encrypt="openssl aes-256-cbc -a -salt"
alias decrypt="openssl aes-256-cbc -d -a -salt"

Then other quick shell scripts can easily encrypt/decrypt files as needed.

However, while this works, it was still a nuisance to actually edit and maintain the encrypted files. Here's an alternate approach that will work under Linux or Windows (using cygwin). It wraps the classic vi text editor, or any editor for that matter, in a shell script that opens and saves files in any standard encryption format (like aes 256), which can then be decrypted by other script utilities. Also, it will save an encrypted snapshot of the file every day it's updated in case you mangle the password or file.

Here's the bash script, which can be saved to /usr/local/bin/svi

# A simple secure vi editor, for aes encrypted files
# file name passed in as argument, for example
#     svi FILENAME
# to open file as read only
#     ln -s svi sview
#     sview FILENAME

# type of encryption

# where temp files will be decrypted

# create tmp dir/file
me=`basename $0`
dir=`dirname "$tmp$1.tmp"`
mkdir -p "$dir"
touch "$tmp$1.tmp"
chmod 600 "$tmp$1.tmp"

# decrypt to tmp
if [[ -e "$1" ]]

 if openssl $cipher -d -a -salt -in "$1"  > "$tmp$1.tmp"
   if [[ ! -s "$tmp$1.tmp" ]]
     echo "WARNING: decrypted an empty file, exiting."
   echo "WARNING: bad password, exiting."


if [[ $me == 'sview' ]]
 # open file read only
 vi -n -R "$tmp$1.tmp"

 # open file for editing
 vi -n "$tmp$1.tmp"

 # re-encrypt after exiting vi
 if [[ -s "$tmp$1.tmp" ]]
   touch "$tmp$1.aes"
   chmod 600 "$tmp$1.aes"
   while [[ ! -s "$tmp$1.aes" ]]
     openssl $cipher -a -salt -in "$tmp$1.tmp" > "$tmp$1.aes"

   # make backup, replace old
   if [[ -s "$tmp$1.aes" ]]
     if [[ -s "$1" ]]
       cp -pf "$1" $1.$(date "+%Y-%m-%d").bac
     mv -f "$tmp$1.aes" "$1"


# cleanup
shred -z -u "$tmp$1.tmp"
rm -f "$tmp$1.aes"

Then for example, to open or create a new encrypted text file, use:



Overall, this is a reasonably simple and secure method for protecting files, in the case a laptop is lost or stolen. The strength is that these files can be transferred across or stored on insecure media.

As for weaknesses though, this does create a decrypted copy of the file on the local computer while it is being edited. And the temp file, even if deleted (unlinked), may leave an image on the local disk. Another weak point is that insecure memory could be flushed to swap space on the hard disk.

And, as with any encryption cipher, it can be always broken with the old "wrench" method.... :)

(comic courtesy of xkcd)