Chemical Traffic Light Puzzle

Here's a description of the "Chemical Traffic Light Puzzle" and its making. Aaron Shih made the puzzle for Caltech Ditch Day -- an annual series of puzzles and challenges -- in 2019, and I helped implement it. I'm particularly interested in some of the software and Arduino-related considerations that were involved.

In the chemical traffic light experiment, you shake a vial of yellow solution until it turns green. Wait a while and it turns red. Wait a while longer and it turns yellow again. You can repeat the experiment several times before the solution stops changing color. The idea of the puzzle is to require participants to simultaneously get yellow, green, and red colors from three different vials. We had three vials with the requisite solutions, three Adafruit color sensors, three Arduinos, several 5mm LEDs that can just turn on/off, basic electronics supplies, and a cryptex with a combination lock (which Aaron Shih laser cut at the last minute). We tried to hook this all up so that simultaneously displaying yellow, green, and red solutions to the color sensors would reveal the combination to open the cryptex.

One challenge to making this puzzle was to ensure that the information revealed to the participants would only be useful if they got the right colors *simultaneously*. (Simultaneity requires more teamwork.) Maybe we could hook all of the color sensors up to just one Arduino, and have that Arduino enforce the simultaneity requirement before displaying the cryptex key. The problem with that approach is that the Adafruit color sensors communicate over an old protocol called I2C, which usually requires hardware support, and we didn't find a way to control more than one sensor per Arduino. Maybe we could have connected the three sensors in series and broadcast to/from them, but that approach wouldn't work because the three sensors were manufactured to all have the same I2C address. We could have worked around that with an I2C multiplexer, but we didn't have time to acquire that piece of hardware before Ditch Day. Finally, Brian Lee suggested using a Software I2C library to control the sensors over ordinary data pins, but I couldn't get any Software I2C libraries to work. Instead, I had some intuition that three Arduinos, each with their own colors sensors and with no connection between each other except their (almost) synchronized clocks, could use some sort of cryptographic technique to garble or "salt" their outputs in a way that could only be decoded if the outputs were obtained (almost) simultaneously. Alex Meiburg happened to be around at this late hour. I described the problem and he immediately suggested the technique I was looking for.

It's easier to understand the technique in the case of a two-color traffic light, with just two color sensors and two Arduinos, so I'll describe that. One Arduino outputs when it detects green, the other when it detects red. Each Arduino has the same pseudo-random number generator with the same seed. At each time step, the generators yield a new pseudo-random number, which is the same on each Arduino. At each time step when the first Arduino detects green, it outputs, in binary, this pseudo-random number. At each time step when the second Arduino detects red, it outputs, in binary, this pseudo-random number XORed with the cryptex combination. If the participants get green and red solutions simultaneously, then they can XOR the outputs from the Arduinos to get the cryptex key. We adapted this technique for a three-color traffic light, using two pseudo-random number generators.

On Ditch Day, this puzzle baaasically worked out as planned.