[ARG] The Pizza Code Mystery

Black Mesa Archive The Cafeteria
#2941

That’s still possible, but I utilized the wrong input for that online decrypter–therefore, it’s unlikely that this is the case. I’m utilizing CrypTool 2 now, and I’ve got it set up so that when I plug in the key, I get outputs for every method of AES, Rijndael, DES and Twofish. It’s not all-inclusive, but it allows me to brute a good portion of the possibilities listed in Code_'s PM. I highly suggest it to anyone looking to do some serious decryption–the interface is easy to use, and the flow-chart representation is wonderful. Not to mention it cuts the work load of inputting into other decrypters by about 90%.

EDIT: We’re all frustrated, guys, but this isn’t really the place to get upset. Take it to PM if you want to duke it out :evil: :cursing:

#2942

Anychance of a dropbox save file for that, save everyone messing about with them.

#2943

Yessir!

Hex Code Attacks

#2944

And that’s the problem with this approach. This stuff is too technical, there are different cipher modes, IVs, key formats…
AFAIK we don’t even know it’s encrypted. The 64-bit padding may be just a coincidence, assuming we take the input as a sequence of hex digits, there’s just 1 in 16 chance of this happening randomly and there have been much bigger coincidences than this (both B32B003A and 35BADD66 are one less than a prime).

#2945

Exactly. My next project is to formulate some kind of dictionary attack utilizing all of the words pulled from every source of information. There’s just too many possibilities for keys, that determining the correct one is nigh impossible. Furthermore, with capitalization being a factor, we could spend generations on this and still not solve it.

#2946

I think we need to decrypt this in multiple levels. Perhaps we need to find/make additional hex code to add, or decrypt a portion at a time. Storm did say “how do you know this has anything to do with encryption”.

#2947

I think 247 has something to do with this. Just to recap, its found under the stair case in questionable ethics on the walls of the secret office-esque area. I think this is interesting as HALOS was programmed to send in level seven cases. QE is the 7th level bar the initial tram ride, and 247 is literally found under a staircase. Idk its just a hunch, but If i’m incorrect I think the number does have something to do with the ARG, it wouldn’t be there otherwise.

#2948

It’s possible, but I think the 247 just represents the order of the portals later in the game.

#2949

Oh, I didn’t realise that. My bad

#2950

Okay, so the first step of my plan is to create a word/phrase bank utilizing all of the clues directly from Storm or Code_. Once complete, I will post it to the blog and the Wiki.

There will be a direct section and an inferred section–AKA, one that utilizes words and phrases specifically posted by Storm/Code_, and another that is a list of inferred words or phrases from our study of the clues.

#2951

Thanks!

Some byte values can’t be represented as printable ASCII characters. The "3F"s are foreign question marks. AngelSG noticed the same thing a while back. I looked into it and noticed the same "?"s in a post by JeffMOD, where he had used this hex to string converter. This converter has a bug where it inserts "?"s wherever there are line feeds in the hex code input. This happens when you copy-paste the formatted hex from the wiki page, but not with the continuous hex string found in the original message.

I had a look at it and noticed that you’ve connected the text input box with the hex code directly to the cipher inputs. You need to insert a string decoder in between and set the input format to “Hexadecimal”. Otherwise you are decrypting the 752 ASCII code values of the individual hex digits.

From faed’s chat with stormseeker earlier this year, we know for sure that it’s encrypted, and that the message can be decrypted.

I share you concerns regarding the technical nature of this. Yet, a lot of evidence seems to be pointing towards a block cipher.

If we take the input as 376 bytes, then it’s 1 in 8 chance that the 64-bit alignment/padding is random, but it’s still small enough to make it hard to believe it’s random.

Those prime numbers are very peculiar, though, and I’m not sure what to make of that.

EDIT: But yeah, if those were coincidences, then I guess the 64-bit block multiple could also be a coincidence. Statistically, a 12.5% chance that any message has a length divisible by 8 is not a small chance at all. But it’s more of a feeling that it’s not a coincidence, and I’d like to think that it’s a clue in and of itself. /edit

The Benaloh/Paillier thing is still bugging me. What if the message was encrypted with a block cipher, but the key encrypted with Benaloh/Paillier and prepended to the encrypted message? But that’s even more technical and complicated.

#2952

Whoops! Good catch, flav. Hopefully it’s fixed now: Hex Code Attacks

Well, based on the block size of the hex code, the CrypTool2 analysis I have set up basically eliminates everything except AES, DES and Rijndael.

Took this from the Wiki page on AES:

AES is a variant of Rijndael which has a fixedblock size of 128 bits, and a key size of 128, 192, or 256 bits. By contrast, the Rijndael specification per se is specified with block and key sizes that may be any multiple of 32 bits, both with a minimum of 128 and a maximum of 256 bits.

