pqwy
commented
9 years ago Hey,
As discussed -- the reason counter was changed in-place was to signal its final value to the caller. In some usage scenarios, all the blocks encrypted with a single key use an unbroken sequence of counting blocks and in those cases you would want a simple way to continue the next message where the previous one stopped.
But I agree, actually changing that parameter was a very poor design (made hastily before the first release).
After several changes to the API, I settled on leaving the incoming block alone and instead taking the offset into the conceptual counter stream.
The current master should be nicer in this respect. And you get hardware acceleration as a bonus.
It's probably better if there is no side effect into the "ctr" who is given by parameter. See tests/test_ctr.ml, with side effect the initial value of "ctr" can not be retrieving... and without side effect we copy the cstruct into another temporary cstruct.