Subject: Re: [Cose] AES based MAC algorithm

From: Brian Campbell <[email-masked]>
Date: Wed, 1 Jul 2015 09:35:20 -0600

What's the motivation for an AES based MAC (vs. say an HMAC)? Is it the
hope that a broader set of COSE could be supported by something that only
has to support AES? Or something else?

On Tue, Jun 30, 2015 at 5:20 PM, Mike Jones <[email-masked]>
wrote:

> Do you have data on how commonly available implementations of these
> algorithms are to help inform the choice?  As you know, in JOSE we drove
> the set of algorithm choices off of a survey of which algorithms were
> implemented on which common development platforms.  (See the attached
> spreadsheet.)
>
> I realize that in this case, the right sets of development platforms to
> survey may be different than the largely Web-targeted development platforms
> that JOSE surveyed.  For COSE, the right tools are more likely to be
> embedded systems development platforms.
>
> Anyway, if we can make this choice based on data, that would be good.  If
> the data shows that people will have to largely build AES-MAC or AES-CMAC
> from scratch because their platforms don't support either of them, then I
> agree with your preference for AES-CMAC.
>
>                                 -- Mike
>
> -----Original Message-----
> From: Cose [mailto:[email-masked]] On Behalf Of Jim Schaad
> Sent: Tuesday, June 30, 2015 3:59 PM
> To: [email-masked]
> Subject: [Cose] AES based MAC algorithm
>
> In doing the work on getting algorithms into the document I ended up with
> a "Which one" question.
>
> AES-MAC has historically been the block cipher MAC algorithm used by most
> people.  In part because it has been around the longest.  It does the
> traditional AES-CBC mode of encryption and then takes the last block of the
> output as the MAC value.
>
> AES-CMAC (also known as AES-OMAC1) is a variant of the same algorithm
> which uses one extra encryption operation and an XOR operation at the end
> of the process to provide higher security than is available with AES-MAC.
> Details of this algorithm can be found in RFC 4493.
>
> Do people have a preference as to which of these two algorithms is
> specified?  My personal preference leans towards using the newer algorithm
> as there is not a significant performance penalty and it appears to have
> better security properties.
>
> Jim
>
>
> _______________________________________________
> Cose mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/cose
>
> _______________________________________________
> Cose mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/cose
>
>

---

From: "Jim Schaad" <[email-masked]>
Date: Wed, 1 Jul 2015 11:31:54 -0700

The motivation that I have is two-fold:

1.       I have been told that this is the more common way to do integrity protection (i.e. AES based rather than hash based).

2.      Yes there is probably going to be a desire in the future to have a minimal set of cryptographic primitives in silicon.  I do not currently believe that one can completely get rid of hash functions if one wants to do ECDH key agreement, but for other configurations it would be possible to do AES only.

Jim

From: Brian Campbell [mailto:[email-masked]] 
Sent: Wednesday, July 01, 2015 8:35 AM
To: Mike Jones
Cc: Jim Schaad; [email-masked]
Subject: Re: [Cose] AES based MAC algorithm

What's the motivation for an AES based MAC (vs. say an HMAC)? Is it the hope that a broader set of COSE could be supported by something that only has to support AES? Or something else?  

On Tue, Jun 30, 2015 at 5:20 PM, Mike Jones <[email-masked] <mailto:[email-masked]> > wrote:

Do you have data on how commonly available implementations of these algorithms are to help inform the choice?  As you know, in JOSE we drove the set of algorithm choices off of a survey of which algorithms were implemented on which common development platforms.  (See the attached spreadsheet.)

I realize that in this case, the right sets of development platforms to survey may be different than the largely Web-targeted development platforms that JOSE surveyed.  For COSE, the right tools are more likely to be embedded systems development platforms.

Anyway, if we can make this choice based on data, that would be good.  If the data shows that people will have to largely build AES-MAC or AES-CMAC from scratch because their platforms don't support either of them, then I agree with your preference for AES-CMAC.

                                -- Mike

-----Original Message-----
From: Cose [mailto:[email-masked] <mailto:[email-masked]> ] On Behalf Of Jim Schaad
Sent: Tuesday, June 30, 2015 3:59 PM
To: [email-masked] <mailto:[email-masked]> 
Subject: [Cose] AES based MAC algorithm

