acmeattic-devel team mailing list archive

[Aditya Manthramurthy <aditya.mmy@xxxxxxxxx>]

On Monday 12 July 2010 10:40 AM, Karthik Swaminathan Nagaraj wrote:
> On Sun, Jul 11, 2010 at 11:33 PM, krishnan parthasarathi 
> <krishnan.parthasarathi@xxxxxxxxx 
> <mailto:krishnan.parthasarathi@xxxxxxxxx>> wrote:
>
>
>         I think there is a miscommunication in terms of what the AES
>         key is functioning in this context.
>         As per our earlier discussions, each user has a Master-key
>         file, which is encrypted and stored on the server. The
>         symmetric key used to encrypt the Master key file is what I
>         refer as the "user's AES key". It should be possible to
>         generate this key independently from any machine, irrespective
>         of machine crashes.
>         My proposal to /find/ this key is to use a consistent hashing
>         mechanism such as SHA256. On the client, as soon as the user
>         enters the passord, the plaintext password is hashed to
>         produce his AES key of 256bits in size.
>
>         This is how Spider Oak and many other authentication schemes
>         handle passwords and keys. The confusion is - this is
>         absolutely necessary for the client application in the first
>         release, and is pretty straightforward and simple. If you read
>         the SpiderOak documentation, their method to retrieve the
>         *assymmetric key pair* is to authenticate a machine another
>         time. This functionality can be added at a future release.
>
>     On a related note, how would we retrieve a user's lost private
>     key. Will a user's key pair be stored on the server with the
>     private  key alone encrypted with the user's AES key?
>
> If we think like SpiderOak, the idea is to authenticate the new client 
> by using the challenge mechanism (using salt, AES key, etc). Once this 
> succeeds, the client creates a new asymmetric keypair and gives the 
> public key to the server. The server would replace the old public key 
> with the new one and things would be back to normal. On every future 
> connection, the server can authenticate the client using the public key.
> Btw, This is planned for a future release.
Looks like there was some pretty bad miscommunication. Let me 
communicate the somewhat simpler method that I was thinking of, based on 
what little documentation there is of SpiderOak's methods:

  1. Each user has a RSA key pair that is created at account creation
     time. The public key is stored on the server, the private with the
     client.
  2. Each user also has an AES key generated from the password and a salt.
  3. The RSA key pair is encrypted with the user's AES key and also
     stored on the server.
  4. The master file is encrypted by the RSA public key (so that it can
     only be decrypted by the private key).
  5. All data sent by client is signed with the user's private key (so
     even clients are authenticated with the server).
  6. All data received from the server is under a secure TLS
     connection, so server is authenticated as well.
  7. When a user loses all client data, the RSA key pair can be
     recovered in the following way:
        1. First a challenge mechanism based on the user's AES key is
           used to authenticate the user.
        2. If that succeeds, the server sends back the encrypted RSA
           key pair, and the client decrypts it and recovers the client
           setup that was lost initially.
  8. When a user wants to add a new client machine to her attic, either
     the RSA private key can be manually copied to the new machine
     (which is bad), or the challenge mechanism can again be used to
     recover the RSA key pair on the client machine (should be preferred).

This method avoids the loss and regeneration of RSA keys, and makes it 
easy to add a new machine to an account on the server. Thoughts?