acmeattic-devel team mailing list archive

[Karthik Swaminathan Nagaraj <nkarthiks@xxxxxxxxx>]

On Sun, Jul 11, 2010 at 11:33 PM, krishnan parthasarathi <
krishnan.parthasarathi@xxxxxxxxx> wrote:

>
>
>>> Thanks for writing it. We can restrict the encryption features for the
>>> first alpha release to include only server authentication (TLS), client
>>> authentication, and data encryption. Data encryption will involve secure
>>> per-file AES key creation and encryption.
>>>
>>> The AES key creation for a user from the password is a feature intended
>>> for the client challenge authentication (like in spideroak). I think we can
>>> keep this for a future alpha release. I have made changes to this effect on
>>> the blueprint.
>>>
>>
>> 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.

>
>>>
>
> --
> Krishnan
>



-- 
Karthik