So if the plaintext is N-bits long...the key has to also be N-bits long?
Let's explain this point-by-point:
- The key stream has to be N-bits long for a stream cipher;
- For an OTP the key is basically the key stream;
- For a stream cipher or block cipher (in stream mode such as counter mode) the key is generally between 128 and 256 bits to be considered secure;
- For these ciphers the key is used to generate the key stream.
I've skipped "plaintext aware" stream ciphers as they don't use XOR (directly) to calculate the ciphertext from the key and plaintext.
If the answer is no and it can be an arbitrary number...wouldn't that be a block cipher?
A block cipher is a cipher that permutes one block of plaintext to a block of ciphertext (and vice versa) - using the key to select the permutation. You can have block ciphers and stream ciphers with about any size of key. The key size doesn't define if something is a stream cipher or block cipher.
If the answer is yes, does the sending and receiver end have to agree on the quantity of bits to be transmitted beforehand?
The answer is no, so that makes this question invalid. Nevertheless: for an OTP you'd have to make sure that you know the location within the key stream and of course that you have shared enough key bits. For a stream or block cipher you don't need to know the quantity of bits to be transmitted beforehand. However, you should be using a unique IV or nonce for each message.
If this is random (ie. unknown beforehand), how can they know what key to use to encrypt and unencrypt if it has to be as long as the plaintext?
They use a complex technique called "keeping count" :) And yes, it is a problem if the index gets out of sync, e.g. because of lost messages.