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 

> > * 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.


Hostes alienigeni me abduxerunt. Qui annus est?

PGP Key 0xA99CEB6D = 5957 6D23 8B16 EFAB FEF8  7175 14D3 6485 A99C EB6D

Attachment: pgpleZMK3XBCL.pgp
Description: PGP signature

Secure Coding mailing list (SC-L) SC-L@securecoding.org
List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
List charter available at - http://www.securecoding.org/list/charter.php
SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com)
as a free, non-commercial service to the software security community.

Reply via email to