null program

Play NetHack

Patience. NetHack is all about patience. Never be too hasty, as the game is extremely unforgiving. If you let your guard down for just a few turns, you can easily lose everything. Death is permanent (with some exceptions), so dying means starting it all over with a new character.

I got into NetHack a couple of years ago. I play is in cycles, playing heavily for a couple of months at a time, then take a break for a couple months after I tire of getting stuck at the same point each game. I generally return a better player. The game is very complex, taking probably a hundred hours of play just to nail down the basic gameplay and techniques.

This is what my typical session looks like. I like it almost as simple as it comes. By default, color is off, but I like to have it on (a lot more information is available with color). The graphics may seem crappy, but it is said,

While the graphics may seem primitive by today's standards, today's gameplay seems primitive by NetHack standards.

The dingo is blinded by the flash!  The dingo turns to flee!

                                                                       -------
                                                                       |++...|
       --------------                               ----------         |.+...|
       |............|              --------         |>........#        ---|---
       |............|              |......|         |........|#           #
       |.........<...#            #.......|         |........|#         ###
       |...^........|           ###|......|         --.-------#         #
       --.----.------           #  ------.-#          #       ###       #
         #######              ###        ###          ###       #       #
            ####              #           #             #       ###     #
               ###          ###           ####          ###       #     #
                 #          #               #  #          #       ###---.----
                 ##       ###               #########     #         #.......|
                 -.----   #                      # -.-----|--        |@.....|
                 |.`...####                      ##-........|        |...[..|
                 |....|                            |........|        |......|
                 |{...|         0##################-........|########-......|
                 ------                            |........|#       --------
                                                   ----------#

wellons the Sightseer       St:12 Dx:12 Co:18 In:12 Wi:8 Ch:16  Neutral S:1967
Dlvl:6  $:1329 HP:48(48) Pw:17(17) AC:7  Xp:5/185 T:3717

Like most rogue-like games, playing NetHack is a rewarding experience, so if you never tried it out before, I suggest taking a look at the NetHack Guidebook and firing it up for yourself! If you don't want to install it, but you have a telnet client available, you can connect to the nethack.alt.org server to play and watch others play, which is a good way to learn more. Building it from source can be a little tricky (took me a little while to figure it out the first time), so using your package manager is advised if you do choose to install it to try it out.

Another good resource is the NetHack wiki Wikihack. However, if you don't want to "spoil" yourself, don't go there. Learning things about the game outside of the game is not considered cheating, but rather spoiling. I don't mind spoiling myself. I will run into plenty of things I have not yet spoiled myself on. The game is hard enough as it is!

There is a theory that if someone ever completely beats NetHack under the hardest conditions, the source code will be thrown out and replaced with something even harder and more unforgiving. There is another theory which states that this has already happened.

When play for the first time, start with a Valkyrie or a Barbarian as these classes are pretty tough against baddies, simpler to play, and more foolproof than some of the squishier classes, like wizards.

WARNING: SPOILERS FOLLOW

To give an idea of some of the interesting gameplay, I have a couple examples.

               #
          -----.--
          |....y.|     ## 
          |......|     #
          |.n....@f######
          |......|
          |....n.|
          --------

I am the @ symbol, which is how NetHack represents the player. I am entering the room with two awakened nymphs (n) and a yellow light (y). Behind me is my cat who fights alongside me and assists me. Nymphs do not do damage, but rather steal your equipment. They approach you, charm you into giving them something from your inventory, which includes weapons and armor, and teleport away. This means that you generally want to kill them before they close in.

Yellow lights also do no damage. They run up to you and explode, causing you to be blind for a number of turns. Normally, this can be a really bad situation if you do not have the right tools available to you, which is typical for early in the game. In the worst case, which also happens to be the most likely, while I work on the nymphs the yellow light will run up to be blinding me. Now, since I cannot see the nymphs, I cannot attack them at range and they run up to me each stealing one item. If I remain blind for long enough, they may find me again and steal something else while I am helpless. They would rob me blind! It would be up to my cat to dispatch them.

However, I did have some good tools available. I happened to get extremely lucky (the Random Number God was nice to me that day) and find both a cloak of displacement and jumping boots at a store at dungeon level 1. The cloak makes me appear to be in a different place than I really am while the jumping boots let me travel several squares in a single turn. I was also playing a rogue, so my main attack was already a ranged one: throwing daggers.

The yellow light ran up to my displaced image and exploded, causing no blindness to me. One down. Next, I threw my plentiful supply of daggers at the nymphs, keeping my distance by jumping around the room. I managed to prevent a deadly situation, being stuck naked with no weapon, by applying my resources well. With NetHack, I had plenty of time to plan out each move I made. There is no timer. NetHack moves at my pace.

There was a another situation a couple months ago (which I will not bother drawing) where I was attacked in the middle of a room by a werewolf. The werewolf summoned help immediately and I was surrounded by winter wolves and coyotes and such. Winter wolves can be dangerous because they shoot deadly frost bolts, and I had not yet have the cold resistance intrinsic.

I cut a hole through the canines towards the hallway where I could fight them one at a time, and I lost most of my health in the process. Then I prayed to recover my health. Then I starting hacking away at the canines. Again, I was low on health and running out of options. The winter wolves were firing bolts down the hallway at me. Engraving Elbereth on the floor was not going to save me from the ranged frost bolts. Things were looking quite grim for me. The end seemed near.

I did the only thing I could think to do at this point: I reached down and took a bite into one of the dead frost wolves that was resting on the floor beneath me.

Take a moment and picture this. Frost bolts are zipping down a dark cold hallway at a nearly dead Valkyrie. There are shattered potions and frozen liquids all over the floor. The winter wolves have caused the temperature to plummet. Her breath hangs visibly in the air. She quickly crouches down and shoves her face into a dead wolf, taking a nasty bite right into its furry, bloodied side. Between her clenched teeth she tears off a piece dripping with blood. Desperately, she stuffs her face with the fresh kill, trying to eat as much as fast as she can as she dodges more frost bolts.

At this moment, the Random Number God blessed me with good fortune, and I was granted the cold resistance intrinsic just before the next frost bolt was going to kill me, allowing me to harmlessly absorb it and continue hacking away the remaining canines. Her reward for victory was a canine feast!

So, yes, the simple looking NetHack can be quite exciting. :-)

A GNU Octave Feature

At work they recently moved me to a new project. It is a Matlab-based data analysis thing. I haven't really touched Matlab in over a year (the last time I used Matlab at work), and, instead, use GNU Octave at home when the language is appropriate. I got so used to Octave that I found a pretty critical feature missing from Matlab's implementation: treat an expression as if it were of the type of its output.

Let's say we want to index into the result of a function. Take, for example, the magic square function, magic(). This spits out a magic square of the given size. In Octave we can generate a 4x4 magic square and chop out the middle 2x2 portion in one line.

octave> magic(4)(2:3,2:3)
ans =

   11   10
    7    6

Or more possibly clearly,

octave> [magic(4)](2:3,2:3)
ans =

   11   10
    7    6

Try this in Matlab and you will get a big, fat error. You have to assign the magic square to a temporary variable to do the same thing. I kept trying to do this sort of thing in Matlab and was thinking to myself, "I know I can do this somehow!". Nope, I was just used to having Octave.

Where this really shows is when you want to reshape a matrix into a nice, simple vector. If you have a matrix M and want to count the number of NaN's it has, you can't just apply the sum() function over isnan() because it only does sums of columns. You can get around this with a special index, (:).

So, to sum all elements in M directly,

octave> sum(M(:))

In Octave, to count NaN's with isnan(),

octave> sum(isnan(M)(:))

Again, Matlab won't let you index the result of isnan() directly. Stupid. I guess the Matlab way to do this is to apply sum() twice.

Every language I can think of handles this properly. C, C++, Perl, Ruby, etc. It is strange that Matlab itself doesn't have it. Score one more for Octave.

The Arcfour Stream Cipher

Stream ciphers are one of the two types of symmetric key algorithms, which is when the same key is used for encryption and decryption. They follow this simple concept: take a good pseudo-random number generator and combine, usually by XOR, its output with your plaintext stream. This is very similiar to the one-time pad, but the random pad is pseudo-random rather than truly random. The key is the seed (or part of one) for the PRNG.

Probably the most well known stream cipher is the extremely simple, yet cryptographically strong, Arcfour algorithm. The official name is actually RC4, which comes from RSA Security where it was developed. It was a trade secret until someone anonymously leaked the algorithm to the public. The name RC4 is still trademarked, though, so Arcfour is generally used instead, meaning "Alleged RC4" (alleged because RSA Security never confirmed the algorithm as being RC4). You have almost certainly used the cipher yourself, because it is used in applications such as WEP and SSL.

The algorithm has two parts: the key schedule algorithm and pseudo-random generation algorithm. The key schedule uses the key, and possible a non-secret initialization vector, to set up the state of the PRNG. The state is an array of length 256 holding all of the values from 0 to 255 in some order, along with two integers (initialized to 0 after the key schedule). The algorithm looks like this,

for i from 0 to 255
    S[i] := i
endfor
j := 0
for i from 0 to 255
    j := (j + S[i] + key[i mod keylength]) mod 256
    swap(S[i],S[j])
endfor

The PRNG deals with one byte at a time, emitting a stream of bytes,

i := 0
j := 0
while GeneratingOutput:
    i := (i + 1) mod 256
    j := (j + S[i]) mod 256
    swap(S[i],S[j])
    output S[(S[i] + S[j]) mod 256]
endwhile

If you implement this in C and use the char type, you can toss the modulus parts because they will just work automatically.

Now you just XOR your message with the output of the PRNG. The Wikipedia article probably explains it better than I can, so check it out if you still don't follow.

Now, Arcfour has some flaws. Specifically, the algorithm itself doesn't specify how an initialization vector is applied, which is important. Using a plan key twice is bad it allows an adversary to get information easily. For example, Lets say you have two messages A and B. You use the same key k, which will produce the same keystream K. Now, you create your two ciphertexts C_A and C_B

C_A = A ^ K
C_B = B ^ K

But notice if the adversary has both ciphertexts,

C_A ^ C_B = A ^ K ^ B ^ K = A ^ B

They are left with your two original messages XORed together. Let me illustrate: we have two messages as bitmap images (here as PNGs for the web),

Encrypt them using the same key. In this case, my key was "somekey".

If the adversary has both of these second "images", she can XOR them together (having no knowledge of the key!) and get this,

An initialization vector (IV) is a set of bytes we combine with the key. The IV is not a secret, as it is sent plaintext with the ciphertext. If different IVs were used above with the same key, XORing the ciphertext would result in nothing, because the keystreams are totally different for each message.

However, the way the IV is combined is important too. Simply concatenating the IV and the key can lead to weaknesses due to the way the key schedule algorithm works. Something more secure would be a cryptographic hash of the key and the IV. The reason WEP is broken is because in its design the IV wasn't used properly.

Another weakness is that the initial bytes of the keystream have low entropy. That is, some bits tend to be 0's or 1's consistently, which can leak information to an adversary. This can be countered by tossing the first few bytes of the keystream. Often the first 768 bytes are dropped, but a conservative amount would be 3072 bytes. Another way to deal with this is running the key schedule algorithm 10 or 20 times (not reinitializing the S array between them of course) rather than just once, which is the way CipherSaber-2 does it.

Yet another weakness is that the keystream becomes distinguishable from random data after about a gigabyte of output. That is, after about a gigabyte, the entropy of the overall stream can become too low and compromise the security of the message. A solution might be to change the IV each gigabyte.

I wrote an implementation of Arcfour in C, which you can get from my Git repostiory with,

git clone http://git.nullprogram.com/arcfour.git

Or grab a snapshot.

It is written as a library that can be used in different applications. Included are a couple programs that make use of it. I strongly suggest writing your own implementation. It is really easy to do, and you will automatically have the algorithm memorized once you do it. The Wikipedia article has some test vectors you can use to test it.

Two-Man Double Blind Coke vs. Pepsi Taste Test

My fiancee, Kelsey, claimed that she could tell the difference between Coke and Pepsi. I wanted to put this to the test. Since there were only two of us, arranging the test wasn't a simple matter of asking someone else to pour some cups. I also wanted to do this right: testing must be double-blind. I devised a little scheme that allowed us to perform two different tests.

The first test was seeing if Kelsey or I could determine which beverage was Pepsi and which was Coke. The second was determining if there was any distinction in taste between the two drinks at all, which consisted matching two different samples together. The second test also acts as a check on the first test.

We bought one bottle of each at CVS. Next, we labeled six different cups with the numbers one though six. Each odd number is paired with the following even number. Kelsey, who was alone, used a die with an even number of sides (this includes a something as simple as a coin toss) to put one beverage in cup #1 and the other in cup #2. In this case, we used my 20-sided die I use for Dungeons and Dragons, because using it for this purpose was just full of win.

The die is important here as a random number generator. If it is left up to a human to decide what drinks go where, we may bias the setup. For example, I may be more likely to put Pepsi in an odd-numbered cup than an even-numbered one.

It is difficult for human beings to behave randomly. Try generating a list of 50 coin tosses yourself. I mean, without a coin. Just type a series of 50 H's and T's. If you examine your list of flips, you will find that you often generate very improbable series of flips (excessive heads or tails) and exhibit patterns. We need dice or coins to make decisions for us in this experiment.

To do it right, the beverage must be chosen before the roll: "I will be pouring Pepsi now.". Roll the die. If it rolls an odd number, pour the drink into the odd cup (#1). Write this information down and keep it secret.

Next, after allowing the foam to calm down (which might accidentally reveal information to me), Kelsey leaves the room and I enter. I perform a similar procedure to distribute the drinks into cups #3 and #4, then #5 and #6. I keep track of what drink, #1 or #2, goes into what cup. I keep it secret. These last two cups are for the purpose of the second experiment.

At this point Kelsey knows what was in cups #1 and #2, but not where they went. I know where they went, but not what was in the cups. Together we know everything, but individually we know nothing.

In order to make the second test double-blind, and allow me to participate, I leave the room. Kelsey rolls the die. If it rolls odd she switches the label on cups #5 and #6. It is important that these cups are identical. One flaw potential, however, is that the liquid in each cup may look unique. One may be more fizzy or one cup a little more full. Noticing this may happen subconsciously, which is the whole point of doing double-blind tests.

Ok, we didn't actually do this last part because I didn't think of it till later.

We sample all four cups (#3 - #6) in pairs, alone, making notes on what beverage we think is in what cup. Once we are both done we share our secrets and see how well we did.

Our results? Neither of us could tell the difference between Coke and Pepsi.

Sudoku Solver

I was at my fiancee's parent's house over Fourth of July weekend. Her family likes to leave plenty of reading material right by the toilet, which is something fairly new to me. They take their time on the john quite seriously.

While I was in there I saw a large book of Sudoku puzzles. Since the toilet is a good spot to think (I like to call it my " thinking chair"), I thought out an algorithm for solving Sudokus. I then left the bathroom and implemented it in order to verify that it worked.

The method is trial-and-error, which it does recursively: fill in the next available spot with a valid number as defined by the rules (cannot have the same number in a column, row, or partition), and recurse. The function reports success (true) when a solution was found, or failure (false), which means we try the next available number. If no more valid numbers are available for testing at the current position, then the puzzle is not solvable (we made an error at a previous position), so we stop recursing and return failure.

More formally,

Find an open position.
Look at that position's row, column, and partition to find valid numbers to fill in.
Fill the position with one of the valid choices.
Recurse using the new change.
If the recursion reports a problem (returns false), try the next valid number and repeat.
If recursion reports success (true), stop guessing and return success.
If the list of valid numbers is exhausted, return failure (false).

Note that the recursion depth does not exceed 81, as it only recurses once per blank square. The "game tree" is broad rather than deep. It doesn't have to duplicate the puzzle matrix in memory either because all operations can be done in place.

Here is the implementation in C I typed up just after I left the bathroom,

int solve (char matrix[9][9])
{
  /* Find an empty spot. */
  int x, y, i, j, s = 0;
  for (i = 0; i < 9 && !s; i++)
    for (j = 0; j < 9 && !s; j++)
      if (matrix[i][j] == 0)
	{
	  x = i; y = j; s = 1;
	}
  
  /* No empty spots, we found a solution! */
  if (!s)
    return 1;
  
  /* Determine legal numbers for this spot. */
  char nums[10] = {1, 1, 1, 1, 1, 1, 1, 1, 1, 1};
  for (i = 0, j = y; i < 9; i++)
    nums[(int)matrix[i][j]] = 0; /* Vertically */
  for (i = x, j = 0; j < 9; j++)
    nums[(int)matrix[i][j]] = 0; /* Horizontally */
  for (i = 0; i < 3; i++)
    for (j = 0; j < 3; j++)
      nums[(int)matrix
	   [i + ((int)(x / 3)) * 3]
	   [j + ((int)(y / 3)) * 3]
	   ] = 0;                /* Within the partition */
  
  /* Try each possible number and recurse for each. */
  for (i = 1; i < 10; i++)
    if (nums[i] > 0)
      {
	matrix[x][y] = i;
	if (solve (matrix))
	  return 1;
      }
  
  /* Each attempt failed: reset this position and report failure. */
  matrix[x][y] = 0;
  return 0;
}

I assumed that it would be slow solving the puzzles, having to search a wide tree, but it turns out to be very fast. It solves normal human-solvable puzzles in a couple of milliseconds. Wikipedia has a near-worst case Sudoku that is designed to make algorithms like mine perform their worst.

char worst_case[9][9] =
  {
    {0, 0, 0,   0, 0, 0,   0, 0, 0},
    {0, 0, 0,   0, 0, 3,   0, 8, 5},
    {0, 0, 1,   0, 2, 0,   0, 0, 0},
    
    {0, 0, 0,   5, 0, 7,   0, 0, 0},
    {0, 0, 4,   0, 0, 0,   1, 0, 0},
    {0, 9, 0,   0, 0, 0,   0, 0, 0},
    
    {5, 0, 0,   0, 0, 0,   0, 7, 3},
    {0, 0, 2,   0, 1, 0,   0, 0, 0},
    {0, 0, 0,   0, 4, 0,   0, 0, 9}
  };

On my laptop, my program solves this in 15 seconds, which means that it should take no more than 15 seconds to solve any given Sudoku puzzle. This provides me a nice upper limit.

There is a way to "defeat" this particular puzzle. For example, say an attacker was trying to perform a denial-of-service (DoS) attack on your Sudoku solver by giving it puzzles like this one (making your server spend lots of time solving only a few puzzles). However, these puzzles assume a certain guessing order. By simply randomizing the order of guessing, both in choosing positions and the order that numbers are guessed, the attacker will have a much harder time creating a difficult puzzle. The worst case could very well be the best case. This is very similar to how Perl randomizes its hash array hash functions.

Now suppose we kept our guess order random then "solved" an empty Sudoku puzzle. What we have is a solution to a randomly generated Sudoku. To turn it into a puzzle, we just back it off a bit. A Sudoku is only supposed to have a single unambiguous solution, so we can only back off until just before the point where two solutions becomes possible. If you imagine a solution tree, this would be backing up a branch until you hit a fork.

Normally, Sudokus are symmetric (in the matrix sense), but completely randomizing the position guessing order won't achieve this. To make this work, the randomizing process can be adjusted to only select random points on the upper triangle (including the diagonal). For each point it selects not on the diagonal, the mirror point is automatically selected next. This will preserve symmetry when generating puzzles.

One issue remains: there seems to be no way to control the difficulty of the puzzles it generates. Maybe a number of open spaces left behind is a good metric? This will require some further study (and another post!).

Variable Declarations and the C Call Stack

A co-worker asked me a question today about C/C++ pointers,

If a pointer is declared inside a function with no explicit initialization, can I assume that the pointer is initialized to NULL?

We were down in the lab and, therefore, he had no Internet access to look it up himself, which is why he asked. When I code C, it is just a sort of mental habit to not use a non-static function variable without first initializing it, but is this accurate? I knew the answer was "no", but I wanted to be able to explain the "why".

Anyway, I quickly recalled some of my experimental C programs and thought carefully about the mechanics of what is going on behind-the-scenes, allowing me to confidently give him a "no" answer. I then threw this together in a few seconds to prove it,

#include <stdio.h>

void a ()
{
  int   * x = (int *) 0x012345FF;
  double  y = -63454;
  (void) x;
  (void) y;
}

void b ()
{
  int   * x;
  double  y;
  printf ("%p, %f\n", x, y);
}

int main ()
{
  a ();
  b ();
  return 0;
}

When you compile it, make sure you don't use the optimization options (-O, -O2, or -O3 for gcc) because they change the inner-workings of the program. It might do things like make those functions inline (so they won't be on the stack as I am intending), or even toss out a(), as it appears to do nothing. The compiler sees that, even though I "used" variables in a() by casting them to void, nothing is really happening, so a() can be ignored. We can probably get around this with a tacked on volatile declaration, which you might see a lot of in a micro-controller program. In a micro-controller, some memory addresses are mapped to registers external to the software, so, from the compiler's point of view, access to these locations may look like nothing is really happening. Optimizing away variables that point to these memory locations will lead to an incorrect binary, so your robot or laser guided shark or whatever won't work.

Anyway, compiling with optimization will break my example! So don't do it here.

When compiling, you should get some warnings about using uninitialized variables, which is kind of the point of my example. Ignore it. That warning alone gives away the answer to the main question, really, but this example is a bit more fun!

Before you run it, study it and think about what the output should look like. When a() is called, its stack frame goes into the call stack, which contains the two declared variables. These variables are then assigned as part of the function execution. When a() returns, the frame is popped off the stack. Then b() is called, and, as the variable declarations are exactly the same, it will fit right over top of a()'s old stack frame, and its variables will line up. x and y are not assigned any value, so they pick up whatever junk was lying around, which happens to be the values assigned in a().

When you run the program, this is the output,

0x12345ff, -63454.000000

The pointer is not initialized to NULL. If x is passed back uninitialized under the assumption that a NULL is being passed, some other poor function that handles the return value may dereference it, resulting in possibly some nasal demons, but most likely an annoying segmentation fault. Worse, this error may occur far, far away from where the actual problem is, and even worse than that, only sometimes (depending on the state of the call stack at just the right moment).

Note here that I am talking about non-static function variable declarations. Global variables and static function variables will not be on the stack. They are placed in a fixed location (in the data segment), and their values are implicitly initialized to 0 at compile time.

A One-Time Pad Mistake

In a previous post I discussed one-time pads. Note: this is about a cryptosystem, not some kind of menstruation disaster. The information for this post comes from a little gem I saw on the xkcd forums. I generally don't lurk around there because it suffers from the same disease most non-self-moderating forums suffer from: anal retentive, power-abusing, whiny moderators. I lucked out this time.

The user Berengal posed the question,

One thing I've been wondering about is if you can use a single one-time-pad to encrypt other one-time-pads to send around.

My first though was, "Hey, why didn't I think of this?". Then, after a moment, I realized that it was the sort of thing that is too good to be true. This is along the lines of ideas that break the laws of thermodynamics. We are looking at a perpetual motion machine here. Just as you cannot create or destroy energy, neither can you use a one-time pad to distribute more than one other equal length one-time pad. Let's make it formal,

In any closed one-time pad cryptosystem, the total number of one-time pad bits in the system remains the same.

Also, if something like this could work, people would be using it already everywhere. Before I got a chance to think too much about it, user AJR spoiled it with an excellent proof on why it won't work.

Note below that I use ^ to indicate exclusive or (XOR).

Suppose you have a master pad, K, that you use to distribute two message pads, k₁ and k₂. You have two messages, m₁ and m₂. We then have four transmitted texts: two encrypted message pads e₁ and e₂, and two ciphertexts c₁ and c₂. We define these as,

e₁ = K ^ k₁
e₂ = K ^ k₂

c₁ = k₁ ^ m₁
c₂ = k₂ ^ m₂

Suppose an adversary is able to record all four transmitted texts. He can apply them like so,

e₁ ^ c₁ = K ^ k₁ ^ k₁ ^ m₁ = K ^ m₁

e₂ ^ c₂ = K ^ k₂ ^ k₂ ^ m₂ = K ^ m₂

This cancels the original message keys and effectively leaves you encrypting two messages with the same pad, which is exactly the wrong thing to do when using one-time pads. Once that is done, the adversary can do tricks like,

e₁ ^ e₂ ^ c₁ ^ c₂ = m₁ ^ m₂

What is left is the two messages XORed together with no keys/pads involved, which, depending on the messages, might reveal something. Don't make this mistake.

One-Time Pads and Plausible Deniability

In a previous post I discussed one-time pads. The information for this post comes from Bruce Schneier's Applied Cryptography (section 10.8).

One-time pads are great for something called plausible deniability. With plausible deniability, when a person holding encrypted data is coerced into decrypting their data, the interrogator will not be able to tell if the person is complying with the decryption order or not. For example, the victim could provide an alternate key that decrypts the ciphertext into some harmless dummy plaintext. To make this more plausible, the plaintext would probably be something potentially embarrassing, such as pornography or secret love letters.

We have a one-time pad K, a plaintext P, a dummy plaintext (the pornography or love letters) D, a dummy key K', and a ciphertext C. Below, I denote XOR with ^.

To encrypt our plaintext, its the normal one-time pad algorithm,

P ^ K = C

Bob and Alice share K, so decryption works like,

C ^ K = P

However, the secret police come along with their thumbscrews and demand that Alice and Bob give them the one-time pad K. Instead, they will provide K'. How is K' defined? Like this,

K' = C ^ D

Because K is a one-time pad and is randomly generated, there is no way to prove that K' is not the real key. Alice and Bob give up K'. The secret police decrypt it,

C ^ K' = C ^ C ^ D = D

"See? We were just keeping our love affair a secret from our spouses!"