From the Canyon Edge -- :-Dustin

Monday, January 26, 2009

Darker Ubuntu theme for screen-profiles

As requested, there is now an ubuntu-dark theme for Ubuntu's screen-profiles. This allows you to choose between light-on-dark, or dark-on-light colors for the window panel and the status panel across the bottom of your screen.

Make sure you have at least screen-profiles_1.15-0ubuntu1, which you can retrieve from:
And then run:

$ select-screen-profile

Select a screen profile:
1. plain
2. ubuntu-light ---- recommended
3. ubuntu-dark

Choose: 1-3 [2]: 3
If your terminal is also configured for light-on-dark, or if you're on a tty console, your screen should look something like this:

Thanks to Tyler Willingham for the suggestion and the patch/branch in Launchpad.


Friday, January 23, 2009

Daemon Challenge 3: We have a winner!

I'm pleased to announce that Robert Escriva is efficient, and the winner of Daemon Challenge 3. I shipped him my final copy of Daemon by Daniel Suarez.

There were 4 other successful submissions. In order of submission:
  1. Robert Escriva
  2. Dave Walker
  3. Neil Shepperd
  4. David Langton
  5. Chris Oattes
My sincere congratulations to all of these gentlemen!

I'll describe the solution below. Both Robert and Dave will be posting their own description of the solution to their blogs. Make sure you check out their explanations as well!

The Solution

For this challenge, I gave you 3 files, an encrypted challenge_3.txt, an encrypted wrapped_passphrase, and a snippet of an md5 shadow entry. I also told you that the wrapping passphrase was 4 alphanumeric characters long. Your goal was to decrypt the contents of challenge_3.txt and solve the riddle inside.

The wrapping passphrase in Challenge 3 is one character longer than the wrapping passphrase in Challenge 2. In the solution of Challenge 2, we roughly estimated that it would take ~40 days to crack a 4-character passphrase.

However, that was using ecryptfs-unwrap-passphrase to do the testing.

In Challenge 3, you have one more extremely valuable piece of have the md5sum of the wrapping passphrase.

Now this is where I made a big goof... In the original post, I mistakenly published the md5sum of the passphrase PLUS the trailing "\n" character. I had to issue an update to the challenge (see the big red text in the Challenge 3 text).

This is an important lesson, though. Be very careful with trailing slashes and hashing algorithms. That one, mostly-invisible character yields very different results. This has bitten many people many times.

There is a bit of synchronous irony in that I made this mistake within about 10 minutes of the Obama/Roberts presidential oathe gaffe :-) We all make mistakes!

So once you had the correct shadow file, you could attack this problem in one of 3 ways:
  1. Using ecryptfs-unwrap-passphrase, trying all 62^4 (14776336 unique passphrases), we estimated last time that this would take ~40 days. If you could split this among enough CPU's, you may be able to reduce this down to a day or two
  2. Using john-the-ripper
  3. Building a table of the md5sum's of all 14776336 passphrases
You can read the documentation on john, if you like, as it is an interesting tool. But for purposes of this solution, I'm going to demonstrate approach (3).

So let's generate that map with a script like this:

CHARS="a b c d e f g h i \
j k l m n o p q r s t u v \
w x y z A B C D E F G H I \
J K L M N O P Q R S T U V \
W X Y Z 0 1 2 3 4 5 6 7 8 9"
for i in $CHARS; do
for j in $CHARS; do
for k in $CHARS; do
for l in $CHARS; do
md5=`echo -n "$i$j$k$l" | md5sum`
echo "$i$j$k$l $md5"
My laptop can crank out about 7000 of these per second. So this should only take about 35 minutes to generate the complete table. You could also add an if-statement in there to spit out the matching passphrase, testing against the md5sum I gave you in the shadow file. And, again note that you could easily split this search across multiple CPUs for parallel scaling.

Using this script, you should easily be able to determine that the wrapping passphrase is "GaM3". Looking back, you'll notice that the username I gave in the shadow file is "sobol". In the book, Matthew Sobol is the dead, game developer who designed the Daemon, which is wreaking havoc on the world in the story.

