Mon, 26 Dec 2011

Short key IDs are bad news (with OpenPGP and GNU Privacy Guard)

Summary: It is important that we (the Debian community that relies on OpenPGP through GNU Privacy Guard) stop using short key IDs. There is no vulnerability in OpenPGP and GPG. However, using short key IDs (like 0x70096AD1) is fundementally insecure; it is easy to generate collisions for short key IDs. We should always use 64-bit (or longer) key IDs, like: 0x37E1C17570096AD1 or 0xEC4B033C70096AD1.

TL;DR: This now gives two results: gpg --recv-key 70096AD1

Some background, and my two keys

Years ago, I read dkg's instructions on migrating the Debian OpenPGP infrastructure. It told me that the time and effort I had spent getting my key into the strong set wasn't as useful as I thought it had been.

I felt deflated. I had put in quite a bit of effort over the years to strongly-connect my key to a variety of signatures, and I had helped people get their own keys into the strong set this way. If I migrated off my old key and revoked it, I'd be abandoning some people for whom I was their only link into the strong set. And what fun it was to first become part of the strong set! And all the eyebrows I raised when I told people I was going meet up with people I met on a website called Biglumber... I even made it my Facebook.com user ID. So if I had to generate a new key, I decided I had better really love the short key ID.

But at that point, I already felt pretty attached to the number 0x70096AD1. And I couldn't come up with anything better. So that settled it: no key upgrade until I had a new key whose ID is the same as my old key.

That dream has become a reality. Search for my old key ID, and you get two keys!

$ gpg --keyserver pgp.mit.edu --recv-key 0x70096AD1
gpg: requesting key 70096AD1 from hkp server pgp.mit.edu
gpg: key 70096AD1: public key "Asheesh Laroia <asheesh@asheesh.org>" imported
gpg: key 70096AD1: public key "Asheesh Laroia <asheesh@asheesh.org>" imported
gpg: no ultimately trusted keys found
gpg: Total number processed: 2
gpg:               imported: 2  (RSA: 1)

I also saw it as an opportunity: I know that cryptography tools are tragically easy to mis-use. The use of 32-bit key IDs is fundamentally incorrect -- too little entropy. Maybe shocking people by creating two "identical" keys will help speed the transition away from this mis-use.

A neat stunt abusing --refresh-keys

Thanks to a GNU Privacy Guard bug, it is super easy to get my new key. Let's say that, like many people, you only have my old key on your workstation:

$ gpg --list-keys | grep 70096AD1
pub   1024D/70096AD1 2005-12-28

Just ask GPG to refresh:

$ gpg --keyserver pgp.mit.edu --refresh-keys
gpg: refreshing 1 key from hkp://pgp.mit.edu
gpg: requesting key 70096AD1 from hkp server pgp.mit.edu
gpg: key 70096AD1: public key "Asheesh Laroia <asheesh@asheesh.org>" imported
gpg: key 70096AD1: "Asheesh Laroia <asheesh@asheesh.org>" not changed
gpg: Total number processed: 2
gpg:               imported: 1  (RSA: 1)
gpg:              unchanged: 1
gpg: no ultimately trusted keys found

You can see that it set out to refresh just 1 key. It did that by querying the keyserver for the short ID. The keyserver provided two hits for that query. In the end, GPG refreshes one key and actually imports a new key into the keyring!

Now you have two:

$ gpg --list-keys | grep 70096AD1
pub   1024D/70096AD1 2005-12-28
pub   4096R/70096AD1 2011-03-11

There is a bug filed in GNU Privacy Guard about this. It has a patch attached. There is, at the moment, no plan for a new release.

A faster attack, but nothing truly new

My friend Venkatesh tells me there is an apocryphal old Perl script that could be used to generate key ID collisions. Here in the twenty-first century, l33t h4x0rz like Georgi Guninski are trying to create collisions.

In May 2010, "halfdog" posted a note to the full-disclosure list that generates PGP keys with chosen short key IDs. I haven't benchmarked or tested that tool, but I have used a different tool (private for now) that can generate collisions in a similar fashion. It takes about 3 hours to loop through all key IDs on a dinky little netbook.

