Re: Please reconsider re-adding AES-CMAC

Hi!

On Thu, Jan 28, 2016 at 8:17 AM, Jim Schaad <ietf@augustcellars.com> wrote:
> This is not a solid cryptographic method to produce generate the shared key.  It would require other things to be done as well.

Please do look at
https://software.intel.com/sites/default/files/managed/d5/e7/Intel-SGX-SDK-Users-Guide-for-Windows-OS.pdf,
notes under "sgx_dh_responder_proc_msg2" section. Just to be sure we
are discussing the same algorithm.

I have implemented it with web crypto, see the algorithm at the end of
the e-mail.

> 1.  ECDH does not generate a uniformly random secret, this combined with the fact that AES-CMAC is not going to be a top notch PRF means that you are going to have bias in the resulting key.

Hm, probably depending on how you use AES-CMAC? To my knowledge it
works pretty well as a hashing algorithm.

But, if we are talking about this, from my reading of web crypto
standard, derived key from ECDH uses shared secret directly? I do not
see any post-processing mentioned? But I will open another topic for
this discussion.

> 2.  You need to deal with the fact that ECDH does not necessarily generate usable outputs for use as a key to AES-CMAC.  P-521 is not an input size for any AES algorithm.

It works well if you use P-256.

> I have been investigating this as part of the COSE work being done in the IETF and have consulted a couple of well=known cryptographic experts to get these opinions.

Do you have any references/citations? Because this would be probably
really great information to pass on to Intel, because they are baking
into their CPUs a well studied MAC algorithm without known issues
which then they use for generating session keys for communicating
between SGX secure enclaves, but which by your accord is not good
practice. I think we should alert them.

In meanwhile, I think it is useful to be compatible with hardware
platforms and instructions available there. As I explained in the
original post, I am proposing to reconsider for the interoperability
sake.

The above mentioned algorithm:

// Algorithm tries to match Intel SGX DH secure session algorithm.
sessionKey = Promise.resolve().then(function () {
  return crypto.subtle.importKey('raw', peerPublicKeyRaw, {
    name: 'ECDH',
    namedCurve: 'P-256'
  }, false, []);
}).then(function (peerPublicKey) {
  return crypto.subtle.deriveBits({
    name: 'ECDH',
    namedCurve: 'P-256',
    public: peerPublicKey
  }, selfKeyPair.privateKey, 256);
}).then(function (bits) {
  return crypto.subtle.importKey('raw', new ArrayBuffer(16), {
    name: 'AES-CMAC',
    length: 128
  }, false, ['sign']).then(function (cmacKey) {
    var data = new Uint8Array(bits.length + 1);
    data.set(bits);
    data[bits.length] = 1;

    return crypto.subtle.sign({
      name: 'AES-CMAC',
      length: 128
    }, cmacKey, data);
  });
}).then(function (sessionKeyData) {
  return crypto.subtle.importKey('raw', sessionKeyData, {
    name: 'AES-GCM'
  }, false, ['encrypt', 'decrypt']);
});


Mitar

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

Received on Thursday, 28 January 2016 19:19:22 UTC