In doing the work on getting algorithms into the document I ended up with a "Which one" question.

AES-MAC has historically been the block cipher MAC algorithm used by most people.  In part because it has been around the longest.  It does the traditional AES-CBC mode of encryption and then takes the last block of the output as the MAC value.

AES-CMAC (also known as AES-OMAC1) is a variant of the same algorithm which uses one extra encryption operation and an XOR operation at the end of the process to provide higher security than is available with AES-MAC.  Details of this algorithm can be found in RFC 4493.

Do people have a preference as to which of these two algorithms is specified?  My personal preference leans towards using the newer algorithm as there is not a significant performance penalty and it appears to have better security properties.

Jim

_______________________________________________
Cose mailing list
[email-masked] <mailto:[email-masked]> 
https://www.ietf.org/mailman/listinfo/cose

_______________________________________________
Cose mailing list
[email-masked] <mailto:[email-masked]> 
https://www.ietf.org/mailman/listinfo/cose

---

From: Martin Thomson <[email-masked]>
Date: Wed, 1 Jul 2015 11:38:26 -0700

On 30 June 2015 at 15:58, Jim Schaad <[email-masked]> wrote:
> specified?

Objection: leading the witness.  I thought that neither would be a
good choice.  AEAD encompasses a MAC (neither of these), and the
hashes that we have defined seem sufficient.

This seems wholly speculative.

---

From: Brian Campbell <[email-masked]>
Date: Wed, 1 Jul 2015 12:43:25 -0600

I only represent a single data point but I've never seen anything other
than hash based MACs used in the applications I encounter. So #1 isn't real
convincing to me.

#2 I can see.

On Wed, Jul 1, 2015 at 12:31 PM, Jim Schaad <[email-masked]> wrote:

> 1.       I have been told that this is the more common way to do
> integrity protection (i.e. AES based rather than hash based).
>
> 2.      Yes there is probably going to be a desire in the future to have
> a minimal set of cryptographic primitives in silicon.  I do not currently
> believe that one can completely get rid of hash functions if one wants to
> do ECDH key agreement, but for other configurations it would be possible to
> do AES only.
>
>
>
> Jim
>
>
>
>
>
> *From:* Brian Campbell [mailto:[email-masked]]
> *Sent:* Wednesday, July 01, 2015 8:35 AM
> *To:* Mike Jones
> *Cc:* Jim Schaad; [email-masked]
> *Subject:* Re: [Cose] AES based MAC algorithm
>
>
>

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 01 Jul 2015 20:53:02 +0200

Brian Campbell wrote:
> What's the motivation for an AES based MAC (vs. say an HMAC)? 

Many constrained platforms have hardware support for AES.

At the link layer, CBC-MAC is already in use as part of CCM.
CCM-based ciphersuites are also the standard ones for the use of DTLS
with CoAP.

Grüße, Carsten

---

From: "Jim Schaad" <[email-masked]>
Date: Mon, 6 Jul 2015 20:22:17 -0700

> From: Martin Thomson [mailto:[email-masked]]
> Sent: Wednesday, July 01, 2015 11:38 AM
> To: Jim Schaad
> Cc: cose WG
> Objection: leading the witness.  I thought that neither would be a good
> choice.  AEAD encompasses a MAC (neither of these), and the hashes that
> we have defined seem sufficient.

AES-CCM uses AES-MAC (not CMAC) for the purpose of computing the MAC value portion.

Jim

---

From: Sandeep Kumar <[email-masked]>
Date: Tue, 7 Jul 2015 11:35:30 +0200

I support AES-CMAC as this is the preferred algorithm for MAC on systems we
build. Would really like to see that gap filled in Cose,
AES-CCM uses AES-MAC (aka AES-CBC-MAC) but the construction is secure only
when used within AES-CCM.

regards
Sandeep

Philips Lighting

---

From: Derek Atkins <[email-masked]>
Date: Wed, 08 Jul 2015 11:09:36 -0400

"Jim Schaad" <[email-masked]> writes:

> AES-CMAC (also known as AES-OMAC1) is a variant of the same algorithm which
> uses one extra encryption operation and an XOR operation at the end of the
> process to provide higher security than is available with AES-MAC.  Details
> of this algorithm can be found in RFC 4493.
>

I prefer AES-CMAC.

