Challenge 3 is a pretty nondescript series of characters. It's clearly a hexadecimal string - the numbers 0-9 and letters A-F representing values between 0 and 15.
2910404C21CF8BF4CC93B7D4A518BABF34B42A8AB0047627998D633E653AF63A873C\ 8FABBE8D095ED125D4539706932425E78C261E2AB9273D177578F20E38AFEF124E06\ 8D230BA64AEB8FF80256EA015AA3BFF102FE652A4CBD33B4036F519E5899316A6250\ 840D141B8535AB560BDCBDE8A67A09B7C97CB2FA308DFFBAD9F9
First things first - how long is it?
$ echo "2910404C21CF8BF4CC93B7D4A518BABF34B42A8AB0047627998D633E653AF63A873C\ 8FABBE8D095ED125D4539706932425E78C261E2AB9273D177578F20E38AFEF124E06\ 8D230BA64AEB8FF80256EA015AA3BFF102FE652A4CBD33B4036F519E5899316A6250\ 840D141B8535AB560BDCBDE8A67A09B7C97CB2FA308DFFBAD9F9" | wc -c 257
257 characters, including one for EOF, so that's 256 characters, or if you convert the hex to binary (2 characters per byte) that's 128 bytes. Hmmm, I'm sure we've seen 128 bytes somewhere before.
As soon as I noticed this I knew exactly what to do - the 128 bytes were meant to be decrypted with the key from Challenge 2; they just had to be! Unfortunately I got hung up on a few details, and the actual decryption took me forever.Endianness(top)
Remember how the web address in Challenge 2 was all mixed up? My first attempts to decrypt the clue failed with similar messages to the ones I was getting when I tried before: "data greater than mod len", "no inverse" and so on and so forth.
I was still (rightly) convinced that the ciphertext was encrypted using the RSA key, but I thought that maybe the ciphertext had been jumbled - just like the web address before. So I tried all kinds of endianness conversion, switching bytes round, switching nibbles round, reversing the byte order in 32 and 64 bit chunks, reversing the whole string and all of the permuations of the above.
This took forever, and I had made absolutely no progress. Most of this came from the fact that I know very little about RSA encryption, so I was flying blind with regards to what should work.RSA Key Check(top)
Eventually, I learnt about some options for openssl which would let me inspect the contents of the key. (That would have been really useful for Challenge 2 -_-). With the -check option, we get all sorts of interesting stuff:
Private-Key: (1022 bit) modulus: 37:c0:04:af:3e:8e:80:cb:75:b1:53:0c:9f:b2:dc: ... b0:ac:94:13:82:39:51:f1 publicExponent: 65537 (0x10001) privateExponent: 13:5b:5d:85:07:60:6d:41:b7:9c:99:2c:61:ea:b5: ... 04:29:e8:b4:b1:69:7b:2d prime1: 37:c0:04:af:3e:8e:80:cb:75:b1:53:0c:9f:b2:dc: ... 70:6c:53:d2:41:f9:3b:e4 prime2: 77:77:2e:77:68:74:73:69:73:69:6c:67:75:6f:65: 63:74:73:72:65:68:73:72:69:2e:65:6f:63:75:2e: 2f:6b:6c:62:74:65:68:63:65:6c:20:79:20:20:20: 20:20:20:20:20:20:20:20:20:20:20:20:20:20:20: 20:20:0b:8f exponent1: 13:a5:24:9d:fc:2e:52:20:40:1b:50:f9:3e:65:80: ... b2:8a:b2:4f exponent2: 08:79:f2:58:12:97:40:a1:18:c9:40:21:cf:19:4a: ... a4:c4:e1:4d coefficient: 14:89:f3:4e:c0:0e:91:ab:96:dd:ca:dd:d5:77:f1: ... 95:82:ff:d8:54:c0:99:3f RSA key error: p not prime RSA key error: n does not equal p q RSA key error: d e not congruent to 1 RSA key error: dmp1 not congruent to d
I've truncated the output, except for prime2... The 77s at the start and the 20s at the end looked a little too convenient to be a big prime number. Lo and behold, if you convert it to an ASCII string: ww.whtsisilguoectsrehsri.eocu./klbtehcel y, which is of course the web address I found by hand in Challenge 2. That really would have been useful before... none of this hacking around with base64. Anyway, I digress.
So the key check told us that the RSA key is garbage - the primes aren't primes, the products don't add up... it's a mess. That's OK though, Wikipedia says "The private key consists of the modulus n and the private (or decryption) exponent d," the other bits are just "nice to haves" to aid in the encryption/decrpytion/key generation process.The Solution(top)
So, now we know what's wrong with our key, we need to find something which can decrypt using the modulus and the private exponent. A little googling turned up a Python app which was just the ticket.
So, it decrypted to:
0x20 0x20 0x20 0x20 0x20 0x20 0x20 0x20 0x77 0x77 0x2e 0x77
0x68 0x74 0x72 0x65 0x67 0x65 0x73 0x69 0x65 0x74 0x2e 0x72 0x6f
0x63 0x75 0x2e 0x2f 0x6b 0x6e 0x65 0x67 0x69 0x61 0x6d 0x30 0x32
0x33 0x31 0x20 0x20 0x20 0x20 0x20 0x20 0x20 0x20
If you do this sort of thing a lot, it's easy to recognise 0x20 as the character code for space, and 0x77 as 'w'... Another web address!
A few lines of Python:
>>> s = "0x20 0x20 0x20 0x20 0x20 0x20 0x20 0x20 0x77 0x77 0x2e 0x77 0x68 0x74 0x72 0x65 0x67 0x65 0x73 0x69 0x65 0x74 0x2e 0x72 0x6f 0x63 0x75 0x2e 0x2f 0x6b 0x6e 0x65 0x67 0x69 0x61 0x6d 0x30 0x32 0x33 0x31 0x20 0x20 0x20 0x20 0x20 0x20 0x20 0x20" >>> chars = s.split() >>> plaintext = '' >>> for c in chars: ... plaintext = plaintext + chr(int(c, 16)) ... >>> plaintext ' ww.whtregesiet.rocu./knegiam0231 '