You don't have to use any of these tools. You can just rent time on an elastic computing service or a botnet, or your own personal computer, and generate keys until you have a match.

I think that it's easy to under-estimate the seriousness of this problem: tools like the PGP Key Pathfinder should be updated to only accept 64-bit (or longer) key IDs if we want to trust their output.

My offer: I will make you a key

I've been spending some time wondering: What sort of exciting demonstration can I create to highlight that this is a real problem? Some ideas I've had:

Publish a private/public key pair whose key ID is the same as Phil Zimmerman's, original author of PGP
Publish a private/public key pair whose key ID is the same as Werner Koch's, maintainer of GNU Privacy Guard
Publish a set of public keys that mimic the entire PGP strong set, except where I control the private key of all these keys

The last one would be extremely amusing, and would be a hat-tip to some work discussed in Raph Levien's Google Tech Talk about Advogato.

For now, here is my offer: If you send me a request signed with a key in the strong set, I will create a 4096-bit RSA public/private key pair whose 32-bit key ID is one greater than yours. So if you are 0x517DD4E4 I will generate 0x517DD4E5.

I will post the keys here, along a note about who requested it, and instructions on how to import them into your keyring. (Note: I will politely decline to create a new key whose 32-bit key ID would create a collision; apologies if your key ID is just one away from someone else's.)

P.S. The prize for best sarcastic retort goes to Ian Jackson. He said, "I should go and create a lot of keys with your key ID. I'll set the real name to 'Not Asheesh Laroia' so everyone is totally clear about what is going on."

[/debian] permanent link and comments

Learning baritone again (for the Russian Nonsemble)

In fifth and sixth grade, I used to play the baritone horn. A few weekends ago, I played a show with the Russian Nonsemble. Look for me in a blue shirt and tie:

When I joined the Brighton public school system in fifth grade, other students had been playing musical instruments for a year. I tried a few different options, and I settled on the baritone. Maybe I really liked the sound, or how buzzing works with a mouthpiece and combines with the entire horn. Maybe I was suggestible and accepted something that the band needed.

I learned the instrument on bass clef, which was its own oddity. It was a little confusing to use bass clef in band and treble clef in chorus, but I managed. (Maybe this exercise taught me something about the concept of equivalence.)

There is something relaxing about playing the baritone: I am not keeping the melody. The tone quality I send out is not, at least in a fifth grade band, make or break the performance. One downside is that, with the highly repetitious lines, it can be easy to get lost.

Early in the sixth grade, our band director asked for volunteers to learn the French horn. Steve Marler picked it up for the musical challenge. I picked it up because I was willing to fill an institutional need.

It was a lot of fun to play French horn. Well, it was a challenge, at least. Every single group performance setting I had for the French horn -- from sixth grade through high school, through the Johns Hopkins concert band -- there was someone sitting next to me who was a full notch better at me. It was disheartening, to be honest.

I stopped playing horn somewhere in college. For a while I played mellophone in the Johns Hopkins pep band, but that wound down eventually.

About a year ago, my friend Irina invited me to be part of a band, for which she lent me a baritone.

Halfway through the concert you see above, I began to do more than just read the music. I listened to the sound of the band and looked at my bandmates, making bom-pom sounds on the horn while bobbing up and down with the rhythm of the song we were playing.

Thanks to Jess Schumann for taking the picture!

[/music] permanent link and comments

Sat, 17 Dec 2011

Computer fraud and abuse by Universal Music Group

It seems that Universal Music Group willfully misrepresented its copyright interest and probably violated its service contract with YouTube. By my understanding of the Computer Fraud and Abuse Act, UMG likely took actions that exceed authorized access, subjecting it to criminal prosecution. (I am just a computer enthusiast and not a lawyer, so I welcome corrections from others.)

The emerging details, reported by Wired.com's Threat Level blog, are as follows:

YouTube said Friday that Universal Music abused the video-sharing site’s piracy filters when it employed them to take down a controversial video of celebrities and pop superstars singing and praising the notorious file-sharing service Megaupload.

In particular, Google created a system for antipiracy that is being abused by UMG:

“Our partners do not have the right to take down videos from YT unless they own the rights to them or they are live performances controlled through exclusive agreements with their artists, which is why we reinstated it,” Google-owned YouTube said.

I look forward to a speedy criminal prosecution of the employees or board of Universal Music Group. If that is not feasible, perhaps the organization itself should be put behind bars.

Even if Megaupload.com fails in its own lawsuit against UMG, I eagerly await the criminal prosecution of UMG as in another case where Federal prosecutors had to get involved.

[/corporations] permanent link and comments

Mon, 12 Dec 2011

Twisted high scores

Living in the Boston area, I've had the chance to spend time with the lovely maintainers of the Twisted project.

Twisted is an event-driven network programming framework in Python. It's also a community of people for whom software is never good enough -- and they're right.

I visited the Twisted November sprint at the Smarterer.com office a few weeks ago and reviewed a ticket. So now I am on the Twisted high scores list for November!

It was one of the most rewarding short periods of time I've ever spent contributing to an open source project. I took someone's contribution and turned it into a patch, and also gave some feedback. This counted as reviewing a ticket, for which I was immediately and strongly socially rewarded: J.P. (exarkun) turned to me and say, "Thanks for contributing to Twisted. An IRC bot pinged me with a note saying my ticket review was complete. And now I appear in the high scores list for November!

[/software] permanent link and comments

Mon, 05 Dec 2011

Vertical

After the November Python Project Night, Noah and I unlocked our bicycles.

[/bike] permanent link and comments

Mon, 28 Nov 2011

The OOT Killer

Commitments require care, and recently I have been suffering from the delusion that making more commitments will make me more able to achieve them.

When overcommit reaches a certain point, the OOT (out of time) killer comes and reaps time from whatever it finds, often with disappointing consequences.

(See also: OOM Killer.)

[/debian] permanent link and comments

Thu, 10 Nov 2011

How To Put Corporations in Jail and Prison (draft)

In the U.S., some crimes carry jail or prison terms for the persons who commit them. Some of the persons who commit these crimes are so-called "natural persons" -- people like you and me. Some of them are corporations. This brief essay explains how and why to apply prison sentences to these artificial persons.

I am not a lawyer. I do live in a country with laws, and I worry that these "artificial persons" can skirt the law by being structured to avoid jail time. So I propose this draft, and I am interested in feedback.

1. A brief summary of jail and prison

First, let us review life for natural persons when they are convicted of a crime with a prison term. Prisoners may find themselves in a minimum-security institution, where they are given some small degree of autonomy, limited (but non-zero) access to communication systems like postal mail, telephones, and in-person visits, and are put to work. Persons who commit violent crimes and constitute a risk to other inmates may be incarcerated in a medium- or high-security facility; in these, inmates are carefully tracked and intensive barriers and check-points prevent too-great movement.

It can be disruptive for a person to find himself or herself behind bars, but it is a disruption that the legal system is willing to make so that the public can enjoy a law-abiding society.

Life in prisons is still life: inmates may always eat, drink water, think to themselves, and (as far as I know) make written notes to themselves. Many famous activists have spent time in jail or prison and gone on to continue their careers. Prisoners in low-security facilities may enjoy lots of communication with other persons, so long as it does not require the use of communication technology.

Persons spending time in prison may continue to own property outside of the prison. Their ability to use it while incarcerated is minimal to nonexistent, but they may have bank accounts, investments, or other financial instruments that appreciate in value.

2. How the structure of corporations makes law enforcement harder

Now that we have a concept of what prison is like, let us carefully consider what it means to be a corporation. Corporations are legal constructions, created to achieve a specific end. They have a primary place of business where individual natural persons meet to do work to help the corporation achieve those ends. Most corporations are created for the private profit of their founders.

The corporation is, fundamentally, a legally-approved veil over the collective activity of individual persons. This corporate veil limits the financial liability for its Directors; if the corporation owes rent on its property, for example, the Directors are not responsible personally for this debt. Virtually all actions of corporations are about the transfer of money. The existence of this structure is widely-considered a good, efficient thing.

Some actions of a corporation go beyond the transfer of money; some actions are criminal. At the moment, individual natural persons who commit crimes as part of their duties to the corporation may find themselves in court and possibly in jail. This can flow all the way up the chain to the Directors.

But if an employee is asked by her manager to commit a crime for the private inurement of the corporation, she is the one most at-risk for criminal proceedings. If a corporation profits from check fraud, the fines may be smaller than the profits earned.

The incentives are mis-aligned: if an investor calculates that the financial punishment for breaking the law will not hurt the corporation, he might urge the corporation to flout the law. The result might be dramatically increased profits with a side-effect of an employee or a Director in jail.

There is an elegant solution to this problem: when an agent for the corporation commits a crime with a jail term, the corporation should spend some time incarcerated as well. This brings us to the final part: the mechanics of applying jail and prison terms to corporations.

3. How to put companies behind bars

Rather than painstakingly identify the employees most responsible for lawbreaking within a corporation, it may be simpler to put the corporation behind bars. Practically speaking, this means moving the primary place of business of the corporation to a jail or prison.

In this regime, when a company is in jail, the employees must go to the jail and subject themselves to the standard restrictions of the jail as they go about their business. If the company has committed a violent offense (perhaps the calculated murder of citizens who live near its place of toxic waste dumping), then while employees are contributing their time to the corporation, they would be subject to highly-secured perimeter fences and close supervision.

Just like a natural person, the corporation can continue its life while in prison. It may have limited access to communication technology, but (depending on the security level of the facility) employees will be able to take notes on paper, send checks in the mail, plan the corporation's future actions, and possibly attend meetings with each other. If this is not enough to maintain the corporation's activities, it should have considered that before committing criminal acts.

One downside to this system is that as corporations are increasingly convicted of crimes, their employees could fill up our already-stretched prison capacity. This, and other practical problems, are easy to address if you consider the spirit of this proposal. The restrictions of prison life could be applied by sending jail wardens to corporate headquarters, where employees are scrutinized and restricted under the same rules as they would be in prison. The warden can be responsible for ensuring limits on communication technology use are enforced.

It can be disruptive for a corporation to find itself behind bars, but it is a disruption that the legal system should be willing to make so that the public can enjoy a law-abiding society.

[/corporations] permanent link and comments

Thu, 03 Nov 2011

Work on important problems

A friend pointed me to a transcript of Richard Hamming's motivational speech, "You and your research." In the speech, Hamming (the famous inventor of the Hamming code, an early and vital error-correction algorithm) discusses points that make a researcher generate important results for the field. (~~I think it was Blake who sent me the link.~~ I seem to have no idea how I found it initially.)

I'll now take a moment and mis-quote Hamming, pretending he's giving advice to activists rather than scientists:

If you do not work on an important problem, it’s unlikely you’ll do important work. It’s perfectly obvious. Great activists have thought through, in a careful way, a number of important problems in their field, and they keep an eye on wondering how to attack them. Let me warn you, ‘important problem’ must be phrased carefully. The three outstanding problems in physics, in a certain sense, were never worked on while I was at Bell Labs. By important I mean guaranteed a Nobel Prize and any sum of money you want to mention. We didn’t work on (1) time travel, (2) teleportation, and (3) antigravity. They are not important problems because we do not have an attack. It’s not the consequence that makes a problem important, it is that you have a reasonable attack. That is what makes a problem important. When I say that most activists don’t work on important problems, I mean it in that sense. The average activist, so far as I can make out, spends almost all his time working on problems which he believes will not be important and he also doesn’t believe that they will lead to important problems.

He tells great stories, and you should read the transcript. Here, however, is a summary of his points:

A handful of people do excellent science repeatedly. It does not boil down to pure luck (though luck does remain important). Courage and hard-work are huge factors.
As you grow older, you will be tempted to only work on large problems. Instead, Shannon urges us to "continue to plant the little acorns from which the mighty oak trees grow."
Necessity is the mother of invention. When you have a resource constraint, you will be forced to address it, perhaps in a novel and generally-useful way.
Be committed to your research question, not your current results. Take note of the places where your data disagree with your theory. You'll need those places later.
When you see a good attack, drop everything and focus on it until you find out if it will work.
If you work with your office as an open door, within a decade you will know where the field has moved-to in a way that closed-door workers will not.
When solving a problem, consider how it can be "characteristic of a class" of problem rather than just one isolated problem.
You must become good at presenting ("selling") your work as well as your motivations.
Avoid the personality defect of wanting total control. This prevents other people from helping you. Generally, learn how to use the system. That includes being willing to appear to conform.
Avoid the personality defect of excessive ego assertion. "Which do you want to be? The person who changes the system or the person who does first−class science?"
Gain the personality boon of seeing the positive side of things, even constraints. Especially self-set constraints.
Know thyself.

The Q&A, and the full speech, get the blood pumping. Give it a read.

[/reflection] permanent link and comments

Sun, 23 Oct 2011

RFBP: Request for birthday present/package

There is a program that I love: bb.

bb is a demo of the famous ASCII Art library, aalib.

     dT8  8Tb     
    dT 8  8 Tb    
   dT  8  8  Tb   
<PROJECT><PROJECT>
 dT    8  8    Tb 
dT     8  8     Tb

bb is a demo-scene-type program that shows how awesome automatic ASCII art is. The personalities of the people who made bb shine through. It's surely one of my favorite programs in Debian, up there with alpine. It's been in Debian since 1998.

bb has a serious bug, however: BB's "graphics" freeze when music starts.

Here's the issue.

bb uses libmikmod to play sound.
Back in the twentieth century, many of us thought it would be cool to have applications play sound through a system service called EsounD. To enable that, the libmikmod maintainers added the ability for libmikmod to send audio to that daemon.
libmikmod detects if your system uses esound, and if so, sends sound there by default.
libmikmod's esound support is broken, and bb half-crashes (as per #123150) when it gets used.
Today, nearly everyone's sound output goes through pulseaudio, which supports ALSA as well as the old esound protocol for backwards-compatibility.

So if your system (like most GNU/Linux systems) uses pulseaudio for sound, then bb is broken. That means every Ubuntu user and most desktop Debian users can't use it.

There are a few possible fixes, depending on where you'd want to solve the problem. If you just want bb to run on your own machine, without recompiling anything, you can adjust pulseaudio's configuration (in /etc/pulse/default.pa) to disable esound support. If you want to do that, just comment out this line:

 load-module module-esound-protocol-unix

We could also possibly patch bb so that it asks libmikmod not to use its esound "support."

I think the smarter thing to do is to adjust libmikmod. Since its esound support seems to be just plain broken, it should be removed. At very least, it should not be the default when ALSA output is available. There is a new upstream release of libmikmod, maybe the esound output is fixed.

In Debian, libmikmod is orphaned. When a package is orphaned, it means that a new person must step in and adopt the package. Debian packages need ongoing care and commitment to fix issues and make changes like this that benefit the users.

In this case, you'd need to understand some C and be willing to maintain a shared library. Maintaining a library in Debian requires attention to detail, but it is quite doable. Since you would be adopting an existing package, most of the work is already done for you. I would also be quite willing to answer questions. If you're not a Debian developer, I would happily sponsor uploads of this package into Debian so that the fixes are part of the distribution.

So: who will maintain libmikmod and fix bb? Could it be you?

It would make a really great birthday present if the amazing bb program worked in the next Debian release. Leave a comment if you have questions or are interested!

P.S. In a pinch, I can be convinced to maintain libmikmod myself, but I think this is a great opportunity for someone new to Debian to make a big difference.

[/debian] permanent link and comments