views:

323

answers:

2

I've migrated my database on my mobile device away from VistaDB because it's just too slow. I'm now using ProtoBuf instead to create a series of flat files on a Storage Card, the only issue is there's obviously no encryption.

Which encryption method works best with ProtoBuf? I'm basically serializing a collection of data entities to a file, then deserializing from the File back into my collections. I figure the best place to put the encryption would be in the FileStream on the read/write.

The data will contain NI numbers, names and addresses, so this has to be secure. Any idea anyone?

+2  A: 

I think you're on the right track. You should just be able to do something like:

ICryptoTransform encryptor = ...
Stream encStream = new CryptoStream(outputFileStream, encryptor, CryptoStreamMode.Write);
Serializer.Serialize(encStream, obj);
encStream.FlushFinalBlock()
encStream.Close();

ICryptoTransform decryptor = ...
Stream decStream = new CryptoStream(inputputFileStream, decryptor, CryptoStreamMode.Read);
Serializer.Deserialize<Type>(decStream);
decStream.FlushFinalBlock()
decStream.Close();

For the basics of .NET's encryption framework (including how to get the ICryptoTransform objects, see other questions like What’s the best way to encrypt short strings in .NET?.

Matthew Flaschen
Obviously, apologies for the dups. It was due to a SO bug.
Matthew Flaschen
+1  A: 

Another option is to actually encrypt the entire folder where the data is stored by installing a system-wide file system filter. The advantages here are that:

  1. Your app code is agnostic to the encryption and the encryption will be done in native code.
  2. Since the encryption is done in native code, it's going to be faster
  3. Since the encryption is not inside managed code, it's a lot harder to reverse engineer and figure out your keys, salts, etc.

Of course the disadvantage (for those who don't write C anyway) is that you can't write it in C#.

ctacke
i don't know how much faster native code will really be. It probably depends how much data is in question. I also don't think managed code will make the keys that much more obvious. Either way, the keys should be in memory for a short period of time (potentially visible to a debugger) and never on disk.
Matthew Flaschen
What is the best way of using the key? I need to know the key so that the data can be encrypted/decrypted on the server and client side. That means both sides need to know the key, also I need the ability to put the card that the data will be stored on into a new PDA on the fly and still be able to view the data. Is it bad practise to store the key in source?
GenericTypeTea
Yes, storing the key (unencrypted) anywhere on the hard drive (including in source code) means it's basically compromised immediately. This is why DRM schemes always end up broken.
Matthew Flaschen
DIsassembling managed code with Reflector makes it really easy for a junior "hacker" to find the key. If it's buried in native bytecode, it takes a lot more skill to disassemble and find it.
ctacke