PSA API doesn't support streaming mode for AES 128 CTR

Hello,

ncs 2.6.0

device: nrf52840

we are migrating our code to Zephyr and noticed that PSA implementation of AES 128 CTR doesn't support pure streaming mode (or it's not mentioned how to use it), while this algorithm is intended to be used like that.

Specifically current Actual behavior (could be reproduced with AES CTR sample from Nordic):

1) psa_cipher_update decrypts\encrypts as much full 16 bytes blocks as it can

2) psa_cipher_finish decrypts\encrypts the remaining size of the message and calls psa_cipher_abort, that closes psa_cipher_operation_t (iv and counter)! 

With such behavior you can't:

1) Use same psa_cipher_operation_t object in order to continue encryption\decryption operations. Instead you have to initialize a new one, but the new one will have a wrong state of IV + counter!

2) So you can't use this library to encrypt\decrypt messages of any sizes! It's usable only for fixed or known beforehand sizes of messages! So it means you can't use it for any networking protocol (as we do).

I assume the correct Expected behavior of the implementation should be like this:

1) psa_cipher_update decrypts\encrypts whatever buffer size was given. There should be no limitations of block size (16 bytes), since AES CTR is XOR based algorithm.

2) psa_cipher_finish calls psa_cipher_abort and never return additional encrypted\decrypted data.

This issue is blocking us a lot, so I'd be highly appreciated if anyone can look at this.

Kind regards,

Oleh Hordiichuk

  • Hi Oleh,

    CryptoCell (the HW crypto accelerator) can only work on full blocks, so there is no API supporting this directly. However, it should be possible to do what you want. Then, do not call psa_cipher_finish(), but zero padd the last (partial) block, before calling psa_cipher_update() so that you only call this on full blocks. Keep the last block and xor that with the next input (the rest of this block).

  • Hello Einar,

    thank you for the suggestion. As an alternative way to your suggestion - it's possible to use AES ECB algorithm instead and create own implementation of counter increment and XORing plain text. 

    P.S., just in case you're interested in opinions :). IMHO this is a bad API design that an algorithm intended for encrypting\decrypting stream data can not be used like that. I don't think this is a CryptoCell limitation, but software implementation limitation, since it's possible to store the state in psa_operation_t. In any case I've never seen similar limitations in Java, Swift Crypto libraries, which are also having update\finish like API.

Related