Robin Sheat wrote:
> Basically, I needed to encrypt the on-disk format of some data that is
> accessed as a seekable file (it's actually a Lucene index, but the details
> aren't too relevant). The use case for this is to ensure the data is kept
> private, even if the disk or computer the data is on is taken (it's a
> network-aware client app, so they log in to the program using a username and
> password).
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?
> * 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.
> * Is it wise to use the user's password directly, or should that perhaps be
> used to encrypt a key, and that key used to encrypt the files? This would
> certainly make changing the password easier, but if that key is ever
> compromised, it's a bigger issue.
You can get a little extra security with an encrypted keyfile for
certain attack scenarios if done properly. With your design, if I have
only the encrypted file, I can start brute-forcing passwords
immediately. Might not be practical, depending on how big the salt is,
and whether I got that too.
If there's an encrypted keyfile, I have to steal that too, plus I still
have the exact same amount of brute forcing to do. So, the decisions
depends on whether stealing the encrypted data almost always allows me
to steal the keyfile, or if you can do something significant;y better,
like having the user store the keyfile on a USB drive or the remote
server or something.
In order to not have created an irrevocable encryption key, every time
the user changes their password, you should create a new encryption key
and re-encrypt the data with that key, rendering the old stolen keyfile
useless.
>
> * The Java crypto system looks like black-magic. I haven't seen many things
> that talk about how to use it well. How do I know I'm not using it in some
> vulnerable fashion?
I can't help you there. I know nothing about Java's implementation
details, nor can I tell if you've created a stream cipher that can be
decrypted by XORing with itself or something else silly.
Ryan
_______________________________________________
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.
_______________________________________________
