[gnutls-devel] GnuTLS | Add support for AES CMAC mac (!786)

[Development of GNU's TLS library]

> 0. Why are you adding all these algorithms to GnuTLS? (You have added
> CFB8, now comes CMAC and I saw that you were working on XTS.) Do you
> have any application in mind, which would benefit from using GnuTLS,
> rather than using Nettle directly?

CFB8 and CMAC are used by Samba, we're working on making it use GnuTLS
for all algorithms instead of implementing their own.
I think this is partially so we can do FIPS certification on a single
library.
XTS is used by libvirt, which had to copy it from another library
although they normally use only GnuTLS.
So in general I am just bringing in stuff the our downstreams asked us
for, and Nikos opened issues for, a while ago.

> 1. Could you please change just `CMAC_128`/`CMAC_256` to
> `AES_CMAC_128`/`AES_CMAC_256` (and so on for lower case names).
> Nettle code uses cmac128 for generic 128-bit-block CMAC version (e.g.
> for GOST ciphers I'm adding `cmac64_*` interface). However CMAC code
> is not specific to AES (NIST defines TDEA-CMAC-xxx, CMAC computed
> using 3DES as basis).

I can change it to CMAC_AES_128/256 like nettle does, the other way
around would make people think that this is AES + CMAC authentication
of some sort.

> 2. [NIST SP800-
> 38B](https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublicati
> on800-38b.pdf) contained test vectors with tags which are exactly 16
> bytes long. It is replaced now, but [examples for AES-
> CMAC](https://csrc.nist.gov/CSRC/media/Projects/Cryptographic-
> Standards-and-Guidelines/documents/examples/AES_CMAC.pdf) page also
> has 16-byte tags. Could you please re-verify them and just attribute
> them to NIST SP800-38A?

Ok.

> 3. I think it's find to always return 16 bytes. If anybody wants, he
> can handle tag truncation manually.

I guess find -> fine, I agree.

> 4. Which part of GnuTLS MAC interface seems misnamed to you?

it's called HMAC, gnutls_hmac_init when it handles MAC generally,
infact we are adding CMAC and there is already UMAC too. It is not a
big deal, but may be a little confusing to a novice.

-- 
Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/786#note_112431524
You're receiving this email because of your account on gitlab.com.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnutls-devel/attachments/20181027/745d4814/attachment.html>