Re: [COSE] Authentication tag

Hi COSE WG!

Just to add weight to the request of clarifying this on the COSE
document (if its already possible),

I faced the same problem as Samuel (up until this morning),
I am implementing decryption of Encrypt0 cose objects; testing with a
decryption of a COSE Enc0 object AES-CCM-16-64-128 generated with
https://github.com/cose-wg/COSE-JAVA

And the clearer text I found was on "1.1. Design changes from JOSE"  :
 " * Combine the authentication tag for encryption algorithms with the
cipher text."
Now Jim pointed section 10 that also clarifies that.

I think that putting some text on section 5.2/5.3/5.4 will be really
helpful for implementers.
Then reading only Section 5.2-5.4 will clarify almost everything to
needed to decrypt/encrypt an Encrypt0 object.

For instance on Section 5.3 (how to encrypt)
"5.  .. Place the returned cipher text [with the appended returned
authentication tag] into the 'ciphertext' field of the structure."

The decryption instruction will need a little bit more phrasing to
explain; but once at least the encryption is clear, will be easily
understandable for anyone reading the doc.

Thank you for the work Jim and the nice already working implementations!

Renzo

On Mon, Mar 20, 2017 at 9:09 PM, Justin Richer <jricher@mit.edu> wrote:
> Well you weren’t necessarily *wrong* the first time.
>
>  — Justin, not as chair
>
>
> On Mar 20, 2017, at 3:58 PM, Samuel Erdtman <samuel@erdtman.se> wrote:
>
> *implementers
>
> On Mon, Mar 20, 2017 at 8:57 PM, Samuel Erdtman <samuel@erdtman.se> wrote:
>>
>> Thanks again!
>>
>> I think this will add some clarity for tormentors.
>>
>> //Samuel
>>
>> On Sat, Mar 18, 2017 at 10:09 PM, Jim Schaad <ietf@augustcellars.com>
>> 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:samuel@erdtman.se]
>>> Sent: Saturday, March 18, 2017 1:08 PM
>>> To: Jim Schaad <ietf@augustcellars.com>; ilariliusvaara@welho.com
>>> Cc: cose <cose@ietf.org>
>>> 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 <ietf@augustcellars.com>
>>> 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:samuel@erdtman.se]
>>> Sent: Friday, March 17, 2017 9:50 AM
>>> To: cose <cose@ietf.org>; Jim Schaad <ietf@augustcellars.com>
>>> 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
> COSE@ietf.org
> https://www.ietf.org/mailman/listinfo/cose
>
>
>
> _______________________________________________
> COSE mailing list
> COSE@ietf.org
> https://www.ietf.org/mailman/listinfo/cose
>