On Sun, Jun 17, 2018 at 01:06:42PM +0300, Gilad Ben-Yossef wrote:
It was ctr(aes). I wrongly assumed that we are supposed to unconditionally copy the cipher-text block post operation and let the caller do with it what it wants and so the code now does that for all cipher operations unconditionally.
For CTR it doesn't matter whether the last block is less than a block, you should still increment the counter.
So what is a good description of what we are supposed to provide in that field post operation? The next IV? but as you stated, that is not necessarily useful for all ciphers.
When in doubt, please refer to the generic implementation. If that is still unclear or if it seems wrong, please post to the list.
Cheers,
On Tue, Jun 19, 2018 at 5:27 PM, Herbert Xu herbert@gondor.apana.org.au wrote:
On Sun, Jun 17, 2018 at 01:06:42PM +0300, Gilad Ben-Yossef wrote:
It was ctr(aes). I wrongly assumed that we are supposed to unconditionally copy the cipher-text block post operation and let the caller do with it what it wants and so the code now does that for all cipher operations unconditionally.
For CTR it doesn't matter whether the last block is less than a block, you should still increment the counter.
OK. got it. Although I am not sure how does one use this to continue encryption if the plaintext was not block aligned.
So what is a good description of what we are supposed to provide in that field post operation? The next IV? but as you stated, that is not necessarily useful for all ciphers.
When in doubt, please refer to the generic implementation. If that is still unclear or if it seems wrong, please post to the list.
Got it.
So as a sanity check if I understood correctly I need to: - Increment counter in IV for CTS - Copy last ciphertext block for CFB and CBC to output IV (partial blocks not allowed)
What about OFB? unless I've missed something there is no generic implementation... ?
Thanks again, Gilad
On Thu, Jun 21, 2018 at 04:35:44PM +0300, Gilad Ben-Yossef wrote:
What about OFB? unless I've missed something there is no generic implementation... ?
In general we shouldn't add hardware drivers for algorithms that do not have a generic implementation. Sometimes they slip through though.
Cheers,
linux-stable-mirror@lists.linaro.org