acmeattic-devel team mailing list archive

[krishnan parthasarathi <krishnan.parthasarathi@xxxxxxxxx>]

>
>> 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?

>
>>

--
Krishnan