How does challenge-response with asymmetric encryption work for login?

Bob has Alice's public key. Bob picks a random response, encrypts it with pk_Alice, sends the ciphertext as the challenge. Only Alice can decrypt it.

Setup: Alice has sk_Alice; Bob has Alice's certificate / pk_Alice.

Login:

1. Alice → Bob: "I'm Alice".
2. Bob: pick random response. Send challenge = Encrypt(pk_Alice, response) to Alice.
3. Alice: decrypt → response = Decrypt(sk_Alice, challenge). Send back.
4. Bob: compare received value with the response he picked. OK / NOK.

Properties:

• The server never has Alice's secret key — only her public key. Server compromise doesn't leak login credentials.
• Alice proves possession of sk_Alice without ever transmitting it.
• The challenge encrypts a fresh random value, so no replay.

Vs. symmetric challenge-response: the big win is asymmetry of trust — the server never had the secret to begin with, so breach of the server doesn't compromise Alice. The cost is computation (RSA/EC operations are slower than HMAC) and key management (PKI).

Tip: Modern protocols (TLS 1.3, SSH) tend to prefer the signature variant (next card) over the encryption variant, because signatures don't require encrypting potentially sensitive responses, and signature schemes are slightly more flexible.