Say you run in to a messed up AES (128) implementation which has the s-box configured as [0x0, 0x1, ..., 0xFE, 0xFF] and where you can query a few plaintexts to get the corresponding ciphertexts. How many queries would one need to be able to deduce the key, and how would one go about it? This would be a chosen plaintext attack, but I fail to see how it would be done. Thanks a lot.
If the s-box is the identity mapping, then the remaining cipher is linear.
If the cipher is linear (over $GF(2)$), then the expression for any given bit will be equal to: $$c_i = m_i \oplus m_j \oplus m_k \oplus \dots \oplus k_a \oplus k_b \oplus k_c \oplus \dots$$
For some varying quantity of and values of $a, b, c, j, k, \dots$ per ciphertext bit.
Basically, each ciphertext bit is equal to a xor of plaintext bits and key bits (and any round constants, as applicable).
Chosen plaintext attack
A linear cipher can be broken with 1 chosen plaintext attack.
Submit a block of all 0 bits as the plaintext to the encryption oracle.
Since the plaintext has no influence on the key schedule, the key bits that influence each ciphertext bit do not vary between invocations on different plaintexts. When the message is all 0 bits, then the equation for any given ciphertext bit is simply $$k_a \oplus k_b \oplus k_c \oplus \dots$$
Where the quantity and values of $a, b, c, \dots$ vary for any given ciphertext bit (round constants omitted for simplicity).
The resultant ciphertext will be equivalent to an encryption/decryption key.
It may/will not be the key that was used to evaluate the cipher, but it will work to recover the plaintext from a ciphertext, or vice versa.
To do so, simply XOR the equivalent key with a ciphertext, then run the "AES"* decryption routine without the addRoundKey step.
Proof of concept located here
*"AES" is in quotes, because AES is a standard. Once it is modified (e.g. by changing the s-box), it is not AES anymore.