This is a "canonical" answer meant to move the hints and partial results out of the question, as well as present a unified description of the solution and explain some of my thoughts about the puzzle.
Warning, unmarked spoilers ahead!
First Layer
Hieroglyphics
I called the symbols at the bottom of the initial image "hieroglyphics." Here they are, magnified:
Colors
The colors are supposed to hint that the image needs to be separated into its three color channels: red, green, and blue.
Red Key
The key indicates that the red channel holds a key used in another part of the puzzle.
Blue Boxes
The four hollow boxes represent four parts of an image encoded in this channel. The fact that they are hollow is supposed to indicate that this picture is not the 'real' solution.
Green Lock and Boxes
There are three groups of symbols here.
- The first, a lock, indicates that the green channel is encrypted, and needs the key from the red channel.
- The solid boxes are supposed to indicate the 'real' (high-resolution) pieces of the image from the blue channel.
The check mark signifies verification. The solid box over the check is supposed to indicate that one part of the image is somehow part of the verification process.
- Finally, there are three pairs of hollow and solid boxes. These represent three cover images (hollow boxes) which each hide another part of the solution (solid boxes).
Most of the hints in the hieroglyphics were not necessary, so this part wasn't solved/explained in full. However, I'm glad I included it, since it reduced the number of extra hints necessary to zero; which, in my mind, is the mark of a good puzzle. (OK, this isn't totally true, but more on that later.)
Color Channels
Each one of the three color channels in the image encodes a different file.
To decode, you just need to take the 8-bit image values for each pixel and write them to a file. There are no extensions, but you can figure out the file types from their magic bytes using a utility like file. (Or just use a hex editor; the Ogg files begin with Ogg, and the encrypted file begins with -----BEGIN PGP MESSAGE-----.)
This part was solved by LeppyR64 .
Not all the files were the same length, so I had to pad out the two shorter ones. Fortunately none of the formats mind having extra junk appended to them. I padded the files using random bytes drawn from the same distribution as the rest of the file, so that there wasn't an apparent change in color or texture.
Second Layer
Blue Channel
The blue channel contains an audio file: blue.ogg (504 000 bytes)
This audio file contains a voice reading the sentence, "if you haven't found any clues yet, here's what you should be looking for." This is followed by an SSTV image of the playing cards mentioned in the question.
This part was also solved by Leppy64.
The intent was that this image should provide an overview of the four pieces that need to be found. However, I underestimated how well the image could be recovered, meaning that the puzzle can be solved without finding the four hidden pieces. If I were to do this again, I would have added extra noise to make identifying the cards impossible.
Red Channel
The red channel contains an audio file: red.ogg (504 000 bytes)
The audio file in the red channel contains morse code, which reads as follows:
VVV CLG PUZ CLG PUZ DE RBC = GA VY FB SFR = IF U CNT MAKE KEY SIGN TI83 PUB KEY ES POST SIG, I WL POST KEY = USE PKCS1 N PADDING = 73 ES GL PUZ DE RBC <BK>
I made heavy use of morse-code-specific abbreviations in order to shorten the message, making it a bit challenging to read. Here it is in plain English:
(VVV) [attention] Calling PUZ, calling PUZ, this is RBC. Good afternoon, very fine business [good job] so far. If you can't make the key, then sign the TI83 public key and post the signature, I will post the key. Use PKCS#1, but no padding. Best regards and good luck; PUZ, this is RBC, over.
This is followed by a long series of DTMF tones, encoding the following sequence:
65537#10279922920444758952198236835097069960343622366001203286574422344156143529924117113239897731294792673018741448270384194591460111562322538604975737399705241*11337130627295915340299728600099026395063941250029823456400750546429518737269225761911696211987509755865509636756944318366919520522935654742514845464086299
They are (in decimal) the public exponent $e$ and primes $p$ and $q$ of an RSA secret key. They are followed by my voice reading the words "Echo, Papa, Quebec" (EPQ in the NATO phonetic alphabet, identifying the three numbers), surrounded by Quindar tones (because I'm a huge geek).
The morse code describes an "alternate route" I put into the puzzle. It took me quite a bit of effort to obtain a PGP private key from the information above. I eventually resorted to using RFC 4880 (which describes the PGP message format) to create the key by hand in a hex editor:
-----BEGIN PGP PRIVATE KEY BLOCK-----
lQHaA1VfT04AAAEEAKX3IOHDBljU7bCSqBGXQBt6fyxiJO9kEbjfJGzMSSbu7Uq7dW3NKUtotZ54
JOa/RpF8E1StBQ8N4L7rYbdTfYNL8hMV4eSxXD6EcV4ezKBv3fiKfROarCLEeWhbg5tG+EZM52bb
6P5OZaTGtucr+sj2st2Qq0Ttnw/1l/ReCMkjABEBAAEAA/0QocRve3jeXBr5z/38d/jaXXCd2l6z
MtxnzMznWPhCaOfqI6vFS4MbkIHAQMVfQ8SRqH/TbjIMln/IV5Rc/TFIVsN/+6thU8ddbuQL6jeE
h+HMKiYmAtnXNfDfb3QVZikh4sYkrOBRws0zE9UVsAtobIppT1gE+INlfpSr6fmFsQIAxEc3b88q
TU8DhAyD9osjIC8IH4VhofApVwPfJYqWuP1syMswdVjWDL1pKkXtJBQ3A0nii63w8YBBn8HfLNh+
mQIA2Ha9fEljuMBvFI2lBNH3x7myCnGaDTeI6sx+/6esucwgDvOhiin7XHM9ReBBBO8+f8d/PshH
UmsMXVBQai9HGwH7BEv1GeXZ6yL4eKC4jBvcdqRM/tuiSZodqIZBSQ8BaQG7X6m1IEL5pH8EXhr7
LWcruhlYtSIMBREid82G/p0SPZ+StQA4U3RhY2sgRXhjaGFuZ2UgVXNlcnMgKGh0dHA6Ly9wdXp6
bGluZy5zdGFja2V4Y2hhbmdlLmNvbSk=
-----END PGP PRIVATE KEY BLOCK-----
However, Jarnbjo actually managed to construct the key in software using the Bouncy Castle crypto library, avoiding the need for the alternate route.
The "alternate route," was supposed to be for someone to use the provided key to sign a known piece of data. This requires the computation of $d$ (the private exponent), the number such that $e\times d \equiv 1 \bmod {\varphi(n)}$. The signature of a message $m$ is then just $c=m^d \bmod n$. These computations (modular inverse and modular exponentiation) are "easy" (computationally efficient) if $\varphi(n)$ is known. Given the factorization $n=p\times q$, then $\varphi(n)=(p-1)(q-1)$.
The plan was that if someone provided the value of $c$ by performing the above calculations (or equivalent)—proving that they understood what the key meant and how to use it—then I would provide the PGP key file I made.
However, there were some complications:
- I needed a (preferably large) message for the puzzle solvers to sign, and didn't have a lot of space left. So I chose the TI83's signing key's public modulus as a large, publicly-known number that is connected to cryptography.
- When GPG generates keys (and I generated this key with GPG) it actually computes $d$ as $e^{-1} \bmod {\operatorname{lcm}(p-1,q-1)}$, as recommended by the PKCS#1 standard. It's been a while, so I don't remember if GPG complained when I tried using the other definition of $d$ or if I just didn't know the two are interchangeable (they both have the property that $m^{e\times d}\equiv m\bmod n$), but I thought it was necessary to convey this information to the puzzle solvers.
- Finally, PKCS#1 also specifies padding and hashing algorithms used when computing signatures, which I didn't want the puzzle solvers to have to use if they wanted to go the alternate route, so I specified "no padding" in the puzzle.
Overall the "alternate route" was a pretty bad idea, and one of the two major flaws in this puzzle. This clue was very confusing (particularly my use of morse abbreviations) and ultimately unnecessary.
As for why I included it: this was the first puzzle I had posted, so I didn't yet have a good idea of the interaction between the puzzle maker and puzzle solvers (namely that the puzzle solvers would say if they were having trouble and needed a hint). I was also possessed by an extreme desire to make the puzzle totally-self contained with no "extra" hints whatsoever.
Also, I probably should have gotten someone with better enunciation to do the reading in this puzzle. =)
Green Channel
As I mentioned before, jarnbjo successfully decrypted the green channel's PGP stream using the private key values listed above. If you want to do this yourself without installing the JDK or Bouncy Castle library, you can use the PGP key above with GnuPG.
Third Layer
Decryption of the PGP stream results in a compressed directory (green.tar.bz2 (361 213 bytes)). It contains pictures of my three cats (because, why not?) in three different formats. Each hides one quadrant of the image of playing cards. Each also contains a comment which is a hint as to how the playing cards are hidden.
allie.jpeg
download original (81 938 bytes)
This image contains the comment:
The "middle child" of our cats, Allie is quite shy as well as a real pushover. This uses the same trick as the tiff image, but slightly harder.
The clue says that this one is harder, because it's more difficult to spot; but technically it's pretty simple. Quark found that if you delete the file's header and open the file, the lower-left quadrant of the playing card image is revealed:
This image is actually stored as an EXIF thumbnail. A quick side note: JPEG is not a file format, it is actually the name of a compression algorithm/image encoding. JPEG-encoded images are usually stored in a JIF (JPEG Interchange Format) file. In the language of video encoding, JPEG is the codec and JIF is the container—as an analogy, an AVI file (the container) might hold an H.264 video stream (the codec).
To make things even more complicated, there are two commonly used, mutually-incompatible, extensions of JIF: JFIF (JPEG File Interchange Format) and EXIF (EXchangeable Image File format). They both have the capability to store a thumbnail of an image, either uncompressed or as a complete, self-contained JPEG image.
In this case the thumbnail is stored (JPEG-compressed) in a JFIF container, which is itself the thumbnail of the outer EXIF container. Since the thumbnail is stored as a complete, self-contained JFIF image it can be viewed by moving it to the front of the file (or scanning the file with a tool like JPEGsnoop). I embedded the thumbnail with ExifTool, available with most Linux distributions.
bitsy.tiff
download original (141 085 bytes)
This image contains the comment:
Bitsy, our oldest cat, is the heaviest of the three by far. I thought it fitting that she should get the most bloated format in this challenge.
Quark noticed that, in Windows Explorer, the thumbnail of this image is the upper-left quadrant of the playing card image. Jarnbjo found that by deleting the TIFF headers and image data, the remaining part of the file can be opened as a JPEG image:
download original (43 875 bytes)
The TIFF (Tagged Image File Format) specification is a real monster to work with. It was originally designed to be a "universal" format to replace the raw formats used by various camera and scanner manufacturers. In practice, this meant that the specification had to encompass pretty much all of the commonly-used encoding methods—hence the joke that TIFF stood for "Thousands of Incompatible File Formats."
TIFF encodes an image's metadata as a list of tags called an Image File Directory (IFD) that describe an image. These tags usually contain small bits of information about the image (e.g. the resolution, color type, where the image data is located in the file, etc.) but they can also point to other IFDs describing other images. This facility is used to allow TIFFs to encode multi-page documents, or (in this case) to embed a thumbnail of the image.
Although TIFF is usually used to hold losslessly-compressed image data, JPEG compression is allowed in a "Baseline" TIFF (meaning that all TIFF readers are required by the standard to support it). However, when exporting as a lossy TIFF, GIMP (my photo editor of choice) didn't allow me to change the compression settings (so I couldn't get the image as small as I wanted). So, I used the huge flexibility of the TIFF format in the way it was intended: I put the two JPEG files (actually JFIF files, remember?) together, and then appended a hand-written TIFF header constructed to point into the data sections of each JPEG. This has the added "benefit" that the two images are each complete, self-contained JPEG files that you can examine and extract (optionally with a tool like JPEGsnoop).
porsche.png
download original (137 079 bytes)
Quark found that by deleting the first half of the image, the upper-right quadrant of the playing card image is revealed.
Nothing too clever here. The hidden image is also a PNG, and it is simply appended to the main image. The main challenge was getting the filesize small enough while retaining detail. You can see some pretty heavy banding and speckling in the cover image.
There was supposed to be a comment on this image too, but I apparently forgot to add it. The original copy of the embedded image has the comment "Told you it was pretty dirty..." (but it looks like this comment went missing in the final version?), so it was probably something along the lines of "Porsche, our youngest cat, is a real trickster. So, this image is hidden with a dirty trick." It was almost exactly a year ago when I made this puzzle, so I don't quite remember.
Second-and-a-half Layer
The third layer yielded only three of the four pieces of the playing card image. To find the fourth, we have to go all the way back to the heiroglyphics:
The check mark signifies verification. The solid box over the check is supposed to indicate that one part of the image is somehow part of the verification process.
Indeed, if we check the encrypted file from the green layer, we find that the file is signed as well as encrypted. In order to verify the signature you need the public key of the signer, in this case me. But where can we get my key? From a public keyserver, of course! If you download the key I made for this puzzle, you will find that it has an attached image! LeppyR64 extracted this image to reveal the fourth quadrant of the playing card image:
I don't really want to talk about this part. This was supposed to be the pièce de résistance, the most clever of clever parts of the puzzle. However, the original version of the puzzle omitted the signature on the encrypted file, causing much frustration on the parts of the puzzle-solvers, and much wailing and gnashing of teeth on my part when I discovered my mistake.
Here's what I think happened. I work mainly on a Windows desktop, but for programming and other tasks I prefer Linux, so I run a Linux virtual machine (VM) in Windows. Parts of this puzzle (e.g. the encryption tasks) were performed on the Linux VM, and parts (e.g. the image manipulations) were performed on the Windows host. Due to some poor planning, I essentially had two copies of the project that I manually synchronized, one on Linux and one on Windows.
When I had all the parts of the puzzle finished, I decided that it would be best to test them on a computer without the original files, so that I could be sure that it was possible to do every step of the puzzle. I also have a Windows laptop, which is in the same situation (Windows host, Linux VM), that I used to "verify" the puzzle. When I copied over the project to that computer, I now had four (independent!) copies of the project floating around.
At this point I found and corrected a few mistakes, so I modified the 'final' files and moved them back to my desktop to upload them. At this point some files got shuffled around, and an intermediate file (the encrypted but unsigned copy of the "green" file) got substituted for the final (signed) one. I incorporated and uploaded the wrong file, and the rest is history.
Now my VMs are configured to share the same filesystem as the hosts, and my two computers are synchronized through the cloud.
Fourth Layer
Assembling the four quadrants obtained from the previous parts, we get the full layout of the poker game:
(click for original)
The cards in play are:
Community cards: 9♠ 7♣ 2♣ A♥ A♣
South: 10♣ 4♣ — flush (in clubs)
North: A♦ 3♠ — three-of-a-kind (aces)
West: 5♥ 2♥ — two pair (aces and twos)
East: 4♥ 3♥ — one pair (aces)
South's flush depends on all three clubs in the community: removing any one of them will greatly devalue his hand. Similarly, North and West both use the aces (including the ace of clubs) in either a pair or three-of-a-kind. From this we can guess that the ace of clubs is a key card.
The solution comes when we notice that East is close to a straight: he is just missing a five. If we swap the only five in play (the five of hearts in West's hand) with the previously-identified ace of clubs, we get:
Community cards: 9♠ 7♣ 2♣ A♥ 5♥
South: 10♣ 4♣ — nothing (ace high)
North: A♦ 3♠ — pair (aces)
West: A♣ 2♥ — two pair (aces and twos)
East: 4♥ 3♥ — straight (five-high)
Thus reversing the ranking of the players' hands.
This part was solved by LeppyR64.
I'm not sure where I got the idea for this part of the puzzle from. I always knew that I wanted and endpoint a little more substantial than "you did it!" Poker worked well since the setup can be conveyed visually, and in separate pieces. The distinctiveness of playing cards was sort of a benefit, since I could get away with using very low-resolution images in some cases and the card values were still legible; however this was also a problem, since they were even legible in the "overview" image! Overall though I was satisfied with the poker puzzle.
This puzzle wasn't very hard to solve, but it was a little difficult to come up with. Once I came up with the idea, I just wrote a program to find the puzzle scenario by brute-force, testing random hands until one matching a specific description (existence of a unique swap that reverses the rankings of the players) was found. I left it running overnight, and it found two solutions. The other didn't have as many "types" of hands (three of the players had straights!) so I rejected it, using the one you see.
Please let me know if I misattributed any parts of the solution, and comment if you have any more questions about the creation of this puzzle!