> Jim

-derek
-- 
       Derek Atkins                 617-623-3745
       [email-masked]             www.ihtfp.com
       Computer and Internet Security Consultant

---

From: Derek Atkins <[email-masked]>
Date: Wed, 08 Jul 2015 12:27:04 -0400

Brian Campbell <[email-masked]> writes:

> I only represent a single data point but I've never seen anything other than
> hash based MACs used in the applications I encounter. So #1 isn't real
> convincing to me.
>
> #2 I can see.

On the (extremely tiny) devices that I'm working with they provide an
AES implementation in hardware, but they don't provide any hashes in
hardware.  This means I can implement an AES-CMAC and have it actually
run relatively efficiently.  Implementing any hash in software would
take excessively long to run (assuming we could get an implementation to
actually fit in the ROM).

(For the record, we also have an ECDH replacement called Algebraic
Eraser Diffie-Hellman, AEDH, which definitely does not require any Hash
functionality).

Also, all AEAD functonality is effectivtely using an AES-based MAC of
some sort, be it CBC-MAC, CMAC, or a GF-based AES mac in GCM.

-derek

>     1.       I have been told that this is the more common way to do integrity
>     protection (i.e. AES based rather than hash based).
>    
>     2.      Yes there is probably going to be a desire in the future to have a
>     minimal set of cryptographic primitives in silicon.  I do not currently
>     do ECDH key agreement, but for other configurations it would be possible
>     to do AES only.
>    
>      
>    
>     Jim
>    
>      
>    
>      
>    
>         algorithms are to help inform the choice?  As you know, in JOSE we
>         drove the set of algorithm choices off of a survey of which algorithms
>         were implemented on which common development platforms.  (See the
>         attached spreadsheet.)
>        
>         I realize that in this case, the right sets of development platforms
>         to survey may be different than the largely Web-targeted development
>         platforms that JOSE surveyed.  For COSE, the right tools are more
>         likely to be embedded systems development platforms.
>        
>         Anyway, if we can make this choice based on data, that would be good. 
>         If the data shows that people will have to largely build AES-MAC or
>         AES-CMAC from scratch because their platforms don't support either of
>         them, then I agree with your preference for AES-CMAC.
>        
>                                         -- Mike
>
>         AES-MAC has historically been the block cipher MAC algorithm used by
>         most people.  In part because it has been around the longest.  It does
>         the traditional AES-CBC mode of encryption and then takes the last
>         block of the output as the MAC value.
>        
>         which uses one extra encryption operation and an XOR operation at the
>         end of the process to provide higher security than is available with
>         AES-MAC.  Details of this algorithm can be found in RFC 4493.
>        
>         specified?  My personal preference leans towards using the newer
>         algorithm as there is not a significant performance penalty and it
>         appears to have better security properties.
>        
>         Jim
>

---

From: Derek Atkins <[email-masked]>
Date: Wed, 08 Jul 2015 12:36:10 -0400

> when used within AES-CCM.

Off topic for COSE, but I was considering writing up a draft that
specifies an AES-CCM+ that is really how to use AES-CTR + AES-CMAC in a
construction similar to AES-CCM (i.e., AES-CCM but replace CBC-MAC with
CMAC).  Would you support me in that effort?  :)

-derek

---

From: Samuel Erdtman <[email-masked]>
Date: Wed, 8 Jul 2015 23:47:09 +0200

Hi,

I do not really have any strong preference regarding AES-MAC or AES-CMAC
just a comment with regards to HMAC and constrained devices. During spring
I got my hands on a TWN3 RFID reader, it has a C like scripting language
that only supports bytes and byte-arrays and I wanted to do HOTP (HMAC) on
it, so I ported the reference implementation to C with these constraints
(only bytes) and then I where in the process of porting it to the scripting
language and got halfway before the memory was full. My code was not highly
optimised but I don´t think I would be able to shrink it to half the size,
i.e. if there is no hardware support it can he hard to fit sha1.

Best Regards
//Samuel Erdtman

On Wed, Jul 8, 2015 at 6:36 PM, Derek Atkins <[email-masked]> wrote:

> good
> >     AES-CCM uses AES-MAC (not CMAC) for the purpose of computing the MAC
> value
> >     portion.
> >
> >     Jim
> >
> >     >