So using "GaM3", you can unwrap the wrapping-passphrase and perform the eCryptfs mount, as described in the solution to Challenge 2.

Doing so, you will be able to view the riddle:
Start with the sha512sum of the following seed:
$ echo "Daemon" | sha512sum
Write the computed sum to the first line of a new file.
sha512sum that new file.
Write the resulting sum to the second line of the new file.
sha512sum that new file.
Write the resulting sum to the third line of the new file.
Continue doing this until you have exactly 1,000,000 lines in the file.
Hint: the first two lines of this file should be:
Take the last 6 digits of the 1,000,000th line, and the first six digits of
line 961,325.
Take the difference of these two numbers.
Convert that difference from hex to decimal.
Who's number is this?
Alright! So now you just need to write a simple shell script, right? Perhaps something like:


sha=`echo "Daemon" | sha512sum - | awk '{print $1}'`
echo $sha > /tmp/sums
while [ $i -lt 1000000 ]; do
sha=`sha512sum /tmp/sums | awk '{print $1}'`
echo $sha >> /tmp/sums
i=`expr $i + 1`
Nice, now watch your sums grow. It will crank through $i pretty first. But note that with every run /tmp/sums is getting bigger. Every run is harder than the previous. Eeeek!

Let's see how long the 1,000,000th run will take... A single sha512sum is 128 characters, plus a "\n", so we need a file that is 129,000,000 bytes long.

$ dd if=/dev/zero of=/tmp/foo bs=1000 count=129000
s=1000 count=129000
129000+0 records in
129000+0 records out
129000000 bytes (129 MB) copied, 0.327751 s, 394 MB/s

And let's time how long it takes to sha512sum that entire file:

$ time sha512sum /tmp/foo
d8b81aa1485ad47faa38a9f6595556be9edcade0c3a077226773200ae91e9c71e897ef42b9ddb68e3d401ea079b5c5a6961bb50bf611f27832be8398aae3f898 /tmp/foo
real 0m0.817s

Nearly a second! That's going to add up. The early sums are going to take less time, and the later ones will take more. We can roughly estimate that average run will take about half of the longest, and we can multiply that average by the 1,000,000 times we need to do it. That's somewhere around 4 days on my laptop.

The way this problem is designed, this would be very difficult to parallelize. Every subsequent calculation builds on the previous, so we cannot split it up very easily.

However, every subsequent calculation builds on the previous, and this is something we can very much use to our advantage!

In the shell script above, each call to sha512sum starts over from scratch. This is completely wasteful!

And now we're back to the title of the challenge, How efficient are you?

Every time we perform the calculation, we just have a small new delta, a little bit of data added to the end. I would have been far more cruel, had I asked you to prepend the data, but in appending it, I gave you a tremendous chance for optimization!

So with each run, you can build on the work of the previous run, rather than starting over from scratch. You can take advantage improve both your CPU and memory utilization.

Here's a small Python script from Kees Cook, who, by the way, solved each of these challenges ahead of their release, as my 1-man QA team :-)

import hashlib, os, sys

m = hashlib.sha512()
digest = m.hexdigest() + "\n"

m = hashlib.sha512()

out = file('growing.sums','w')
top = 1000000
for i in range(0,top):
digest = m.hexdigest() + "\n"
if (i % 100) == 0:
print "%d %0.1f\r" % (i, i * 100 / top),
In less than 30 seconds, this script will generate precisely the same output that the shell script above will produce 4 days later! Amazing, huh!

I know that both Robert and Dave found their solutions in a similar manner. Dave wrote his script in Perl. I'm looking forward to reading their solutions on their blogs!
With your output of all 1,000,000 sums, the two lines you're looking for are:


Strip out the specified portion and calculate:
561093-da7080 = 845FED
Convert that to decimal, and you get: 8675309.

This number happens to be a rather large prime number, and a twin-prime at that! Prime numbers are the basis for public-key cryptography.

As to "who's number is this?", well, perhaps that takes a bit of knowledge about pop culture. If you enunciate each digit, you should hear it pretty clearly...