Since our hex code is 3008 bits, this means that 32- and 64-bit block sizes are permitted–unfortunately, 128, 192 and 256-bit block sizes don’t fit. This might indicate that Rijndael is the way to go, as the key-size can be a multiple of 32, but no multiple of 32 between 128 and 256 fits into the 3008 bits of the code.

Therefore, I’m thinking that this could only be AES, DES or 3DES. Either that or it must needs be appended somehow.

Someone please correct me if I’m wrong, here.

#2953

AES has a block size of 128 bits, so AES doesn’t fit either, if it’s used in ECB or CBC mode.

However, there are other modes (e.g., CFB, OFB and CTR) that don’t require the last part of the data to be padded to a full block. This means that a block cipher of any block size could have been used, if it was used in any one of these modes. The length of the ciphertext would be the same as the length of the plaintext. However, this also means that, in this scenario, the 64-bit block multiple is simply a coincidence.

See https://en.wikipedia.org/wiki/Block_cipher_mode_of_operation for more info on block cipher modes.

CBC has been the most commonly used mode. But, in that mode, and any mode other than ECB, we have the IV to worry about as well.

#2954

A thought occurred to me. It’s still possible that we are supposed to use a 128-bit block size.

If you look at the full-text of HALOS.txt, after ASCII-85 decoding, it says “[End Transmission]|~[Abortive]” just after the hex code. However, the IRC clues usually ended with [Terminal]. Maybe this means something was went wrong with the transmission, so the last 8 bytes of the last block weren’t transmitted.

Since we are dealing with a block cipher, each block is encrypted independently, save for the affect of an initialization vector. But even in that case, the corruption of the last block shouldn’t affect any of the other blocks.

This reminded me of the wiki clue posted on the 752 hex code page, in the comments section. There is a comment that talks about the Tau Cannon. Everything but the last part is perfectly coherent (after filling in the blanks). Then the message becomes garbled, like it would if the last block was corrupted. After this, the message cuts out, as if it were halted midway through.

Storm keeps telling us to focus on the story. Maybe he meant the story, in the most basic sense, behind these clues.

EDIT: There’s more to support this theory:

First, in “Tempus omnia revelant,” there is a quote form Dante’s Inferno. After doing some background research, it seems that, while the quote itself is literally meaningless, in its original context, it is the very fact that it is meaningless that gives the line meaning. In our case, the incomplete block resulting from the transmission error implied by the implied by the “~[Abortive]” would result in a part of the decoded text being meaningless. However, it is the very fact that this text would be meaningless that would lead us to determining the block size.

Second, in the PM from Code_, it’s said multiple times that the encryption is probably using a 128-bit or 256-bit block size. That doesn’t make any sense with the 752 hex code as is, since it would only be 23.5 blocks of 128 bits. However, if we assume that the last half of the last block is missing, this would bring the code to a full 24 blocks of 128 or 12 blocks of 256.

#2955

Considering that the Wiki Quote looked incomplete, and it linking to the Tau Cannon, The Whiteboard c2a4x_labboard2 whiteboard, and the 21 into 1 seems to back up your theory, a few people even me said that the Hex was incomplete, and why Storm always stated Halos Code when he talked about it and not the 752 Hex code.

EDIT : Also with the 21 into 1, doing basic maths gives you 0.0476190476*, the 47 how ever jumps out at me, as its noted a few times, even turning up in the game on a few things as well.

#2956

@Gunsrequiem When you posted that Cryptographic Functions Page, i noticed that R4 was the only one that allowed 2048 bits, this correlated to the main whiteboard with the Cypher Notes on it found in the observation room in QE.

#2957

1/21 = 0.0476190476190476190…
It’s a repeating decimal.

Also, the crux of my theory isn’t that the hex code is incomplete, but rather that it probably has a 128 or 256 bit block size.

In theory, we should be able to identify the correct key by successfully decoding just the first block. That is, th first 16 or 32 hex values (32 or 64 characters), for 128 and 256 block sizes respectively.

This would require using a key of the same length (16 or 32 plaintext characters), unless some hash function is needed, but I haven’t found any clues pointing to that.

#2958

Remember, Storm posing under his pseudonym 0418_08151814, said:

"f I were a betting man, I would say this is a 256bit encryption, probably of the AES or Rjindael cipher algorithm (not that you can tell from the code, but its pretty common) ".

#2959

Technically speaking, a 256bit AES is identical to a 256bit Rjindael. The key length should be 32.

#2960

Regarding the OpenSSL comment/hint; this [stackexchange], and the link in the answer looked very interesting.

thought?

Founded in 2004, Leakfree.org became one of the first online communities dedicated to Valve’s Source engine development. It is more famously known for the formation of Black Mesa: Source under the 'Leakfree Modification Team' handle in September 2004.