acmeattic-devel team mailing list archive

[Karthik Swaminathan Nagaraj <nkarthiks@xxxxxxxxx>]

On Mon, Jul 12, 2010 at 2:09 AM, Aditya Manthramurthy
<aditya.mmy@xxxxxxxxx>wrote:

>  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> 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.
>
> The only miscommunication for me was that I assumed that a new keypair
would be generated, now that the server knows the identity of the client.
Either implementation is fine with me.

>
>     1. 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?
>
I would like to keep separate keys for separate machines. If we follow the
SpiderOak model, each client (for the same user) has a unique identity and
maintains its own synced folders. Thus maintaining a separate key is not an
issue and somewhat feels like a cleaner separation to me (gut feeling).

>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~acmeattic-devel<https://launchpad.net/%7Eacmeattic-devel>
> Post to     : acmeattic-devel@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~acmeattic-devel<https://launchpad.net/%7Eacmeattic-devel>
> More help   : https://help.launchpad.net/ListHelp
>
>


-- 
Karthik