Re: Please reconsider re-adding AES-CMAC

Hi!

On Thu, Jan 28, 2016 at 12:59 AM, Ryan Sleevi <sleevi@google.com> wrote:
> 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).

Yes, but I prefer to trust only one 3rd party (which I already have
to, because I would like to use SGX) then adding more 3rd parties to
the mix. Also trusted codebase stays smaller. I do not have to add
extra code. So in theory, if I am able to audit SGX SDK then I am go
to go, without me having to audit also additional crypto library. The
whole point of using SGX is tying to minimize trusted codebase to the
minimum.

> 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.

You cannot have software implementation of SGX. Or you have it, or you
do not have it. If you do have it, then you have those instructions.
If you do not have it, then you cannot use the software I am
interested in. Or you can, but you do not have security properties of
the platform, so it does not really matter if you have also some extra
code in software, the amount of your trusted codebase already went
through the roof.

> Similar to supporting a non-Intel platform (such as the A7 or the many ARM SOCs).

If those platforms support SGX they will probably implement similar
set of instructions in hardware.

> 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.

I understand that there was not much interest, but this this is also
because use cases were not clear. But having a range of common
algorithms do add new use cases and interoperability.


Mitar

-- 
http://mitar.tnode.com/
https://twitter.com/mitar_m

Received on Thursday, 28 January 2016 09:42:40 UTC