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