When a transformation of the key is needed, how can the key be symmetric? [closed]

Question 1

In symmetric key cryptography, one does generally use the same key in both directions (encryption and decryption). It is symmetric because the decryption is performed by inverting the internal order of operations of the encryption. Different parts of the key you provide may be generated and used internally by the algorithm (as is the case in AES) - but obviously this won't be completely random in nature, as the encryption and decryption process will have to reverse the effect of the other, as this is still symmetric key cryptography. As you might know, many cryptographic methods have multiple rounds internally - and often for each such round a subkey or round key is generated from the key that you provide. The process of generating the round/sub keys is called a key scheduling algorithm in cryptography and standard AES uses the Rijndael key scheduling algorithm.

So it is the transformations described there that would happen to the key you provide to the encryption and decryption routines. However, the key that you provide will still be the same (that's the point) and the operations will all be "the same" but reversed.

There's a question on crypto.stackoverflow.com asking how AES-128 (AES with 128 bit key), AES-196 (196 bit key) and AES-256 (256 bit key) differ. You will find Paŭlo Ebermann's answer there useful in further understanding how the original key is transformed into the round/sub keys. Quoting from his answer from there:

   k_0    k_1    k_2    k_3 ─→┃f_1┃─╮
    │      │      │      │    ┗━━━┛ │
 ╭──│──────│──────│──────│──────────╯
 │  ↓      ↓      ↓      ↓
 ╰─→⊕   ╭─→⊕   ╭─→⊕   ╭─→⊕
    │   │  │   │  │   │  │
    ↓   │  ↓   │  ↓   │  ↓    ┏━━━┓
   k_4 ─╯ k_5 ─╯ k_6 ─╯ k_7 ─→┃f_2┃─╮
    │      │      │      │    ┗━━━┛ │
 ╭──│──────│──────│──────│──────────╯
 │  ↓      ↓      ↓      ↓
 ╰─→⊕   ╭─→⊕   ╭─→⊕   ╭─→⊕
    │   │  │   │  │   │  │
    ↓   │  ↓   │  ↓   │  ↓     ┏━━━┓
   k_8 ─╯ k_9 ─╯ k_10 ╯ k_11 ─→┃f_3┃─╮
    │      │      │      │     ┗━━━┛ │
 ╭──│──────│──────│──────│───────────╯
 │  ↓      ↓      ↓      ↓
.......................................
 │  ↓      ↓      ↓      ↓
 ╰─→⊕   ╭─→⊕   ╭─→⊕   ╭─→⊕
    │   │  │   │  │   │  │
    ↓   │  ↓   │  ↓   │  ↓
   k_40 ╯ k_41 ╯ k_42 ╯ k_43

The key expansion works in a way that ki only depends directly on ki−1 and ki−Nk (where Nk is the number of columns in the key, i.e. 4 for AES-128). In most cases it is a simple ⊕, but after each Nk key columns, a non-linear function fi is applied....The functions fi are nonlinear functions build from the AES S-box (applied on each byte separately), a rotation by one byte, and an XOR with a round constant depending on i (this is the element of GF(28) corresponding to xi−1, but there also is a table in the standard). Then the key selection algorithm simply takes k0…k3 as the first round key, k4…k7 as the second one, until k40…k43 as the last one.

Question 2

Martin Dinov has a good explanation of a method to derive subkeys using a key schedule. But subkeys may not even be present in some algorithms. Even then, the subkeys are symmetric for both encryption and decryption, so where's the asymmetry?

What's more likely is that Wikipedia is hinting at key derivation. This is used during many cryptographic protocols, for example for many travel cards. Most current travel cards are memory cards that contain a (set of) symmetric keys per card. These keys have been derived by performing a key derivation mechanism using a unique identifier - normally the UID for contactless chips such as MIFARE or DESFire - and a master key. So the card terminal has the master key, reads the UID and calculates the card specific keys to get read or write access.

So even though the card and terminal have different keys before they start secure communication, the card keys - and then possibly the session keys - are derived by a key derivation mechanism by the terminal. The session keys - keys used to secure the transport protocol - are sometimes calculated on higher end chips using some kind of authenticated key agreement protocol such as Diffie Hellman.