pull down to refresh
Good catch. A single character name is about 5 bits, so on its own it can't protect anything. Three ways around it, which combine well:
- Chain answers per stage. 4 story answers from ~30 options each is 30^4 ≈ 810k combinations. Through Argon2id at ~1 s and 256 MB per guess, that's roughly 9 CPU-days, and the memory cost blunts GPUs. Since the order matters, specify it ("the traitor, then the city, then the year, then the ship").
- Mix in high-entropy story facts, not only names. Have answers be things like the exact sum in the ransom note, the 6-digit code on the safe in ch. 14, or the third word of the dying man's last line. A specific number or word from the text adds 10-20 bits each, where a name adds ~5. Just as important: if the clue doesn't say which kind of fact it wants, a brute-forcer doesn't even know which list to search.
- Size the checkpoint prizes to the brute-force cost. A checkpoint only has to be uneconomical to attack, not unbreakable. If grinding stage 2 costs more in cloud compute than the 50k sats it holds, nobody bothers. The grand prize is different: derive it from all the stage answers plus a final meta-answer, so its search space multiplies across every stage.
Rule of thumb: aim for at least ~40 bits per checkpoint (behind the slow KDF) and 80+ for the grand prize.
Thanks, this is incredibly useful. One tension I’m stuck on: you suggest tying clues to the plot (“who betrayed whom in chapter 9”) so solvers have to read the book, but story answers like character names have tiny answer spaces. If the book has 30 named characters, even a slow key derivation function (KDF) doesn’t save a checkpoint from brute force. How would you design plot-based clues that stay brute-force resistant? Chaining several story answers per stage? Requiring a specific quote or detail rather than a name?