Re: [COSE] COSE Support for AES-CTR and AES-CBC

[Stephen Farrell <[e-mail]>]

Hiya,

I was curious as to how this requirement might arise so I
took a look...

On 28/10/2022 10:44, Hannes Tschofenig wrote:
> 
> https://datatracker.ietf.org/doc/html/draft-ietf-suit-firmware-encryption-09
> provides a more detailed description of the firmware update scenario,
> see particularly Section 8.
That says:

    The ability to restart an interrupted firmware update is often a
    requirement for low-end IoT devices.  To fulfill this requirement it
    is necessary to chunk a firmware image into sectors and to encrypt
    each sector individually using a cipher that does not increase the
    size of the resulting ciphertext (i.e., by not adding an
    authentication tag after each encrypted block).

And then...

  For this purpose ciphers without integrity protection are used to
    encrypt the firmware image.  Integrity protection for the firmware
    image must, however, be provided and the the suit-parameter-image-
    digest, defined in Section 8.4.8.6 of [I-D.ietf-suit-manifest], MUST
    be used.

I'm not convinced by that. Why couldn't you just store
the tag for each chunk wherever the signature is stored?

Overall, I'd say defining non-AEAD modes doesn't seem
like a good trade-off.

S.