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

[Russ Housley <[e-mail]>]

> On Oct 28, 2022, at 7:27 AM, Stephen Farrell <[e-mail]> wrote:
> 
> Signed PGP part
> 
> 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.

Stephen:

AES-CCM and AES-GCM require the authentication check to be performed before any plaintext is returned.  So, one would have to have a separate tag for each storage block, which adds a lot of overhead and complexity, especially since there is already a digital signature over the whole thing.

Russ