views:

117

answers:

2

Hi all,

I'm looking for a low-level encryption to write questions/answers for a test/exam application in Java. Both the questions and exam are objects. Basically, I need a way to serialize a object, write it to a file, whilst encrypting everything so no one can read the question/answers without my program.

I've heard of Protocol Buffers (http://code.google.com/apis/protocolbuffers/docs/javatutorial.html), but not sure if there is something newer/better out there or if it is the next best thing.

Cheers -Tanner

+4  A: 

You need two steps - serialization/deserialization, which converts an object to a representation which can be stored on disk; and encryption/decryption, which enciphers the on-disk representation.

In Java you can use an ObjectOutputStream to perform the serialization, and a CipherOutputStream to perform the encryption. First obtain a FileOutputStream, then pass that to the constructor of a CipherOutputStream, then pass that to the constructor of an ObjectOutputStream. Then you can just hand your Serializable object(s) to the ObjectOutputStream, and they'll end up serialized, encrypted and written to a file. (You will of course need to perform additional setup on at least the CipherOutputStream object, but that's the basic idea).

However, there is a rather large caveat to all of this. The encryption you're doing is no more than obfuscation - if you give someone the encrypted data and a program that can decrypt it, that person has all the information they need to decrypt the data themselves. There's no way to get around this - if your program can decrypt it, then your program can be pulled apart and its secrets found.

caf
A: 

Judging from your description of the application, performance is not a concern. So a solution that serializes to XML (e.g. using XStream) and then encrypts the XML would be satisfy your requirements.

However, I should warn you that there is a significant risk that student with sufficient incentive could hack your encryption. I can think of only ways you can guard against this:

  1. don't store the encrypted data on the user's machine at all, or
  2. use an asymmetric cipher and don't ever do any decryption on the user's machine.

If you cannot do one or the other, your application is vulnerable. Hacking it is not quite as simple as reading the files with a text editor, but it is not all that hard either ... even if you feed the application through an JAR file obfuscator.

Stephen C
XStream seems quite easy to use and applicable.So are you telling me the only way to encrypt anything would to let the user's computer not have anything to do with the encrypted data? Whilst that isn't exactly applied in this situation for I, the highest level of hacking I expect is script-kiddie, but I'm not sure how easily accessible it would be storing the decryption method in the client code...
Tanner
I think what I'm getting at is, am I right that having the user take apart my program with the encrypted data would require a fair amount of knowledge and skills (a.k.a. they'd need to know what they're doing and stuff)?
Tanner
@Tanner - that is correct. But there are lots of folks out there with the skill to do it; e.g. half the folks who post answers here would have no trouble. Its just a matter of whether there is enough incentive to do it.
Stephen C
@Tanner - re first comment. Not quite as simple as that. There are two kinds of cipher, symmetric and asymmetric. For an asymmetric cipher you encrypt with one key and decrypt with a different key, and (most importantly) it is computationally impractical to derive one key from the other.
Stephen C