Subject: [COSE] Authentication tag

From: Samuel Erdtman <[email-masked]>
Date: Fri, 17 Mar 2017 17:50:01 +0100

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

---

From: Ilari Liusvaara <[email-masked]>
Date: Fri, 17 Mar 2017 19:10:40 +0200

> the auth tag is appends to the end of the ciphertext.

Well, COSE specification refers to RFC 5116 for definition of AE and
AEAD, and that framework only allows single ciphertext output, which
as consequence must contain the tag.

(How it contains the tag is actually algorithm-dependent, but most
have it at the end).

-Ilari

---

From: Jim Schaad <[email-masked]>
Date: Fri, 17 Mar 2017 10:27:29 -0700

>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-masked]] 
Sent: Friday, March 17, 2017 9:50 AM
To: cose <[email-masked]>; Jim Schaad <[email-masked]>
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

---

From: Samuel Erdtman <[email-masked]>
Date: Sat, 18 Mar 2017 21:08:09 +0100

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-masked]> 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-masked]]
> *Sent:* Friday, March 17, 2017 9:50 AM
> *To:* cose <[email-masked]>; Jim Schaad <[email-masked]>
> *Subject:* Authentication tag
>
>
>
> Hi
>
> 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.
>

---

From: Ilari Liusvaara <[email-masked]>
Date: Sat, 18 Mar 2017 23:09:14 +0200

> allowed to put the tag in the COSE headers.

Yes.

> normative requirement on the location of the tag in a ciphertext?

RFC 5116 gives the tag location for AEAD_AES_{128,256}_GCM: It is
appended.

AEAD_CHACHA20_POLY1305 initially got it wrong, the document has
errata that the tag is also appended.

But there are RFC 5116-framework AEAD algorithms that don't append
the tag. E.g AEAD_AES_SIV_CMAC_* prepends the equivalent of tag,
not appends.

> language about where to find/put the tag.

Funkily enough, COSE has AES-192-GCM, but there is no registered AEAD
cipher for that. And then COSE has plenty of CCM ciphers, which
probably don't have registed counterparts.

Also, I didn't find any reference based on quick look that would
say that the tags are definitely appended (but that's the only
sane way).

-Ilari

---

From: Jim Schaad <[email-masked]>
Date: Sat, 18 Mar 2017 14:09:23 -0700

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-masked]] 
Sent: Saturday, March 18, 2017 1:08 PM
To: Jim Schaad <[email-masked]>; [email-masked]
Cc: cose <[email-masked]>
Subject: Re: Authentication tag

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.

Cheers

//Samuel

 

From: Samuel Erdtman [mailto:[email-masked] <mailto:[email-masked]> ] 
Sent: Friday, March 17, 2017 9:50 AM
To: cose <[email-masked] <mailto:[email-masked]> >; Jim Schaad <[email-masked] <mailto:[email-masked]> >
Subject: Authentication tag

Hi 

Cheers

Samuel Erdtman

---

From: Samuel Erdtman <[email-masked]>
Date: Mon, 20 Mar 2017 20:57:49 +0100

Thanks again!

I think this will add some clarity for tormentors.

//Samuel

On Sat, Mar 18, 2017 at 10:09 PM, Jim Schaad <[email-masked]> 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.
>
>
>
> *Sent:* Saturday, March 18, 2017 1:08 PM
> *To:* Jim Schaad <[email-masked]>; [email-masked]
> *Cc:* cose <[email-masked]>
> *Subject:* Re: Authentication tag
>
>
>
> 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?
>

---

From: Samuel Erdtman <[email-masked]>
Date: Mon, 20 Mar 2017 20:58:10 +0100

*implementers

On Mon, Mar 20, 2017 at 8:57 PM, Samuel Erdtman <[email-masked]> wrote:

>> definition. For simplicity sake, the authentication code will normally
>> be defined as being appended to the cipher text stream. The encryption
>> functions are:
>>
>>
>>
>>
>>
>> In the examples provided with the COSE specification I could find out
>> that the auth tag is appends to the end of the ciphertext.
>>
>> 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
>>
>>
>>
>>
>>
>
>

---

From: Justin Richer <[email-masked]>
Date: Mon, 20 Mar 2017 16:09:54 -0400

Well you weren’t necessarily *wrong* the first time.

 — Justin, not as chair

> On Mar 20, 2017, at 3:58 PM, Samuel Erdtman <[email-masked]> wrote:
> 
> *implementers 
> 
> On Mon, Mar 20, 2017 at 8:57 PM, Samuel Erdtman <[email-masked] <mailto:[email-masked]>> wrote:
> Thanks again!
> 
> On Sat, Mar 18, 2017 at 10:09 PM, Jim Schaad <[email-masked] <mailto:[email-masked]>> wrote:
> From: Samuel Erdtman [mailto:[email-masked] <mailto:[email-masked]>] 
> To: Jim Schaad <[email-masked] <mailto:[email-masked]>>; [email-masked] <mailto:[email-masked]>
> Cc: cose <[email-masked] <mailto:[email-masked]>>
> On Fri, Mar 17, 2017 at 6:27 PM, Jim Schaad <[email-masked] <mailto:[email-masked]>> wrote:
> 
> From Section 10:
> 
>  
> 
> From: Samuel Erdtman [mailto:[email-masked] <mailto:[email-masked]>] 
> To: cose <[email-masked] <mailto:[email-masked]>>; Jim Schaad <[email-masked] <mailto:[email-masked]>>
> _______________________________________________
> COSE mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/cose

---

From: Renzo Navas <[email-masked]>
Date: Tue, 21 Mar 2017 14:06:20 +0100

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 <[email-masked]> wrote:
>>> included as part of the cipher text.  For SIV mode it is the IV and there is
>>> no extra authentication tag.
>>>
>>>
>>>
>>> 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.
>>>
>>>
>>>
>>> additional field, and thus one or more bytes are removed from the encoding.
>>> This followed the guidance of trying for very short encodings.
>>>
>>>
>>>
>>> cannot put it in a header attribute then I would like more explicit language
>>> about where to find/put the tag.
>>>
>>> encryption process will generate some type of authentication value, but that
>>> value may be either explicit or implicit in terms of the algorithm
>>> find it. It might be described in some refereed specification but it was not
>>> obvious to me at least.
>>>