Re: Please reconsider re-adding AES-CMAC

On Thu, Jan 28, 2016 at 12:26 AM, Mitar <mmitar@gmail.com> wrote:

> Hi!
>
> To my understanding reading from minutes the only reason to remove
> AES-CMAC from the standard is because it was not implemented in
> browsers? But isn't this chicken and egg problem?


No, it is not. No browser indicated interest, nor did their underlying
cryptographic implementations.


> Concretely, new Intel SGX CPU instructions have support for AES-CMAC
> and uses the algorithm described above to generate shared key based on
> ECDH. Those instructions are available in the SGX SDK, backed by
> native CPU instructions. By using only those functions one does not
> have to additionally increase the trusted codebase with a 3rd party
> crypto library.
>

By definition, it does. You're either trusting the SGX SDK's abstraction
over those instruction sets (a 3rd party) or you're trusting the CPU's
implementation (a 3rd party). You can't escape that. In practice, these
instruction sets are only available on such a small number of actual users
machines - and will remain so for quite a long time - that it will
absolutely be necessary to ship a software or alternative implementation.
Similar to supporting a non-Intel platform (such as the A7 or the many ARM
SOCs).

This is just to disprove that final claim - in order to support CMAC, it
will take non-trivial work to support, and so you still need to convince
browsers it is worthwhile to support, such that there's interest in specing
*and* implementing. It's unlikely to be added to the spec w/o browser
vendor interest.