My laptop slowed dramatically the last few weeks, especially Firefox. Rebooting didn’t help. I suspected a virus, but it was clean. I cleared some Windows caches that can slow things down, but that didn’t help either.
Going through the process list, I noticed that Firefox was using a huge amount of memory, and was adding to it by the second. So it was off to The Google to see what the deal was.
The “download history cache.” Clean out the friggin’ “download history cache.”
All is good again.
Posted: May 4th, 2009 | Filed under: Coding | Tags: download history, firefox, memory use, performance | 1 Comment »

White Mountain Spire
The route follows the cleanest line just right of the center
Photo by Lee Lambert
“Lets climb that.”
Mark Sonnenfeld was looking at a thin crack on an overhanging prow almost a thousand feet above us. From where we were it was impossible to tell if it was climbable, or even if we could get there.
“Sure.”
We were standing below a huge unclimbed wall on the flanks of Mt. White, in central Colorado. Mark spotted the wall years before when he was doing geology field work in the area, and finally badgered me into trying to climb it.
“Could be veg-med,” he told me. Meaning that the cliff looked good, but the climbing might suck.
With this in mind, I sized up the lower part of the wall. It was slabby, and a bit brushy. I picked the hardest, cleanest, line up the lower wall. It looked like it would be easier than we wanted, but at least the climbing would be good. And it lead nicely toward Mark’s crack, so we had a plan.
Now, plans like this aren’t worth much on a first ascent. Especially since we’d never even touched the wall, and had no idea what we were up against. But, if you’re going to make a plan, it might as well be a good one.
A few hours later, I was working my way up a thin corner that faded out a ways below the belay. While the climbing was excellent, it was anything but easy. Insecure and sustained climbing, with poor and difficult to place protection. I fixed a few pins, but they weren’t very good.
It didn’t help that half of my mind was focused on the end of the pitch, where the corner faded away, and the protection would disappear entirely. The fact that I’d refused to bring a bolt kit along didn’t help either.
Amazingly, as the corner faded the holds improved. It was thrilling, but I was able to run it out to the belay.
Things eased off a bit, and we soon found ourselves below Mark’s crack. It was very steep, and a bad size: thin hands. Mark was good at that kind of climbing though, and sent it with a minimum of fuss. I had to fight like hell on it, but managed to second it without falling.
This was followed by another very difficult section, with just enough protection to get through the hard part, and a big runout above. I regretted, again, not bringing the bolt kit.
Some easy climbing brought us to the final spire. It was about forty feet tall, and was shaped like the blade of a screwdriver. There were no cracks. There was no gear. Without a bolt for the summit, we would have to down climb to get off.
I messed around with it for a while. It would be a precarious barn-door layback up the edge of the pinnacle, and harder on the way down. I’d had enough fear for one day, so we left the final spire unclimbed.
That evening we celebrated by consuming a few “Scarlets.” (Officially a “Scarlet O’Hara” – whiskey and cranberry juice.)
Scarlets – IV 5.12a R (10 pitches, five stars)
Note: I returned a few years later with Brian Hansen and, after climbing another new route, climbed the final spire. We had a bolt kit this time…
Posted: April 28th, 2009 | Filed under: Climbing | Tags: bolts, Climbing, first ascent, free climbing, scarlets | No Comments »
One of the advantages of using encrypted email, is that your message won’t trip some piece of mindless data mining software. Remember, a few years ago, when the FBI was running around investigating an Elementary School Teacher because profiling software picked her as a potential terrorist?
Well, using encryption may not be enough.
An article in PC Pro discusses plans in the UK to do profiling based on who you communicate with:
As with the original scheme, the actual content of the phone calls and messages won’t be recorded, just the dates, duration and location/IP address of messages sent.
From this information, they’ll pick the next set of Elementary School Teachers that need to be investigated for possible links to terrorists. It makes me wonder; how many of us are only a few degrees of separation away from someone under suspicion?
Sadly, encryption alone isn’t going to help you here. You’ll need encryption and anonymity.
Posted: April 27th, 2009 | Filed under: Privacy | Tags: data mining, school teacher, surveillance, wiretap | No Comments »
My friends know what a lousy spectator I am. Standing on the sidelines makes me feel like life is passing me by.
So it was surprising to find myself on the wrong side of the registration desk for this year’s Elk Mountains Grand Traverse back country ski race from Crested Butte to Aspen. Not only was I on the wrong side of the desk, but I was signing up some of my old climbing buddies.
How did I come to this?
It started innocently enough, when Jan Runge (Race Director, River Rat Extraordinaire, and one of my best friends) asked me to be webmaster for the race site. No problem. I know when to say when.
Updating the look of the site didn’t seem too bad. I’m a professional nerd, doing some graphics work and hacking some HTML isn’t going to send me down the slippery slope.
I wasn’t even worried when I agreed to go to Crested Butte, as they needed a nerd on-site. Besides, there would be wine, women, and SWAG. I know my limits.
And, before you know it, I’m behind the registration desk. Signing up the real athletes. They’re getting ready for a 43 mile high altitude race to Aspen. I’m getting fat.
So, accompanied by Hurricane McEwen, I fled to Aspen. It will be safe there. Everyone is normal there. I won’t feel like a loser there.
But it got worse.
By the next morning, I’m working the finish line, and racers are collapsing on the ground in front of me. Some are kissing the ground in relief, while others are carried away on oxygen. More than a few of them crawl slowly to the keg. I feel left out.
So I join them at the keg. They need my support. I was doing it for them.
All to soon the keg is empty, and I’m drawn up the mountain to do triage with Jan. I start to feel better deciding who lives and who dies. Who gets to ski down to the (empty) keg, and who gets some quality time on a snow machine.
I even enjoyed skiing down with the last finisher, but it was only because I was needed. I was still in control. I knew what I was doing.
Later that night, as we were having dinner with the Aspen crowd, a very young, and very beautiful, woman kept smiling at me. This seemed to happen frequently in Aspen. Must be mistaking me for Bruce Willis or something.
The racers are unconscious. Women are flirting with me. Life is good.
Jan asked me if I would do it again next year, and I said yes. Guess I’m an addict now.
Can anyone recommend a good 12-step program?
Posted: April 24th, 2009 | Filed under: Adventure | Tags: backcountry, bruce willis, Elk Mountain, Grand Traverse, race, ski | 2 Comments »
From Gizmodo:
Verizon is currently sending out notification letters chock full of legalese to its customers. Here’s a summary: You have 45 days to opt out or you “agree” that Verizon can share your personal data.
Nice.
I was going to go for full frontal snark, but don’t feel the need after reading the comments on Gizmodo and Slashdot. Lets just say that they weren’t exactly positive.
I killed my Verizon account years ago. Any bets on whether my data gets included? (Or did they sell it years ago…)
Posted: March 10th, 2009 | Filed under: Privacy | Tags: cell phone, information, verizon | No Comments »
You know how to protect your own password; how do you protect your user’s passwords?
It is well understood that you should use a different password for each secure site you visit. Given the routine use of email addresses as logins, using a single “universal password” turns a successful attack on one of your accounts into access to all of them.
Not good.
On the other side, if you run a secure site, you need to protect your users, in case they don’t know this, and are not as careful as they should be. (And many of them won’t be…)
This was brought home a few years ago, when I had a project that required me to hack the passwords to my client’s web site. We were moving their site to a platform with incompatible password support, and their user’s passwords were (properly) encrypted, so we couldn’t move the password file directly.
There were many ways to approach this problem, but we wanted to make it as invisible as possible. So, as part of this effort, I put together a quick crack program to see how many of the passwords we could discover ourselves.
We ran the program for a couple of weeks and cracked around 25% of the passwords through a combination of dictionary and brute force attacks. What’s worse, most of these passwords broke the first day.
Why were these passwords so easy to break?
Two reasons:
- Bad passwords, and
- Easy to crack password protection.
The bad passwords were: words from the dictionary, common passwords (”asdf”, “abc123″), easily broken through brute force (”a”, “aa”), or default passwords that were never changed.
The weakness of the password protection wasn’t as obvious, as they’d used the conventional approach of storing a secure hash of the password. Checking passwords was accomplished by hashing the password and comparing the hash value with the stored hash. If they match, you can assume the password was correct.
The problem with this, however, is that the hash value is the same for every account using that password. To understand why this is a problem, let’s look at the design of the crack program I wrote.
The attack worked by constructing a hash table of every unique password hash. It then hashed trial passwords and did a single hash table look up to see if that password matched one used by any of the users. This approach wouldn’t have worked, however, had an effort been made to ensure that the hashed password values would always be unique.
An easy way to create unique hash values would be to calculate the hash of a combination of the user name and password. Now, the crack program wouldn’t be able to do a single test for the hashed value of password “abc123″, it would have to calculate a separate hash value for each user name.
In our case, with over 30,000 users, the crack program would have taken 30,000 times longer to run! We still would have been able to do the dictionary part of the attack, which ran in about a minute, but the brute-force part would have been out of the question. Even still, the dictionary attack would have taken several weeks to complete.
How do you protect your user base?
- Require reasonable passwords,
- Ensure that password hashes are unique, and
- Make your users change default passwords.
(And don’t count on being able to crack your password file…)
Posted: March 8th, 2009 | Filed under: Coding, Privacy | Tags: crack, login, password, Security | No Comments »
I was working on a security subsystem for a website the other day, and I needed to encode a bunch of variables into a cookie. I’ve written this kind of code way too many times before, and it’s pretty straightforward. It is very tedious, however, and can get complicated if you have to worry about escaping characters, encoding arrays, etc.
With this in mind, I decided to sniff around in the PHP documentation and see if there was something there that I could use to make this easier. I started looking at serialization, followed a few references, and pretty soon I came up with a very simple solution:
// Encode the values and set a cookie
function encode_cookie ($foo, $bar, $snork)
{
$cookie = serialize(compact("foo", "bar", "snork"));
setcookie("name", $cookie, 0, "/", "ericwinkelman.com");
}
// Get the cookie, and decode the values
function decode_cookie (&$foo, &$bar, &$snork)
{
extract(unserialize($_COOKIE["name"]));
}
The key to this code is the compact and extract functions. These functions work directly with the program’s symbol table, and not the variables themselves. The compact function takes the names of the variables to store in the cookie, and looks up the values in the symbol table. Similarly, the extract function gets the variable names and values from the cookie, and updates the symbol table with this information.
Through these functions, you don’t have to worry about formating, parsing, escaping, variable orders, etc. It even works with arrays. You must, however, make sure that the names of the function parameters are the same between the encode_cookie and decode_cookie functions.
For extra credit, I suggest encrypting the cookie value so that site visitors can’t mess around with them. Michael Gracie recently posted encryption and decryption functions that can be used for this.
Bake at 450 for 10 minutes and cool slightly before serving…
Posted: February 18th, 2009 | Filed under: Coding | Tags: cookies, php | No Comments »
Wired had a couple of interesting articles about the NSA wiretapping program. While I recommend both of them, there were a couple of points that call into question the value of the NSA’s wiretapping and data mining activities.
In NSA Whistleblower: Wiretaps Were Combined with Credit Card Records of U.S. Citizens they discuss some of the claims made by Russell Tice, the NSA whistle blower:
“This is garnered from algorithms that have been put together to try to just dream-up scenarios that might be information that is associated with how a terrorist could operate,” Tice said. “And once that information gets to the NSA, and they start to put it through the filters there . . . and they start looking for word-recognition, if someone just talked about the daily news and mentioned something about the Middle East they could easily be brought to the forefront of having that little flag put by their name that says ‘potential terrorist’.”
Now, compare this to what is discussed in CIA Spy Enlisted Son to Collect Espionage Debts, Feds Say, where they quote the following coded message sent to Russian agents:
SUBJECT LINE: Hola Nancy!
Hello Sweety! How are you? I’m good. Sorry for taking so long to write to you…you know how work is and all. Any7ways, things are good. It looks like I will still be able to go on that vacation! I will keep you updated on that though. I am very much looking forward to it, and to seeing you again! Well hon, I just thought I’d say “hi” since I had the time!
As I mentioned previously, it is difficult to see how widespread data mining is going to be a useful tool in the fight against terrorists.
How do you build algorithms that distinguish innocent conversations (from people with nothing to hide) from the carefully coded messages sent by terrorists?
Posted: February 3rd, 2009 | Filed under: Privacy | Tags: NSA, Privacy, wiretap | 1 Comment »
Recently, I was reviewing the number theory associated with RSA Public Key Encryption. (I know, I need to get a life.) I noticed that there were several precautions listed for selecting the primes used to generate these keys:
- p and q should differ in length by a few digits
- Both p – 1 and q – 1 should contain large prime factors
- gcd(p – 1, q – 1) should be small
([Den84] Dorothy Denning. Cryptography and Data Security. Addison-Wesley, 1984. )
While precaution 1 can be checked by observation, precautions 2 and 3 are met by picking your primes in particular ways. (To be discussed some time in the future, assuming I don’t get a life before then…)
Nerd that I am, I fired up OpenSSL and took a look at some keys. What I found was that all of the keys failed test 1, some of them badly.
For example, this command will create a 2048 bit RSA key, and display it on the terminal:
openssl genrsa -3 2048 | openssl rsa -text –noout
Parsing through the output, you’ll find the two primes used to create the key:
[stuff removed]
prime1:
00:df:5f:81:5b:54:38:20:a4:bb:11:62:1f:05:33:
e2:68:27:f3:25:c9:2b:f9:75:5c:75:10:c0:70:67:
99:6b:9d:2c:99:5d:3a:1e:3a:ff:7e:dc:65:6a:a2:
09:44:0f:b8:10:43:b6:66:15:05:da:52:7b:79:a7:
79:d5:d7:84:01:c8:84:d2:76:0b:80:4b:3d:68:28:
d6:3c:f2:e6:02:27:11:f8:e8:52:ef:f3:5a:79:d9:
89:1f:fb:4b:fd:63:c9:fb:da:97:0f:e4:36:95:73:
a0:53:bf:cf:e8:a6:e0:7e:86:7e:23:14:a8:82:bb:
5f:7a:3e:14:a5:c2:7c:8c:eb
prime2:
00:df:46:72:0f:05:aa:b3:33:3b:e8:57:c7:40:43:
e8:42:0c:00:5e:a5:48:cc:48:76:3b:bd:8a:a5:29:
55:a5:17:0b:a7:e8:65:55:43:e0:22:63:13:33:87:
b6:45:0a:77:70:54:d2:be:c6:d8:41:22:8f:d6:19:
40:95:7f:7e:cc:75:c6:7f:80:bd:89:ab:d4:b7:69:
9f:73:2b:53:12:4b:14:ff:b3:b4:b6:c1:c2:88:f2:
34:d7:c7:34:2c:2f:86:9a:12:41:22:53:2c:2e:1e:
f4:37:d7:51:d5:cf:6e:bd:3b:0c:ac:10:1b:76:5a:
88:52:fa:10:61:9b:6e:a4:89
[more stuff removed]
Note that in this example, the two primes are the same length, and have the same prefix:
00:df:
I repeated the test a number of times, with similar results; the lengths were always roughly the same (within a bit or two) though the values of the generated primes generally differed by more than above.
I can’t speak to precautions 2 and 3, as I haven’t read the key generating code, and don’t know how they go about picking their primes. (Anybody out there familiar with this?)
Given the size of the key, this probably isn’t a big concern for most applications. If you are restricted to smaller keys, however, you may want to generate a few keys, and select one with a significant difference between the values of the primes.
Conclusion: OpenSSL can generate keys that violate precaution 1. I don’t know yet about conditions 2 and 3, but I think it is unlikely that either of them are met.
Posted: January 30th, 2009 | Filed under: Coding, Privacy | Tags: Add new tag, encryption, Public Key, RSA, Security | No Comments »
Recent news about the NSA’s wiretapping program doesn’t come as much of a surprise. We knew they were doing wiretaps. What was surprising was the scale: they wanted to monitor everyone and everything. It’s hard to imagine that they will obtain useful information from such a broad-based approach.
Consider on-line advertising. There are a number of very large companies doing ad placement on the web. These companies have loads of personal information about us, extensive data mining tools, and years of experience trying to predict our interests and behavior.
And the result? Most of these ads are so ineffective that they are only worth around $0.00001 each.
Additionally, unlike the terrorists, most of us are not trying to hide our interests/behavior. So you would expect the results for the NSA to be even worse.
Now this comparison may not be fair (I’d love your feedback on this) but it makes me wonder how the NSA is going to get much value from this program. A lead on a potential terrorist that’s only worth $0.00001?
Posted: January 27th, 2009 | Filed under: Privacy | Tags: data mining, NSA, on-line advertising, wiretaps | 2 Comments »