Eight - Six - Seven - Five - Three - Oh - Niiiiieeeeeiiiiiine

And if you still don't get it, Google and Wikipedia will promptly point you to Tommy Tutone's hit song of 1982, "Jenny".

Thanks so much to everyone who participated in these challenges! It was a lot of work for me to put together, but a lot of fun, too. I will try to do something like this again, perhaps after the Jaunty release. I'm working on filename encryption in eCryptfs now, that might give me a whole new approach to challenges ;-)

Finally, let me once again thank Kees Cook for all of the time and CPU cycles he spent helping me refine these problems. Kees is one in a million!

And also, thanks to Daniel Suarez and his publishers for donating the hardback copies of Daemon. These guys have been very appreciative of grass roots promotion in the blogosphere.

Daniel emailed me back in September (after my initial blog post reviewing the book). He said:
Daniel Suarez (aka Leinad Zeraus)

Cheers to that Open Source Community!

Wednesday, January 21, 2009

Musica Now Supports mp3, ogg, flac, wav!

I have previously blogged about Musica--a web application that provides browsing, streaming, and downloading your music over http/https. At the time, Musica only supported indexing of MP3 files.

Several readers of my blog requested support for FLAC and OGG files. I agreed to hack this up, they opened bugs: Bug #313408 and Bug #288839.

I rolled out musica-1.4 last week, which now contains support for MP3, FLAC, OGG, and WAV files. The code changes were actually really minimal. If you're interested in seeing the PHP modifications, refer to:

You should be able to install the binaries on Hardy, Intrepid, and Jaunty.

Obligatory screen shot:

Note the sample artist, Jeff of the funniest guys I know! Head over to where you can listen to this album for free, and buy it if you like it. My Mom's Van is my favorite ;-)


Tuesday, January 20, 2009

Daemon Challenge 3: How efficient are you? -- UPDATED!

As described in previously in my blog, this is the final of three Daemon Challenges.


Daemon Challenge 3: How efficient are you?

  2. Download the materials:
    • challenge_3.txt - eCryptfs underlying data
    • wrapped-passphrase - an eCryptfs wrapped passphrase file
    • shadow - an md5sum passphrase hash
      UPDATED: The original shadow file I gave was INCORRECT. I inadvertently generated this by passing the passphrase PLUS the carriage return to md5sum. Tisk tisk tisk. I'm SO sorry. I have uploaded an updated shadow file to that link. My apologies for the confusion.
      This UPDATED, CORRECT hash was generated by stripping the trailing carriage return, using:
      echo -n "$PASSPHRASE" | md5sum -
    • HINT: Given this password hash, you may crack the wrapping password, using john-the-ripper, or a similar tool. Or, if you want to brute-force attack the wrapped-passphrase, it may be helpful to know that it is exactly 4 alphanumeric characters. You may want to refer to the solution of Challenge 2.
    • HINT: You will need to set up GPG email encryption in order to submit your answer. See:
  3. Your goal is to solve the riddle and precisely follow the instructions in the decoded challenge_3.txt file to submit your answer.

Good luck,

Thursday, January 15, 2009

The Science Fair 20 Years later, and a Belated Thank You








Daemon Challenge 2: We have a Winner!

So it turns out that Adam Greig is persistent, and the winner of Daemon Challenge 2. I shipped him a copy of Daemon by Daniel Suarez (another copy sent off to the UK).

There has been only 1 other successful submission at this point, and that's by Dave Walker.

My sincere congratulations to both Adam and Dave.

I'll describe the solution below. This information will likely be useful in solving Daemon Challenge 3. I recommend working through it, if you intend on competing in the next challenge.

The Solution

I told you that the wrapped-passphrase file contains a 128-bit mount passphrase, encrypted using a wrapping passphrase. This perfectly mirrors a normal Encrypted Private Directory setup in Ubuntu, where your login passphrase is used as a wrapping passphrase.

You can use the ecryptfs-unwrap-passphrase utility to (attempt) to unwrap a wrapped passphrase file.

Clearly, trying to brute-force attack the mount passphrase is impractical. That's 2^128 combinations that need to be tested. That's 3.4 x 10^38. A very big number indeed.

