Archive for the ‘cryptography’ Category

I Am Not Satoshi

November 26, 2013

There has been a lot of speculation recently regarding whether or not I am Satoshi Nakamoto, the infamous creator of Bitcoin, and more recently whether or not a Bitcoin address which I control was used to fund the Silk Road marketplace.  I would like to address these two issues now and hopefully put them to rest.



REcon 2012

June 19, 2012

I’ve just recently returned from REcon 2012 and while I heard a couple people express that they had “heard” that some people were more disappointed with this year’s conference compared to prior ones, I personally really enjoyed it and felt it was the best one yet.  I saw and enjoyed more of the lectures this year than I have in the past and seemed to have better interactions with the other conference attendees, better conversations, and generally enjoyed myself more than years past.  Perhaps it was because this year Montreal wasn’t in the middle of a heat wave with no air conditioning in the hotel and the conference hotel didn’t catch fire (:


MD5? Really?

January 7, 2009

First let me say that this article is not meant to diminish the work that Alexander Sotirov et. all have been doing for the past 6 months.  It’s good work, has brought about some awesome results, and has demonstrated what was once a theoretical attack on PKI certificates based on MD5 hash collisions.  What I’m amazed at is that it had the impact that it actually did.


Configuring DNSSEC in BIND

August 1, 2008

DNSSEC, which I mentioned in my previous post about mitigation for Kaminsky’s recent DNS cache poisoning flaw, are the SECurity extensions for the Domain Name System (DNS). It essentially adds cryptography to DNS, allowing authoritative nameservers to cryptographically sign their zones and resource records, which in turn allows caching/recursive nameservers to verify them. This prevents attacks against the recent cache poisoning flaw by allowing the nameserver under attack to verify that a record it receives is valid by checking the cryptographic signature against the zone’s public key. Theoretically, an attacker would not be able to forge this signature unless the zone’s keys have been compromised.

I’ve spent a bit of time over the past few days researching DNSSEC, as it’s been standardized for nearly a decade now but there hasn’t been much adoption. It’s most likely The Best™ solution for the recent vulnerability, but I’ve heard time and again that it’s too complicated and has too many controversial issues surrounding it which is why many admins haven’t adopted it into their infrastructure and still don’t plan to.

During this research, I’ve configured all of my nameservers to use  DNSSEC, both authoritative and caching/recursive. While it is a bit of a pain on the authoritative side having to deal with signature expiration, key rotation, proving your identity and ownership of the zone to a domain lookaside verification (DLV) registry and providing your DLV records, etc., configuration for caching/recursive nameservers was relatively straight-forward and simple. While this will obviously only protect you from accepting spoofed, poisoned cache entries for records within zones using DNSSEC, why would you not want to at least verify signatures for those zones that do provide them?


The Information Security Industry is like the War on Drugs

August 27, 2007

After reading this article regarding the state of the IDS/IPS market and how IDS systems still and will likely have their niche, I was reminded of the common problem that plagues both Information Security and the War on Drugs; the majority of the focus is on detection and policing rather than on prevention and treatment, the former of which is usually an expensive, time-consuming, and futile battle.


Crack crack crack, all day long…

February 7, 2007

The other day while migrating data from my old Linux workstation to my new one, I came across a file that had my login credentials for both my personal account and the CAU team account over at If you’re not familiar with, it’s a massively multi-player (heh) encryption-cracking effort. By sheer force of numbers, they have in the past cracked crypto challenges for the RSA’s DES II-1 and DES-III challenges (they lost DES II-2 to the EFF), RSA Labs’ RC5-56 and RC5-64 challenges, the CS Communications & Systems cipher challenge, and others. The way it works is, you, the average computer user, download the client application (dnetc) and run it on your computer. You can configure it to only run while your screen-saver is on, or you can configure it to run in the background at all times. Either way, when your computer is idle, it will use those idle processing cycles to work on a chunk of crypto data that it has downloaded from the available work-pool at Essentially, it contributes to the community workload when you aren’t using your computer.


Vulnerability Disclosure, Cryptography Research, and Open Source

January 23, 2007

Today, Bruce Schneier posted an essay to his blog arguing the case for full disclosure of software vulnerabilities, which I am also in favor of. It’s apparently a side-bar to an article in CSOOnline entitled “The Chilling Effect” which is about some of the growing issues surrounding vulnerability research in web software. There’s also two other side-bars arguing the case for keeping vulnerability information secret or only telling the software vendors as well as the hybrid option that has sprung up in the last few years termed “responsible disclosure.”