What's the best symmetrical .net encryption provider for size?

I have a scenario where I need to serialize a struct to a byte array or string, encrypt it and then store it in a SQL table.

The issue is that it's possible that this table will run into millions of rows and so size is all important.

I've been using the BinaryFormatter to serialize to a byte[], converting it to Ascii and then compr开发者_如何学编程essing it with the RijndaelManaged provider.

Prior to encryption, the string is about 230 bytes. Post encryption, it is over 600 bytes.

Does anyone know if any of the other cryptographic providers would do a better job of this? Or, if indeed there's a better way that I should be going about this?

Thanks very much in advance,

Z

In general, encryption algorithms only add a fixed overhead (for IV and, in the case of asymmetric encryption algorithms, the encrypted symmetric key). If you're seeing a 2x increase in size, that indicates that you are doing something before or after encrypting that increases the size of the data.

I would remove the ascii conversion - encryption algorithms work just fine on raw binary data - and make sure you are storing into the database as a raw binary blob, rather than base64-ing or similar. If you still have trouble, please post the code you're using.

I've found the issue.

I've done a few things 1/ stopped using .net serialization. I notice that serialized content includes assembly information (eg culture, version etc) with every object. It even does this when you override ISerializable and 'roll your own'. I can see why it needs that to re-serialize... but I don't want to store that in every row. Instead I've just built a delimited string and converted that to a byte array. I 're-serialize' myself.

2/ I stopped trying to convert the byte[] to a string (with some sort of encoding) prior to encryption. I now just pass the byte[] into rijindal.

3/ I've started using varbinary in the table and am writing the encrypted result as raw bytes. That seems a lot more efficient than trying to use some sort of encoding.

So - with all that, I've got the final, encrypted product down to about 150 bytes. Big improvement! ... also, I haven't tried compressing it yet either.

Thanks for peoples help :-)

Z