FFI: botan_cipher_get_update_granularity() returns 17

[ni4]

....which is quite unlogical if application relies on this value. Root of this is in the ffi_choose_update_size() function and the fact that mode.update_granularity() returns 1.

[reneme]

I confirm!

This is true for the decryption of some AEAD modes. On the C++ level, some report a minimum_final_size() (of the tag length) and an update granularity of 1; notably ChaChaPoly, EAX, SIV and CCM. As a result, ffi_choose_update_size() produces 17. Also surprising: for GCM it reports 32 (due to both update granularity and minimum final size reporting 16 and ffi_choose_update_size() rounding up "17" to the next multiple of "update granularity").

Note that botan_cipher_get_ideal_update_granularity() (introduced in Botan 3.0) always reports reasonable values. However, documentation claims that "ideal granularity" is always a multiple of "update granularity", which obviously isn't the case for the configurations affected by this issue.

We should have caught that in #3951 already, but the tests that sanity-check the granularities aren't up to the job. Thanks a lot for scrutinizing this even before it gets released!

[reneme]

@randombit I feel the safest fix for this is to let botan_cipher_get_update_granularity() pass-through whatever is returned by Cipher_Mode::update_granularity() (see https://github.com/randombit/botan/pull/4094). This would remove the bug-prone logic in ffi_choose_update_size(). Functionally, it should be just fine after the changes in #3951 -- most notably the BOTAN_FFI_ERROR_INSUFFICIENT_BUFFER_SPACE handling added there.

Nevertheless, one could make a case about semver: Users that rely on the old behavior with the sufficiently sized update granularity, might trip over this. When updating to 3.5.0, they would either need to switch to botan_cipher_get_IDEAL_update_granularity() or handle BOTAN_FFI_ERROR_INSUFFICIENT_BUFFER_SPACE properly.

As an alternative to #4094, we could extend the logic in ffi_choose_update_size() to scale the minimal update granularity to ensure ideal granularity is a multiple of it. My gut tells me, that this will just make it more error-prone, though: e.g. when Cipher_Mode's update granularity is equal to its ideal granularity.