In theory, a running key cipher includes any sort of stream cipher or a one time pad. The idea of a 'running key' is that the cipher produces an output equal in length to the message, which is then combined with it. At first glance OTP wouldn't be included in this, but just think of the cipher as the identity operation, and the input key as a random string of bits equal in length to the message. Essentially:
key + cipher => running key
running key + message => ciphertext
However, in classical cryptography, the running key cipher referred to a specific method where you choose a text (say, out of the Bible), and then encrypt a message by adding the letter values of a particular verse to the message. In this case, we would consider the cipher to be the book, and the starting location of the key. For example, let's have the book be the Bible, and the key be Genesis 6:10:
Noah had three sons: Shem, Ham and Japheth.
We convert that to numbers, ignoring case, and removing punctuation (using the usual a=0...z=25 method):
13 14 0 7 7 0 3 19 7 17 4 4 18 14 13 18 18 7 4 12 7 0 12 0 13 3 9 0 15 7 4 19 7
Our message is "Project Mayhem commences at six AM", so we convert that to numbers as well:
15 17 14 9 4 2 19 12 0 24 7 4 12 2 14 12 12 4 13 2 4 18 0 19 18 8 23 0 12
And then add them all together (modulo 26) to make our ciphertext:
2 5 14 16 11 2 22 5 7 15 11 8 4 16 1 4 4 11 17 14 11 18 12 19 5 11 6 0 1
We could also convert this back into letters if we like (this does have the advantage of allowing more compact representation, and decreases the likelihood of transcription errors, for example by missing a space between two numbers). In any case, to decrypt, just do the same thing, but instead of adding, subtract modulo 26, and you get the result, sans spacing or punctuation.
Of course, this method is completely insecure, because the 'key' will have statistical abnormalities which can be exploited. For example, it is far more likely for the key (as well as the message) to have values like 4 (e) than 25 (z). In addition there will be digraphs and trigraphs visible in the key, again making analysis easier.
The use of a running key cipher can also happen accidentally, by reusing a stream cipher key twice on two different messages. By XORing the two messages together, you cancel out the output of the stream cipher, leaving you with just two messages, XORed against one another. This has happened a couple of times to various Microsoft security protocols, and probably quite a few other places as well (the problems in PPTP were well publicized, so those are the ones that immediately come to mind for me).
I did the word->number conversion with the following braindead C code that I hacked up (assumes ASCII).
#include <stdio.h>
#include <string.h>
#include <ctype.h>
int main(int argc, char* argv[])
{
int j;
if(argc != 2)
{ printf("Bad args\n"); return 1; }
for(j = 0; j != strlen(argv[1]); j++)
{
char c = argv[1][j];
if(!isupper(c) && !islower(c))
continue;
c = tolower(c);
printf("%d ", c-'a');
}
printf("\n");
return 0;
}