A theoretical attack on Orthrus can only involve attempting to decrypt one card out of the two. After all, if you have both cards, then there's no puzzle to solve.

Of course, even if you were to decrypt it, you'd only have half the data. Still, if the data consisted of a single small file, that file might fit into a single data block, which gives you a 50-50 chance of actually possessing the entire thing (or nothing). That's why it's important for the crypto to be correct.

We can assume for this discussion that AES is "secure." What that means is that if you don't have the key that there's nothing about the ciphertext that can help you determine the key - that your only choice is to brute-force it. We can also assume for this discussion that Orthrus' code does what it claims correctly (we obviously can't assume that, we need to test it properly, but this discussion is about the design). We can further assume that you can recognize the plaintext when you get it. That's a fairly good assumption given that it's highly likely that the decrypted data will be an ordinary disk partition table with a well-known filesystem on it.

If you wished to attempt to brute-force the decryption of one of the cards, here's what you'd be facing.

You have the 32 byte volume ID, and you have only half of the 64 bytes of key derivation material. More crucially, you lack the 10 bytes of nonce that go into the AES counter mode that decrypts each sector.

The key derivation system uses AES CMAC, so there's (probably) no chance to take shortcuts to attempt to find the right volume key. Since you have to replace 32 bytes of missing key deriving data, it'd be easier to simply attempt to brute-force the 16 byte volume key directly.

But having the key is not enough - you also have to brute-force the 80 bits of nonce data. All in all, you have to get 208 bits right before you can decrypt the half of the volume you have. The number of combinations is on the order of a 4 with 62 zeros after it. There's no way that's computationally feasible.

The other theoretical attacks on Orthrus would involve rogue firmware. The firmware itself is open, so anyone could make a patched version of it. The ATMega32u2 has no security coprocessor or secure bootloader, so there's no way to insure the integrity of the firmware at run-time. Moreover, the controller has EEPROM storage, so there's every possibility rogue firmware could hide secrets that way for later retrieval.

The mitigation for this is that since there's an ISP header on the board, you have the opportunity to verify and/or replace the firmware at any time. Since the firmware is open-source, you have the ability to examine the code for weaknesses, intentional or otherwise. As long as you have a trustworthy toolchain, you can make your own copy of the firmware and flash the device. If you really, really have a threat model that suggests that someone could infiltrate and hack your Orthrus, then that's what you'll have to do.