I've come to use AES/SIC for my purpose as I want to write an encrypted file and read it back with the possibility to seek (I only need to read parts of it and don't want to decrypt the whole file just to read a single part of it).
SIC (using Bouncy Castle) looked promising. I've implemented a stream which is seekable but ended up with a weird issue. I wrote a few values and suddenly at a specific point data become a mess. I investigated into BC and how SIC was implemented. My conclusion: Each time I call
Write on the stream, the block number is used and transformed as nonce and internally the counter is increased. In my case I wrote Major and Minor of my version number in single calls, but read it in one go. The one part was okay, the other was a random number.
I now struggle with this, because I need to write the file differently than I would read it. Like writing in intermediate streams to create header files with relative positions in order to seek to the right position later. But since I am writing the header part and the whole body in one go, but read them sequentially field by field, it would not work.
My idea was to introduce a method, which calculates the counter by the current block number. Thus I could write multiple times with the same outcome until the block size has exceeded.
TL;DR: I'm no expert on cryptography, so here's what I want to know: Is it safe to calculate the counter based on the block number in the stream rather than increasing it every write? After all it's more predictable.
Alternatively what would be a good way to go? Is there any encryption algorithm / cipher mode which allows me to write and read in unequal amounts and is still seekable?