Copyright Brian Starkey 2012-2014
Valid HTML 4.01 Transitional

Valid CSS!
iconGCHQ: Can You Find It? (2)max, min, close
23rd October 2013
Challenge 2(top)
The second challengeThe second challenge

This is what you get for challenge 2 - a directory listing containing a single file. The file is an RSA private key (I guess not that private any more):

Naively I tried but of course it wouldn't be that easy!

RSA Encryption(top)

I can't pretend to be even knowledgable about encryption, let alone an expert. Everything I know about RSA I learnt trying to crack these codes. Basically it relies on the fact that factorising very big numbers is rather slow to do on current computers.

The first thing I tried was to decrypt the ciphertext from challenge 1 using this key:

$ openssl rsautl -decrypt -in cipher1 -out plaintext -inkey comp1.key 
RSA operation error
139938077894464:error:0406506C:rsa routines:RSA_EAY_PRIVATE_DECRYPT:data greater than mod len:rsa_eay.c:584:
This made absolutely no sense to me, so I did some research. I also tried generating a public key from the private key, but that didn't work either. Can you tell I have no idea what I'm doing?

It turns out that data encrypted by RSA ends up as a chunk of data of a specfic length - and the length must be no greater than the length of the "modulo" parameter of the RSA key. I encrypted some random strings to see what happened:

$ openssl rsautl -encrypt -inkey comp1.key > encrypted.txt
$ wc -c encrypted.txt 
128 encrypted.txt
The wc command gives you a word count, though in this case I've asked it to tell me how many bytes are in the encrypted file - 128. This means that our encrypted data should be 128 bytes long. Remember this for later!

I noticed something fishy when I tried to decrypt the test files I had encrypted - openssl was throwing a wobbly. A little googling indicated that maybe the key was bad so I decided the RSA was a red herring and started looking at the key file itself.

A Solution (Base64)(top)

The key file is encoded as Base64 - a way to encode binary data as a printable string, so that you can stick it in an email or something similar. This is standard for RSA keys, but the "=" sign at the end is a dead giveaway.

There's a linux tool for decoding base64, handily called base64. If you strip the header and footer off the RSA key and pass it to base64 to decode, you get a bunch of binary garbage (which kills your terminal, btw), but you'll also spot some human readable (ish) text at the end. I ran the output through hexdump and grepped out readable things. Here's some commands to do it:

$ sed '1d' comp1.key | sed '$d' > tmp.b64
$ base64 -d tmp.b64 > tmp.out
$ hexdump -C tmp.out | grep -B3 -A3 --color=always --binary-file=text -E "([a-z]){3}"
Which gives some output which looks a little like this:
Almost readable outputAlmost readable output

The bit that should catch your eye here is (mostly) in red. Notice "ww.w" at the start? Kinda looks like a web address. If we correct for Endianness we get a lovely little URL: Yet again, a Turing vibe.

So there we have it, second challenge solved, second answer found (bletchley) and third clue located. On to Challenge 3!