The login passphrase, clearly, is the weaker link, and easier to attack. And I gave you two significant hints. I told you that it consists entirely of alphanumeric characters, and that you could break it within 48 hours. There are 62 unique characters among [A-Za-z0-9]. But you do not know the length. A simple calculation, though can narrow that search.

First, let's get a feel for how many password attempts you can make per second. Let's just see how long it takes to try 100 passwords. I don't expect any of these to succeed. I'm only interested in the rate.

$ time seq 1 100 | xargs -i ecryptfs-unwrap-passphrase wrapped-passphrase {} 2>&1 >/dev/null
real 0m23.487s
user 0m21.481s
sys 0m0.180s
Okay, so I was able to attempt 100 passphrases in 23 seconds. That's about 4.3 attempts per second.

So for each of the following passphrase lengths, let's see how long it would take to test the entire keyspace:
  1. 62 / 4.3tries/sec = 14 seconds
  2. 62*62 / 4.3tries/sec / 60sec/min= 15 minutes
  3. 62*62*62 / 4.3tries/sec / 60sec/min / 60 min/hour = 15.4 hours
  4. 62*62*62*62 / 4.3tries/sec / 60sec/min / 60 min/hour = 40 days
So there is our break point! Based on my clue, you should know that the passphrase is 3 or fewer characters long.

I'm going to take this opportunity to re-enforce the importance of having a high quality passphrase! Let's do this calculation one more time, with a larger set of valid characters, [a-zA-Z0-9~!@#$%^&*()-_=+[]{}|;:'",<.>/?]. That should add about 30 characters. So instead of 62, we have 92 valid characters. Let's also hope that your login passphrase is at least 8 characters long. In this case, we have:

92*92*92*92*92*92*92*92 / 4.3 / 60 / 60 / 24 / 365 = 37 million years

That should take a bit longer ;-)

Now, that 4.3 number was very conservative. There's a few ways we can increase our number of tries per second--primarily through parallel processing.

Let's assume you can crank through the 1- and 2- character long passphrases, and you do not get a hit (you won't).

Let's write a script that will generate every 3-character alphanumeric passphrase:

for i in $CHARS; do
for j in $CHARS; do
for k in $CHARS; do
echo "$i$j$k"

Run that script and output it to a file.

$ ./ > /tmp/passphrases
$ wc -l /tmp/passphrases
238328 /tmp/passphrases
Okay, so we have 238,328 passphrases we need to test. So you could start crunch through these at this point, in a single thread, on a single system. But most laptops these days have multi-core cpu's. And you might even have access to multiple machines.

I have 8 dual-core machines running Ubuntu at my immediate disposal. I'm going to run my 2 instances of my cracking thread on each of these systems. So I'm going split that passphrase file into 16 equal parts (14896 passphrases per file).

$ split -l 14896 /tmp/passphrases
$ ls x*

Yeah, the split command has some wierd idiosyncrasies. There are better ways of doing this, but split is simple, and fast.

Now, I need a small script to attempt the passphrase cracking. This script will take one of our generated passphrase files as an input argument. It will try each of those, printing a status message to screen (to track progress), and will exit 0 if/when it finds a correct passphrase. Note that I also have it send an email message to me. I customized that to send me a text message via SMS to my cell phone ;-)

passphrases=`cat $INPUT`
total=`wc -l $INPUT`
for p in $passphrases; do
ecryptfs-unwrap-passphrase wrapped-passphrase "$p" 2>&1 >/dev/null
echo "FOUND: $p"
echo "FOUND: $p" | mail
exit 0
i=`expr $i + 1`
echo "($p) $i / $total"
exit 1

So now, copy this script and two of these input files to each machines. You could use something like puppet to send this information to each system. I didn't mind starting each of these individually, with:
$ time ./ xap2 | tee /tmp/out
And, in less than hour, one of the processes hit the winner:
Sweet, now, let's decrypt the mount passphrase:
$ ecryptfs-unwrap-passphrase wrapped-passphrase 9zD
Unable to read salt value from user's .ecryptfsrc file; using default
So there's the mount passphrase! Also, let's look at that warning message briefly... I also gave the hint in the challenge that we're using the default eCryptfs salt. For added security, you should always consider adding a salt to such passphrases. There's a simplicity/complexity trade off. Just something you should consider in your own environments and use cases.

