Reputation: 2465
I'm relatively new to C# and encryption, so please bear with me. I'm writing some data to a file and I wanted to encrypt it using Aes (CBC), but I'll get new data each day and I wanted to write all the data to one file per week, month, year, it depends on the content. Thus the "server" will be restarted / shut down definitely (it's not going to be a real server) and I wanted to know if it is possible to somehow get (and save to a file) the latest initialization vector with which I could after restart continue encrypting data and writing it to the same file. So that when I would decrypt the file I would just somewhere get the iv of the file and could decrypt it just with that one iv?
Pseudocode:
Encryption:
1.) encrypting data according to iv and key
2.) after data flow stops "special iv" is saved to one other file
3.) data flow stops, some time passes, "server" is shut down or restarted
4.) read "special iv" from file and continue with encryption 3. and 4. loop for a week, month, year
Decryption:
1.) read (somehow obtain) iv and key from that file
2.) decrypt the file with that iv and key
Decryption should not notice that encryption was ever stopped and application exited, ... I've got no idea how to realize this, how to get that "special iv". But I think this should be possible to realize.
What do you think, is there a reasonable way to obtain that special iv? Any ideas on how to do it?
Thank you a lot for your time and answers.
EDIT: I'm using .NET (4.0) implementation of AES and I would prefer to use that if possible
Upvotes: 1
Views: 1328
Reputation: 3194
What you propose is actually not completely secure. A description of a potential attack is in the paper "A challenging but feasible blockwise-adaptive chosen plaintext attack on SSL" by Gregory V. Bard.
The problem is that CBC requires that an IV can not be predicted by an attacker. However if you encrypt plaintext piecewise, then an attacker might learn the latest ciphertext block, which will basically be used as an IV for the next block that is encrypted an hence violates the requirement. The paper contains some examples, when the attack is feasible, but of course as the paper says it is not easy to exploit. Still it might be better to use for example the CTR mode, which does not have this limitation.
Upvotes: 0
Reputation: 2166
To decrypt any block in CBC mode, you only need the previous encrypted block: the plaintext will be "AES-decryption of current block XOR previous cipher block". As you encrypt, you will only write multiples of the block size to file, as this is how CBC works. When you start the encryption, so when you start filling the file, you have to pick an IV (random, different for every file you create, so make it depend on the time or some such thing), you write that to file as the very first "cipher text block", and then for every block of actual data, you XOR it with the previous block from the file (which in the beginning is the IV), and then encrypt with your block cipher. When you get new data later, we just use the last block that you already have.
Subtle point: as you only write multiples of blocks, you'll need padding. Make it so that you know how many bytes are padding and how many bytes are "real data". When you start with a next batch of data, you should somehow mark that the previous block ended a "data unit", so that you know that, when decrypting, you know which blocks you need to remove the padding of to get the actual data. So you'll need some wrapper around it, or the internal structure of the data (format) would always make this unambiguous. It's something to watch out for.
Upvotes: 5
Reputation: 30979
The "special IV" you refer to is just the current IV at the end of encrypting a single day's worth of data; your cryptographic library should be able to give that to you. Decryption of a block just requires the key and the IV for that block, so you can save (say) each day's IV to decrypt its data.
Upvotes: 1