On Thu, 14 Feb 2019 at 09:04, Eric Biggers <ebiggers@xxxxxxxxxx> wrote:
>
> From: Eric Biggers <ebiggers@xxxxxxxxxx>
>
> Make the arm64 ctr-aes-neon and ctr-aes-ce algorithms update the IV
> buffer to contain the next counter after processing a partial final
> block, rather than leave it as the last counter. This makes these
> algorithms pass the updated AES-CTR tests.
>
> Signed-off-by: Eric Biggers <ebiggers@xxxxxxxxxx>
I take it this means we return an output IV even if the algorithm
could never proceed in a meaningful way, given that we throw away some
keystream bits that would be needed in that case.
That means this change is strictly there to make the test framework
happy, even for cases that can never appear in reality.
Wouldn't it be better not to set out_iv for input buffers whose size
is not a multiple of the block size?
> ---
> arch/arm64/crypto/aes-modes.S | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/arch/arm64/crypto/aes-modes.S b/arch/arm64/crypto/aes-modes.S
> index 67700045a0e0..4c7ce231963c 100644
> --- a/arch/arm64/crypto/aes-modes.S
> +++ b/arch/arm64/crypto/aes-modes.S
> @@ -320,8 +320,7 @@ AES_ENTRY(aes_ctr_encrypt)
>
> .Lctrtailblock:
> st1 {v0.16b}, [x0]
> - ldp x29, x30, [sp], #16
> - ret
> + b .Lctrout
>
> .Lctrcarry:
> umov x7, v4.d[0] /* load upper word of ctr */
> --
> 2.20.1
>
