I'm no security professional, just a programmer with a healthy interest in it, most of what I've gleaned has come from lists such as this, and the various securityfocus ones.
A little while ago I was asked to implement something that I didn't have much
of a low-level idea of, so I hope here is an appropriate place to ask.
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).
What I did was take the user's password to create a key (Java follows):
paramSpec = new PBEParameterSpec(salt, iteration);
PBEKeySpec keySpec = new PBEKeySpec(password.toCharArray());
SecretKeyFactory kf = SecretKeyFactory.getInstance("PBEWithMD5AndDES");
key = kf.generateSecret(keySpec);
this key is then used to initialise a cipher. The IV for the cipher is created
by the Java crypto system, and that is then written to the head of the
stream. Following that is an encrypted 'magic number', and the encrypted
data. Note that this happens when the file is closed, in the interim it is
buffered in RAM (due to the need to be able to seek anywhere within the file
while writing).
Decryption follows an (obviously) similar process, the key is generated as
above, the IV is read from the head of the stream and used to start the
cipher going, the magic number is checked to ensure it is what it should be
(so I know that decryption is happening correctly), and then the stream is
read and decrypted into memory.
There are some maybe-issues I'm aware of, but I'm not confident in my ability
to tell how significant they are, I'd appreciate any suggestions or comments.
* Buffering in RAM is an issue as it could get swapped out etc. I'd like to
know of any recommendations for creating a seekable, encrypted file.
* 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?)
* 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.
* 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?
* Is it OK to have the IV exposed like that, or should it be kept hidden
somehow? The impression I have is that it's OK for it to be known, so long as
it changes every time the file is written.
I know this is a bit off the vulnerability theme that this list often takes,
but I hope it's considered relevant enough to dig up some input.
Cheers,
--
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
pgpgIhTRygXHV.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. _______________________________________________
