Stormseeker once told us that he had given us a hint somewhere when someone complained that the puzzle was impossible to solve. At that point in time, the “21 goes into 1” or “21 into 1” had not yet been discovered, but the “21 goes into 1” hint had already been sitting undiscovered in a file in a folder on stormseeker’s site for several months (according to the last-modified timestamp of the file). A few more months went by and then “21 into 1” appeared on the wiki. It’s likely that this was the hint Stormseeker was talking about. Since he repeated it on the wiki, it must be important.
If we go by the idea that this hint is supposed to tell us something about the enciphering method or the exact cipher we are dealing with, without spelling it out like he did with the SECOM puzzle, then it’s possible that “21 goes into 1” somehow relates to a specific step (or part of a step) being performed by a cipher, a step that’s unique to a specific cipher. One such step could be a permutation in a block cipher where bits are shuffled around according to a predefined permutation table.
The realization that “21 goes into 1” must be referring to an operation, as opposed to being a property of something (like the number of characters or bytes in a key), came recently when I came across a post by @JohnNotJohn where he pointed out the thing about the subject-verb agreement of “21 goes into 1”. I started thinking about it again last week when “21 into 1” was mentioned in the thread again, and I posted the very generic idea about “something in position 21 that goes into position 1”. And while I was thinking about what that could mean my first thoughts were that it could be some kind of bit or byte mapping, and it occurred to me that that’s exactly what’s being done in many block ciphers, specifically block ciphers that uses permutations as part of the enciphering process.
And so I went looking for block ciphers that had a predefined permutation that would map a bit number 21 from an input to bit number 1 in the output. And I found such a mapping in the Lucifer cipher.
I’m not going to describe the inner workings of the Lucifer cipher in too much detail, but at the core of the Lucifer cipher algorithm there is a one-way function called the F-function, which is performed in each round of the encipherment. For each block of plaintext the cipher performs 16 rounds of encipherments, and each round uses a subkey that is generated according to a key schedule.
The last step in the F-function is a bitwise permutation of 64 bits (8 bytes). As described on https://www.quadibloc.com/crypto/co0401.htm, the permutation is being done according to the following table:
10, 21, 52, 56, 27, 1, 47, 38,
18, 29, 60, 0, 35, 9, 55, 46,
26, 37, 4, 8, 43, 17, 63, 54,
34, 45, 12, 16, 51, 25, 7, 62,
42, 53, 20, 24, 59, 33, 15, 6,
50, 61, 28, 32, 3, 41, 23, 14,
58, 5, 36, 40, 11, 49, 31, 22,
2, 13, 44, 48, 19, 57, 39, 30
This is basically a lookup table that tells us for each bit of the output which bit to fetch from the input. For example, the first number in the table corresponds to bit number 0 of the output bit array (as stated in the description, the bits are numbered starting from 0). The number 10 is the positional number of the bit to fetch from the input bit array. So basically bit number 10 of the input bit array goes into bit number 0 of the output bit array. The next number is 21, which means bit number 21 of the input bit array goes into bit number 1 of the output bit array. Continuing, bit number 52 of the input goes into bit number 2 of the output, and so on.
However, this is not exactly how it’s described in Sorkin’s original description of the cipher (https://www.fuseki.com/lucifer.pdf). In Sorkin’s description, the permutation is performed on one byte at a time. But in the description at https://www.quadibloc.com/crypto/co0401.htm it looks like they have combined the permutation step with the diffusion step, which spreads the permuted bits across eight bytes.
TL;DR: “21 goes into 1” could be a reference to a specific bitwise permutation that being used by the Lucifer cipher algorithm.
Well, the passphrase “laseroptroniclinearinducercannon” used in the SECOM puzzle was longer than the 20-character requirement of the SECOM cipher, so we can’t rule out that the key is based on a phrase that’s longer than the keysize of the cipher.
There’s a Java implementation here made by some students: https://www.cs.rit.edu/~ear7631/crypto/
I found some old C implementations a while back as well. I’ll see if I can find the links to them.
Somehow, I doubt it would be that simple, but we should try the most obvious keys first, I guess.
We can just pad the code with 8 zero bytes at the end (or simply delete the last 8 bytes). If we were to successfully decrypt the code, the last block will be corrupt (missing), but maybe that’s how the puzzle was designed. This could be what the “[ABORTIVE]” means. Maybe that’s also what the LOL Cannon message, which was corrupted/interrupted in mid-message, was meant to tell us.
EDIT:
Actually, the original grilled pizza message said “congratulationsyouwonthePIZZA”, without the word “have”.
There are some ciphers that have variable key lengths, for example, Blowfish with key lengths of 32-448 bits. Also, the stream cipher RC4 (or ARC4), which has been widely used with SSL/TLS, can use keys lengths of 32-2048 bits.
Another idea: Maybe one passphrase was encrypted using a second passphrase, and the result used as key for the actual message.
