> On Oct 28, 2022, at 7:27 AM, Stephen Farrell <[email protected]> > 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
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
