From DojoWiki

April Meeting - April 24th 2008

Proposed Authentication Spec

• This replaces Client Interaction 2 and Server Interaction 1. (From the March Meeting Client/Server Comm - March 27th 2008 )
• The following interactions are for Client and Server.
• Possibly also consider a persistent storage of user credentials.
  • Without persistent storage, the authentication is very weak, because the user is supplying the publicKey on login.
  • So they could generate a fresh key pair and login as someone else (since they just generated the privateKey and publicKey)

1. Client: After the client connects, the client sends: name|publicKey\n
2. Perform challenge/response authentication
   1. Server: sends block of random data
   2. Client: signs the received data and sends it back. (encrypts it with his private key)
   3. Server: verifies the signed data (decrypts with public key and compares with originally sent challenge)
   4. Server: On successful login, it returns a random session key
   5. Server: On failure, sends back an error message
3. All future commands from the client must include the session key.

The public key could then be used for transmissions for encrypted chats if we wanted to get into that.