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 

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.


Hostes alienigeni me abduxerunt. Qui annus est?

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

Attachment: 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.

Reply via email to