Now, we can use that mount passphrase to establish an ecryptfs mount, and view the contents of challenge_2.txt.
$ mkdir /tmp/1 /tmp/2
$ cp challenge_2.txt /tmp/1
$ sudo mount -t ecryptfs /tmp/1 /tmp/2
Select key type to use for newly created files:
1) pkcs11-helper
2) openssl
3) passphrase
4) tspi
Selection: 3
Select cipher:
Selection [aes]: aes
Select key bytes:
1) 16
2) 32
3) 24
Selection [16]: 16
Attempting to mount with the following options:
Mounted eCryptfs
And we can view the contents of challenge_2.txt:
$ head -n 5 /tmp/2/challenge_2.txt
Challenge 2:
What is the full name of the research partner of a cryptographer who's first name matches the name of a dog on a tv show which has featured a vessel named after the video game played in a movie filmed near the largest city served by the United States telephone area code matching the greatest prime factor of the number of the asteroid named after the person possibly killed by a squeamish ossifrage?
Answer: ?
Page down a bit, if you want the solution to this riddle. Or don't go below here, if you want to try and solve it for fun :-)

As tempting as it might be to start at the beginning or somewhere in the middle, it's easiest if you start at the end.
  1. "squeamish ossifrage" is a tribute to the RSA crypto cipher challenge Ron Rivest posed in 1977. The answer to his challenge was, "The Magic Words are Squeamish Ossifrage"
  2. An ossifrage is a lammergeier or bearded vulture, Gypaetus barbatus (note the "ae" dipthong)
    Legend says (hence the 'possible') that the Greek Aeschylus playright was killed by one of these scary birds dropping a stone on his head. (Again, note the "ae" dipthong.)
  3. Asteroid 2876 is named after him
  4. 719 is the greatest prime factor of 2876
    Prime factors are the basis for most modern cryptography!
  5. Area code 719 serves greater Colorado Springs, CO
  6. A number of movies were filmed in the Colorado Springs area
    But one movie should really stand out to any hacker...WarGames! If it doesn't immediately jump out at you, you might need to do some thinking and research :-)
  7. Dig around for some trivia about the movie, if you don't remember it clearly enough. You'll find that Matthew Broderick had to practice his skills at Galaga quite a bit for the role and the scenes where he plays the game in the film.
  8. Some basic research on Galaga (one of the best arcade games ever!) should reveal that the submarine in Lost is actually named in honor of the game, as the writers of that show love the game too ;-)
  9. I'm a big fan of Lost, so I know that there are a couple of dogs that make appearances here and there. But there's certainly one that's been around the longest, and that's Vincent.
  10. There are probably more than one cryptographer named, 'Vincent', but at least the first page of Google, when searching for 'vincent cryptographer' is dedicated to Vincent Rijmen.
  11. Vincent Rijmen is the co-inventor of the AES encryption algorithm, which is at the core of eCryptfs.
  12. And his research partner, co-inventor of AES, is Joan Daemen
And that's your answer, Joan Daemen! Hopefully you'll appreciate the great irony, that this challenge deals in cryptography, eCryptfs uses AES, and we're doing this in honor of the book, Daemon.

The Next Challenge

So the next challenge will build upon this one. I recommend working through some of the exercises on this page and getting comfortable with them.

Additionally, to submit your answer to the final challenge, you will need to use GPG email signatures and encryption. Your public key will need to be hosted on a PKI key server, such as, or even on

Good luck!


Wednesday, January 14, 2009

Ubuntu Jaunty Testing: screen-profiles

On December 14, 2008, I posted about screen - the window manager for the Ubuntu Server.

A lot has happened since then, mostly over the Christmas and New Year's holidays.

