|
|
|
|
|
|
by regedit728
613 days ago
|
|
|
Minor correction (I'm assuming it was a typo) -- the secret for the passkey should be the private key. The server stores the user's corresponding public key. Based on my (limited) understanding from reading the page:
1. Server generates challenge, sends a challenge
2. User device signs the challenge by encrypting with its private key, returns the signature.
3. Server verifies the signature by decrypting with the public key. As you mentioned, the private key (the only thing that can generate a valid signature) isn't leaked. |
|
|
Yeah, I meant "public key" in the sense of "public-key cryptography". I've edited the comment to make this clearer. Thanks for pointing that out.
> Based on my (limited) understanding from reading the page: 1. Server generates challenge, sends a challenge 2. User device signs the challenge by encrypting with its private key, returns the signature. 3. Server verifies the signature by decrypting with the public key.
That is almost exactly right, but since we're being precise here, I would just pick on this one very minor nit:
> User device signs the challenge by encrypting with its private key
> Server verifies the signature by decrypting with the public key
"Signing/verification" and "encrypting/decrypting" are two completely different things. In RSA these are conflated, but it's important not to confuse them. With elliptic curves, these have nothing to do with each other. It's just a peculiarity of RSA that makes it encrypt/decrypt to do digital signatures.