I wouldn't go so far as to say that IND-CPA/CCA1/CCA2 aren't applicable. The fundamental error l33t2328 is making lies in mistaking the part of the pad used to encrypt a particular plaintext with the entire "key" which must remain constant. That makes zero sense in the context of a one-time pad, and as you said if the rules are misinterpreted that way it just makes the IND tests meaningless for OTP. Even for other algorithms it's typical to have some element which must be unique for each plaintext (e.g. a nonce or initialization vector) for the system's security properties to hold. For OTP that varying component just happens to be the specific region of the pad used for the encryption. The entire pad is the key. This perfectly satisfies the requirements of the formal definition, as the pad is shared in advance and does not vary, while the portion to be used for a given plaintext is chosen during encryption and does not need to be kept secret.
> The fundamental error l33t2328 is making lies in mistaking the part of the pad used to encrypt a particular plaintext with the entire "key" which must remain constant.
This is no error. The distinction you are making is nonsense. Indeed, given the key k and a message m, the basic correctness requirement of a crypto-system demands that dec_k(enc_k(m)) = m.
How on earth is this decryption to be done under your assumption that only some part of the pad was used?
First, to get this out of the way, there is no meaningful sense in which OTP fails any of these IND-CPA/CCA1/CCA2 games. Depending on how you formulate the preconditions, either the games are simply not applicable to OTP and the result is nonsense, as any implementation which satisfied requirements for encryption and decryption oracles which reuse the same bits of the pad for multiple plaintexts would not be OTP, or OTP passes the tests with flying colors. Personally I don't think the former is worth discussing—as it amounts to an attacker already having a full copy of the pad—so I'll be limiting my response to the version that actually makes sense.
> the basic correctness requirement of a crypto-system demands that dec_k(enc_k(m)) = m
Indeed. For OTP you have a bitstream k which is the entire pad, large enough to provide one bit of pad for every bit of plaintext you might ever want to encrypt. enc_k(m) is defined as taking the next length(m) unused bits from the pad, which I'll call k[m], and calculating the ciphertext (c) as (k[m] XOR m, i) where i is the index of k[m] within the pad. (In some systems the starting index would be implicit but then you can't lose or reorder messages, which isn't really compatible with the concept of oracles.) These bits k[m] are then effectively destroyed in the sender's copy of the pad, never to be used again. dec_k(m) is exactly the same process, including the destruction of the used bits, but using the recipient's copy of the pad.
(Yes, this means enc_k and dec_k carry some extra implicit state and are not simply functions in (k × m) → c; this is a strict requirement to count as an implementation of OTP. If you aren't doing at least this much, especially including the part about never reusing bits from the pad on either the sending or receiving side, you don't have an OTP system.)
So dec_k(enc_k(m)) = m, but k[m] is different for each m—and knowing m and enc_k(m) tells you k[m] for that message, the one supplied by the attacker, but nothing about any other message. The attacker might as well be using their own distinct pad rather than the provided encryption & decryption oracles for all the good this does them.
> The entire pad is the key.
At least we agree on something. The key for which encryption & decryption oracles must be provided is indeed the entire pad, not just the part used for one particular message.
> there is no meaningful sense in which OTP fails any of these IND-CPA/CCA1/CCA2 games
That’s factually wrong. A CCA oracle can easily determine the key.
> enc_k(m) is defined as taking the next length(m) unused bits from the pad
No, it is not. It’s defined as m \xor k.
You are describing another cipher, but not Vernan’s OTP.
> Yes, this means enc_k and dec_k carry some extra implicit state and are not simply functions in (k × m) → c
Then you aren’t describing an encryption and decryption function. Those depend only on k and m.
Someone must be able to have the algorithm and the key and decrypt any message. Your “hidden state” cannot(and indeed should not) be a part of the algorithm as it violates the principle of kerckhoff.
Stepping out of the theoretical for a moment, your proposed scheme also makes no sense in reality. How am I to know what part of the pad you’re using if I’m in a bunker picking up your encrypted signal?