With the help of Nick Barcet (and contributions from several others, including Dave Walker, Jamie Strandboge, Nicolas Valcarcel, and Marc Deslauriers), we have a new package in Ubuntu Universe for Jaunty: screen-profiles.

I'm quite proud of what we've accomplished thus far with the package--we're bringing some bling to the Ubuntu Server.

Across the bottom, we have panel displaying a three-color logo, the Ubuntu release, a notification that a reboot is required (@), 77! updates are available, the current system load is 0.27, the system has 2 cpu's, currently running at 800MHz, 3.9GB of memory, the current date and time. All of this in less than 80 characters.

Above the status panel is another panel, showing the open windows in the current screen session. You can see that I have 4 windows dedicated to: root, screenbin, screen-profiles, and Daemon.

This is intended to communicate some of the same information available in the upper and lower panels on your Ubuntu desktop.

Nick has created the excellent screen-profiles configuration utility, accessible by pressing F9.

From the Help screen, you can see the hotkeys we have defined within this custom screen profile, to help navigate among your windows.

Beyond the Help screen, there are several other functions available on the main Menu.

These are intended to help you customize and improve your screen experience.

I find the last option most interesting. Here, you can toggle screen-by-default. If you turn this on, each time you ssh into your system, or open a new terminal on your desktop system, you automatically launch into a screen session (reconnecting to an existing one if available). I'm enjoying this feature quite a bit!

Call for testing!

At this point, we're looking for some testing and feedback. Please file bugs at:
Based on that feedback, I'm going to push a Main Inclusion Report for screen-profiles, and add screen-profiles to the Ubuntu Server Seed.


Tuesday, January 13, 2009

Daemon Challenge 2: How persisent are you?




Daemon Challenge 2: How persistent are you?

    You can:
  2. Install ecryptfs-utils
  3. Download:
    • challenge_2.txt - eCryptfs underlying data
    • wrapped-passphrase - an eCryptfs wrapped passphrase file

Good luck,

Monday, January 12, 2009

screenbin - like pastebin, but for screen

Just before Christmas, Mark Shuttleworth posed a question to our development team. He asked us think about how we could leverage Ubuntu instances in the Amazon EC2 cloud in the course of our daily development practices.

I had a jump-start on that question, in that I had already been thinking about it for several weeks.

To answer Mark's challenge, I created a script that I call screenbin.

Most of us that use IRC on a daily basis are familiar with 'pastebin', such as For those that are not, a pastebin is a website that allows people to paste large dumps of code or text data, and then share simply by referencing a URL. It's handy in IRC and instant messaging, where people generally abhor large dumps of text being pasted and overrunning their IRC buffer.

Pastebin has become an incredibly valuable tool for collaborative communication and development. It's key that the data shared via pastebin is non-confidential and volatile (able to be discarded at any time).

Thinking about Amazon's EC2, I'm particularly intrigued with the "throw-away" nature of instances. A given instance is useful for some period of time, and then it's trivial to destroy that instance, and pay your ~$0.10 tab for 1 hour's usage.

I also noted the asynchronous limitations of pastebin. For real-time collaborative editing, you can use something like Gobby. But what if you want to do more than simple document editing? What if you and your Agile Development practices dictate that you need to do some extreme programming or paired programming with a buddy halfway across the globe? Or you need to do a demo, some education, instruction, or peer code review? Maybe some collaborative debugging? Or even mentoring?

Of course, you can use a shared GNU screen or VNC session. This necessitates exchanging keys or passwords, though, and allowing that sort of access over the Internet. Most of the time, our personal or corporate firewalls prevent this sort of access for very good reasons. And even when it doesn't (or can be opened), allowing such access can be a bad idea!

But then there's that "throw-away" nature of EC2. In a matter of seconds, you can instantiate a brand new, pristine and clean Ubuntu instance in EC2, add the additional packages you need. You can point your collaboratives to a publicly accessible hostname/ip and get to work. When you're done (or should something go south, such as the machine becoming compromised), you can pull the plug and destroy the instance in a second. You can do all of this without necessitating any changes in your network infrastructure or firewalls.

This is the magic that screenbin provides!


