*implementers On Mon, Mar 20, 2017 at 8:57 PM, Samuel Erdtman <[email protected]> wrote:
> Thanks again! > > I think this will add some clarity for tormentors. > > //Samuel > > On Sat, Mar 18, 2017 at 10:09 PM, Jim Schaad <[email protected]> > wrote: > >> There are two different schools of thought about where to put the >> authentication tag. RFC 5116 was designed so that it is part of the >> standard set of parameters rather than separate. Thus, for GCM, it is >> included as part of the cipher text. For SIV mode it is the IV and there >> is no extra authentication tag. >> >> >> >> Other encodings have made the fields be separate, JOSE and CMS keep the >> tag and the cipher text as separate items and, for some systems, you then >> get the opposite world of needed to combined them when doing decryption >> operation. The decision of where and how authentication tags are placed >> is always going to be an encoding decision and not part of the encryption >> algorithm. >> >> >> >> The decision was made to combine them for COSE because it saved an >> additional field, and thus one or more bytes are removed from the >> encoding. This followed the guidance of trying for very short encodings. >> >> >> >> I have filed an issue to remember this at the next revision. >> >> >> >> Jim >> >> >> >> >> >> >> >> *From:* Samuel Erdtman [mailto:[email protected]] >> *Sent:* Saturday, March 18, 2017 1:08 PM >> *To:* Jim Schaad <[email protected]>; [email protected] >> *Cc:* cose <[email protected]> >> *Subject:* Re: Authentication tag >> >> >> >> Thanks Jim and Ilari for the quick replies. >> >> So if I understand it correctly RFC 5116 defines AE and AEAD with the >> requirement to bundle the tag with the ciphertext, so it would not be >> allowed to put the tag in the COSE headers. >> >> Section 10 Content Encryption Algorithms, gives a hint of where to find >> the tag, 'normally' appended. Forgive me my ignorance, but does GCM have a >> more normative requirement on the location of the tag in a ciphertext? >> >> If GCM does not mandate the location of the tag in the ciphertext and we >> cannot put it in a header attribute then I would like more explicit >> language about where to find/put the tag. >> >> Once again thanks for the quick and enlightening reply. >> >> Cheers >> >> //Samuel >> >> >> >> >> >> On Fri, Mar 17, 2017 at 6:27 PM, Jim Schaad <[email protected]> >> wrote: >> >> From Section 10: >> >> >> >> COSE restricts the set of legal content encryption algorithms to those >> that support authentication both of the content and additional data. The >> encryption process will generate some type of authentication value, but >> that value may be either explicit or implicit in terms of the algorithm >> definition. For simplicity sake, the authentication code will normally >> be defined as being appended to the cipher text stream. The encryption >> functions are: >> >> >> >> >> >> *From:* Samuel Erdtman [mailto:[email protected]] >> *Sent:* Friday, March 17, 2017 9:50 AM >> *To:* cose <[email protected]>; Jim Schaad <[email protected]> >> *Subject:* Authentication tag >> >> >> >> Hi >> >> I´m working on a JavaScript implementation of the COSE msg specification, >> currently working on the GCM encryption. >> >> In the nodejs crypto environment the authentication tag is set separately >> i.e. a specific setAuthTag call. I looked into openssl and could see that >> that was the case there too. >> >> In the examples provided with the COSE specification I could find out >> that the auth tag is appends to the end of the ciphertext. >> >> I tried to find this described in the COSE specification but could not >> find it. It might be described in some refereed specification but it was >> not obvious to me at least. >> >> If it is not to late I would suggest that authentication tag is lifted >> out from the ciphertext and into the unprotected header similar to IV. Or >> that it is explicitly described that the authentication tag should be >> appended to the ciphertext. >> >> Cheers >> >> Samuel Erdtman >> >> >> >> >> > >
_______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
