Re: [PATCH 2/2] crypto: s5p - use correct block size of 1 for ctr(aes)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




On 20.08.2019 12:24, Krzysztof Kozlowski wrote:
> On Mon, 19 Aug 2019 at 16:24, Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx> wrote:
>>
>> Align the s5p ctr(aes) implementation with other implementations
>> of the same mode, by setting the block size to 1.
>>
>> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx>
>> ---
>>  drivers/crypto/s5p-sss.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/crypto/s5p-sss.c b/drivers/crypto/s5p-sss.c
>> index ef90c58edb1f..010f1bb20dad 100644
>> --- a/drivers/crypto/s5p-sss.c
>> +++ b/drivers/crypto/s5p-sss.c
>> @@ -2173,7 +2173,7 @@ static struct crypto_alg algs[] = {
>>                 .cra_flags              = CRYPTO_ALG_TYPE_ABLKCIPHER |
>>                                           CRYPTO_ALG_ASYNC |
>>                                           CRYPTO_ALG_KERN_DRIVER_ONLY,
>> -               .cra_blocksize          = AES_BLOCK_SIZE,
>> +               .cra_blocksize          = 1,
> 
> This makes sense but I wonder how does it work later with
> s5p_aes_crypt() and its check for request length alignment
> (AES_BLOCK_SIZE). With block size of 1 byte, I understand that
> req->nbytes can be for example 4 bytes which is not AES block
> aligned... If my reasoning is correct, then the CTR mode in s5p-sss is
> not fully working.

As I remember this case there are allocated buffers with len aligned up
AES_BLOCK_SIZE, source data copy to one buf, hw encrypts full block, 
then nbytes are copy back.

-- 
Best regards,
Kamil Konieczny
Samsung R&D Institute Poland




[Index of Archives]     [Kernel]     [Gnu Classpath]     [Gnu Crypto]     [DM Crypt]     [Netfilter]     [Bugtraq]

  Powered by Linux