Best practices for encrypting client-side data

[robin at kallisti.net.nz (Robin Sheat)]

On Wednesday 09 May 2007 05:04:53 you wrote:
> You go on to describe (I think) crypto operations that take place
> completely on the client site. What is the relationship between the
> encrypted data and server client->server communications?
For the purposes of this, there isn't. It was just to illustrate the point 
that a password is required and is checked by another component of the 
system. All the crypto (that I'm interested in here) is completely 
client-side.

> > * The salt is currently hard-coded. It should be regenerated for every
> > encryption operation in order to make it that much harder (question:
> > should it be a different salt used for every file encrypted by a user, or
> > one salt across all files by that user? Does it matter?)
> You should have a random salt every time you generate a hash or key.
Y'know, thinking about it more, I don't think that a salt would help at all in 
this situation. I'm not storing a hash of the password anywhere, the data is 
encrypted with the hash of the password, and to decrypt, the hash is 
regenerated from the user-supplied password.

...actually, I take that back. It would mean that each file (the data is 
composed of multiple smallish files) would have a different key, so if the 
attacker found the key to one, but not the password, they couldn't get to the 
other files. A small gain, but a gain nonetheless.

-- 
Robin <robin at kallisti.net.nz> JabberID: <eythian at jabber.kallisti.net.nz>

Hostes alienigeni me abduxerunt. Qui annus est?

PGP Key 0xA99CEB6D = 5957 6D23 8B16 EFAB FEF8  7175 14D3 6485 A99C EB6D
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://krvw.com/pipermail/sc-l/attachments/20070510/96253057/attachment.bin