"The same key" in the context of OTP means the same pad… all the key material shared between the sender and recipient. However, every encryption with that pad must use a different part of the pad or it isn't OTP at all. Not reusing bits from the key material is the defining characteristic of the One-Time Pad.
The only reasonable formulation of IND-CPA, IND-CCA1, or IND-CCA2 for OTP involves the encryption and decryption oracles using a unique subset of the pad for each plaintext. That's part of the cryptosystem definition, much like the selection of unique, random nonce values. When put in those terms, the encryption and decryption oracles can only ever reveal the parts of the pad used to encrypt the adversaries' chosen plaintext, which doesn't provide any information which could be used to decrypt any other ciphertext, so OTP easily passes all three tests.
You’re mistaken. CCA has a formal definition that may not match with your expectation, but in the definition of CCA, the same key that is used to encrypt the challenge message is used for the decryption oracle.
Is there a point to arguing whether a system is CCA secure if the 'formal definition' uses the system in an explicitly wrong way?
Especially if there is a trivial modification of the 'formal definition' that better matches the intention and allows for results that apply to reality?
Of course there is the question of whether the modification is trivial, and whether the modification changes CCA meaningfully for other systems. But argue about that, whether a definition modification changes past results using that definition. Just stating 'that is not the formal definition' if the formal definition gets criticism and an alternative is suggested, is not really good-faith engagement with criticism.
The point is that CCA is not applicable to one time pad. All you're saying is that OTP is not secure if you know the key. It doesn't matter what terms you use to describe it. It just doesn't mean anything beyond that.
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?
Even if you make this assumption it still wouldn't be a successful attack because OTP makes no security claims if the key is re-used. If there's no security claim there's nothing to attack to begin with.
I can declare that my "brazzy attack" involves an oracle that for any given cipher text gives me the key it was encrypted with. Wow, all modern ciphers are vulnerable to it, the only thing that resists it is keeping the algorithm secret!
Just because you can think of something doesn't mean it makes sense.
I’m not sure what point you were trying to make. I think you accidentally made the opposite point. Indeed your definition would imply that all modern ciphers are not Brazzy-secure. I’m not sure why this matters to you.
No one is saying that the fact that OTP cipher is not CCA secure is practically relevant.
But the fact of the matter is that a cryptosystem being CCA secure is defined as we discussed and the OTP cipher does not meet the requirements.
I think we're largely in agreement then, but I still believe that it makes more sense to say that the definitions of OTP and CCA are incompatible and therefore it's just meaningless to apply one to the other.
