From: Gix, Brian <brian.gix@intel.com>
To: ell@lists.01.org
Subject: Re: [PATCH] cipher: add AES-CMAC hashing support
Date: Wed, 29 May 2019 15:29:42 +0000 [thread overview]
Message-ID: <1559143780.3694.10.camel@intel.com> (raw)
In-Reply-To: <20190529105234.d5hn6i2gbx4boswj@scytale>
[-- Attachment #1: Type: text/plain, Size: 3787 bytes --]
Hi Michał,
On Wed, 2019-05-29 at 12:52 +0200, Michał Lowas-Rzechonek wrote:
> Hi Brian,
>
> On 05/29, Gix, Brian wrote:
> > > > > The algorythm is supported in the kernel, and it is used heavily by
> > > > > Bluetooth Mesh, and is the one Mesh required algorythm missing from ELL.
>
> Is this about mesh_crypto_aes_ccm_encrypt and
> mesh_crypto_aes_ccm_decrypt functions in mesh/crypto.c?
The code you copy pasted below *is* the usage of AES_CCM that we use in mesh, but it is *not* the topic of the
patch I posted here to ELL yesterday. AES-CMAC is the algorythm we use in Mesh to generate all of the various
Keys and IDs from master Net and App keys.... It is a simple one-directional hashing function, and as I also
learned yesterday, is already supported in ELLs checksum.c code.
>
> If so, they can be implemented with l_aead_cipher_* API, without any
> changes to ELL, see below.
>
> There is a slight problem, though - this works only on newer kernels
> (IIRC, 4.9+), and some vendors (particularly Freescale i.MX6) do not
> provide them :(
This is definitely a question worth answering. We are aware that pre-4.9 kernels did not correctly support
AES_CCM, so switching the mesh daemon's crypto to pure ELL supported kernel based encryption and decryption
will mean that the daemon is not supported on very old kernels.
As far as Freescale platforms go, I do not know how to answer that question. At some point we do need to move
on from older platforms so that the rest are not "held back". But I do not know if that time is yet now.
I would really like to get Marcel's opinion on this.
>
> What's worse, my experiments show what the kernel does *not* report an
> error while bind()ing the algo socket, but the results are wrong :(
>
>
>
> bool mesh_crypto_aes_ccm_encrypt(const uint8_t nonce[NONCE_LEN],
> const uint8_t key[KEY_LEN],
> const uint8_t *aad, uint16_t aad_len,
> const uint8_t *msg, uint16_t msg_len,
> uint8_t *out_msg,
> void *out_mic, size_t mic_size)
> {
> bool result;
> struct l_aead_cipher *cipher = l_aead_cipher_new(L_AEAD_CIPHER_AES_CCM,
> &key[0], KEY_LEN, mic_size);
>
> if (!cipher)
> return false;
>
> if (!out_msg)
> return false;
>
> result = l_aead_cipher_encrypt(cipher, (void *)msg, msg_len,
> aad, aad_len, &nonce[0], NONCE_LEN,
> (void *)out_msg, msg_len + mic_size);
>
> if (out_mic) {
> switch (mic_size) {
> case 4:
> *(uint32_t *)out_mic = l_get_be32(out_msg + msg_len);
> break;
> case 8:
> *(uint64_t *)out_mic = l_get_be64(out_msg + msg_len);
> break;
> default:
> /* Unsupported MIC size */
> return false;
> }
> }
>
> l_aead_cipher_free(cipher);
> return result;
> }
>
> bool mesh_crypto_aes_ccm_decrypt(const uint8_t nonce[13], const uint8_t key[16],
> const uint8_t *aad, uint16_t aad_len,
> const uint8_t *enc_msg, uint16_t enc_msg_len,
> uint8_t *out_msg,
> void *out_mic, size_t mic_size)
> {
> bool result;
> struct l_aead_cipher *cipher = l_aead_cipher_new(L_AEAD_CIPHER_AES_CCM,
> &key[0], KEY_LEN, mic_size);
>
> if (!cipher)
> return false;
>
> result = l_aead_cipher_decrypt(cipher, (void *)enc_msg, enc_msg_len,
> aad, aad_len, &nonce[0], NONCE_LEN,
> (void *)out_msg, enc_msg_len - mic_size);
>
> if (out_mic) {
> switch (mic_size) {
> case 4:
> *(uint32_t *)out_mic = l_get_be32(out_msg +
> enc_msg_len - mic_size);
> break;
> case 8:
> *(uint64_t *)out_mic = l_get_be64(out_msg +
> enc_msg_len - mic_size);
> break;
> default:
> /* Unsupported MIC size */
> return false;
> }
> }
>
> l_aead_cipher_free(cipher);
> return result;
> }
>
next prev parent reply other threads:[~2019-05-29 15:29 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-05-29 0:49 [PATCH] cipher: add AES-CMAC hashing support Brian Gix
2019-05-29 1:32 ` Denis Kenzior
2019-05-29 3:04 ` Gix, Brian
2019-05-29 3:25 ` Gix, Brian
2019-05-29 10:52 ` =?unknown-8bit?q?Micha=C5=82?= Lowas-Rzechonek
2019-05-29 15:29 ` Gix, Brian [this message]
2019-05-29 19:26 ` michal.lowas-rzechonek
2019-05-29 20:07 ` Gix, Brian
2019-05-29 16:14 ` Denis Kenzior
2019-05-31 17:28 ` ELL building broken for 32bit systems Gix, Brian
2019-05-31 17:41 ` Gix, Brian
2019-05-31 19:53 ` Denis Kenzior
2019-05-31 20:28 ` Gix, Brian
2019-05-31 20:44 ` Denis Kenzior
2019-05-31 23:12 ` Gix, Brian
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1559143780.3694.10.camel@intel.com \
--to=brian.gix@intel.com \
--cc=ell@lists.01.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.