Get a wodge of totally random data as big as your plaintext. That's your key. XOR it together with your plaintext. The result is your ciphertext.
To decrypt, XOR the key with the ciphertext. You get your plaintext back.
If the key is truly random, there is no way of telling which of all possible plaintexts of the length of your ciphertext is the original plaintext without knowing the key. Given the three-letter OTP encrypted message "XYZ", for all you know it could be "yes", "no ", "cow", "Bob", or anything else.
Caveats:
never use the same key to encrypt more than one message. Otherwise, the key can be removed by combining the ciphertexts, leaving just a combination of two plaintexts; which is easy to analyze statistically.
your key must be *totally* random. Any pattern will inevitably lead to a statistical attack on the ciphertext.
Note that having people pick little wooden bingo balls out of a pot is NOT sufficiently random. Modern methods of getting random data are (top end) does a radioactive particle decay in time, was a neutrino or cosmic ray seen, down to the low bit in a sample of noise data (from a weather antenna) or lowest end, your computer mike. --Vitenka
Opposite track progression. (The second layers spiral goes from the outside in, instead of starting again at the inside.) This has advantages (no seek time delay when switching layers, which can lead to smoother playback with a smaller buffer requirement) and disadvantages (generally evil for writing, and can be a pain to lock onto tracks with what looks like a grid pattern)
The opposite is PTP (Paralell track progression) which does the more obvious and saner thing. --Vitenka (DVD terminology, may apply to other media too)
In fanon; One True Pairing.
Ugh. I'm hoping this isn't really a word meaning 'fanfic-canon'. Although an abbreviation for Kanon-fanfic might be survivable. --Vitenka