Most cryptographic libraries I've encountered uses some variant of
processPlaintext(...) and then
doFinal() to produce the ciphertext and resets the state.
In the context of packet communications, it feels like it would be optimal to setup key and IV once and then use that single initialisation in some way for all packets on the same channel.
In the case of CBC + padding, one could re-initialise the cipher with the last cipher block as IV.
(If I use a stream cipher, or manually implement CTR, it's straightforward of course.)
It would be nice to be able to use GCM to avoid manually adding authentication. However, it would appear that the usual implementations are geared towards encrypting a single packet - and resets all internal state on doFinal.
I would like to provide only a single IV for GCM, and then in some safe way either keeping the original state, or derive consequent IVs from the initial IV in a secure manner.
What I wonder is consequently:
Are there implementations that allow you not to reset the state when finalising a packet (i.e. making encryption and authentication dependent on the previous packet)? Failing that, what would be a safe way to derive consequent IVs from an initial IV value?
(I've not read about GCM sufficiently in depth - so I have no idea if there is a significant cost to setting up GCM with an IV)