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 <[EMAIL PROTECTED]> JabberID: <[EMAIL PROTECTED]> Hostes alienigeni me abduxerunt. Qui annus est? PGP Key 0xA99CEB6D = 5957 6D23 8B16 EFAB FEF8 7175 14D3 6485 A99C EB6D
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. _______________________________________________