You must have an active EC2 account and the userspace utilities installed. For instructions, see:


I have packaged it for Ubuntu, and I hope that it will make into Jaunty Universe soon. For now, it's available in my PPA:


Once you have installed screenbin, you could use it like so:
$ screenbin --guest kirkland --guest mathiaz --packages "ubuntu-desktop" --ec2-keypair ~/.ssh/ec2-keypair.pem

screenbin will use Launchpad to retrieve the guest users' ssh keys, so the value of --guest should be a valid Launchpad id. And it will try to retrieve a public key from $HOME/.ssh/*pub. In this case, you would be sharing a screen session among yourself, as well as kirkland and mathiaz.

It will install the specified additional packages on the instance, and install the guest users' ssh keys.

Then, you and each of your guests can ssh to the public hostname/ip address and each of you should be logged into a shared screen session.

Upcoming features

Please provide feedback and feature requests in Launchpad as bugs at:


Wednesday, January 7, 2009

Daemon Challenge 1: We have a Winner!

Thanks to everyone who participated in Daemon Challenge 1!

And the winner is...

I'm pleased to announce that Michael Bryant is the winner of the first challenge, clocking in with the correct answer at about 7 minutes past noon!

Congratulations to Michael. I'm shipping a copy of Daemon to the UK for Michael ;-)

I would also like to recognize the following participants who correctly solved the first challenge (in order of correct submission):
  1. Michael Bryant
  2. Greg Auger
  3. Adam Greig
  4. David Futcher
  5. Thomas Thrainer
  6. Vincent Bakker
  7. Kay Bieri
  8. Flávio Martins
  9. Ted Smith
  10. Martijn Cielen
  11. Alexander Gabriel
  12. James Tait
  13. Eric Hammond
  14. Jeremy S
  15. Pedro Silva
  16. Michele (Macno) Azzolari
  17. José Luis "Artir" Ricón
  18. Dave Walker
  19. David Langton
The Solution...

I've said several times that Daemon is a great book, and I'm happy to host this contest to support Daniel's first book. In running the contest, I'm also hoping to make more people aware of Ubuntu, security, and specifically our open source encrypted filesystem, eCryptfs.

This first challenge, "Is there anybody out there...", was mostly about generating some interest in the book and the contest, and hopefully getting a few new people using Ubuntu Intrepid Ibex's Encrypted Private Directory feature, which I've spent quite a bit of time developing.

The solution to the first challenge is quite simple... Once you've followed the Encrypted Private Directory setup instructions, and mounted your private directory by logging out and back in, you can obtain your mount options and remove your signature as I described with:

$ x=`grep "$USER.*Private.*ecryptfs" /proc/mounts | awk '{print $4}' | sed 's/sig=[0-9a-f]*,/sig=xxx,/'`
$ echo $x
Then, you can obtain the md5 message digest of $x with:
$ echo $x | md5sum
da9ae8f980ec845914220cfe727a8b16 -
The value, da9ae8f980ec845914220cfe727a8b16, is then used as the symmetric key to decrypt the challenge text file:
  • $ gpg challenge_1.txt.gpg
Once this text file is decrypted, you could see a very simple riddle:
Challenge 1:
Leinad_Zeraus : Daniel^Suarez
Nitsud_Dnalkrik : ???????????????
Daniel Suarez originally published Daemon under the pseudonym, Leinad Zeraus, which, of course, is his name spelled backwards.

Unfortunately, my backwards-name isn't nearly so cool ... 'Nitsud Dnalkrik' sounds more like a scrubbing agent used aboard Russian spacecraft ;-)

The Next Contest

I hope there's even more participation in the second challenge, due to be published next Tuesday.

It should be more difficult, will likely involve Ubuntu, eCryptfs, gpg, and actually cracking passwords/passphrases, as well as a more difficult embedded riddle.


Monday, January 5, 2009

Daemon Challenge 1: Is there anybody out there?




Daemon Challenge 1: Is there anybody out there?

    You can:
  2. Set up an Encrypted Private Directory.
  5. Obtain the MD5 message digest of $x
    • Learn more about gpg

Good luck,