So I have no idea whether I am still chasing shadows as it seems I was when looking at the Colossus picture (see Is there a hidden stage? ), but I’m instinctively unhappy about the RSA private key file from Stage 2.
Here’s the source of my discomfort: clearly the file was manually manipulated to include the secret information (i.e. the solution to stage 2, see Stage 2 but that information was encoded into the Prime2 field of the RSA private key. It appears though that some of the other fields have been updated too, and it’s not clear why. It’s not as if there’s a need to “protect the integrity” of the key file itself - the tampering with prime2 does that all by itself, and renders the key unusable by openssl for a straight encrypt of the data in Stage 3.
You can see the details of the information in the keyfile by typing this command:
openssl rsa -in comp1.key -text
Note how the modulus (first field) is 128 bytes (1024 bits) long. Now in the RSA calculation, the modulus is equal to prime1 * prime 2, which means that (notwithstanding the fact that prime2 has been tampered with) we’d expect prime 1 to be approximately 64 bytes/512 bits long. It isn’t - it is also 128 bytes in length. Why is that? Now I suppose (without understanding the full rules of RSA key generation) that the “original” prime2 could have been a very small prime, say 2 or 3, and thus prime1 could still be 128 bytes in length, but if that were the case then you’d expect to be able to show that (and to find the original prime2) by dividing modulus by prime1. If you do this, you find that prime1 it is not an exact factor of modulus, (there’s a remainder) so one of them has indeed been tampered with (in addition to the tampering of prime2).
The mystery deepens if you look a little more closely at the data: approximately the first half of both prime1 and modulus are the same!
Now if I am indeed chasing shadows this was simply a quick cut-and-paste job by the bods at GCHQ to create a keyfile of approximately the right size, etc, but it does seem more than a little odd.
I’ve been plugging away at these two fields trying to understand what additional information - if anything! - is encrypted there. I’ve looked at the “additional” data in prime1 (i.e. the data beyond the duplication point with modulus), I’ve looked at the same trailing part of the modulus field, I’ve tried subtracting one field from the other, I’ve looked at each field in it’s entirety, and in each of these cases I’ve done simple hex->ascii and UTF-8 (i.e. viewing the data as text), I’ve done a BASE64 conversion, and I’ve tried to decrypt the data using the private key itself as the key (as per Stage 3), and THEN done an ascii/utf-8/BASE64 conversion. In no case am I able to find a hidden message.
So - am I chasing shadows still? It would be nice to know!