[gnutls-help] GnuTLS cryptographic API questions

[Nikos Mavrogiannopoulos]

On Mon, Apr 3, 2017 at 4:01 PM, Ted Zlatanov <tzz at lifelogs.com> wrote:
> On Fri, 31 Mar 2017 20:58:26 +0200 Nikos Mavrogiannopoulos <nmav at gnutls.org> wrote:
>
> NM> On Thu, Mar 30, 2017 at 3:27 PM, Ted Zlatanov <tzz at lifelogs.com> wrote:
>>> So that's perfect. I had a feeling I was missing something :) Do you
>>> think those functions could also be listed under the Cryptographic API
>>> sections I cited?
>
> NM> It's a historical reason they are in the Core API (crypto API didn't
> NM> exist at the time). Now moving them to crypto.h would break existing
> NM> software. I've added some text that several functions may not be
> NM> listed in crypto API. If you have a better suggestion I'd appreciate a
> NM> merge request.
>
> Understood, and thanks. I'll do that.
>
> NM> There are separate gnutls_mac_list() and gnutls_digest_list() which
> NM> can be used to obtain the different sets.
>>>
>>> Does it make sense to correlate MACs and digests, since digests are
>>> currently a subset of MACs? You do that with AEAD ciphers (a subcase of
>>> general ciphers).
>
> NM> This correlation is only for HMACs. MACs like poly1305 and UMAC have
> NM> no equivalent digest.
>
> Right, so let me ask another way--can we say "these MACs are HMACs?"
> through the API?

The wording is not correct as HMAC means a hash-based mac. However, as
far as the API is concerned, it can be exactly the same (and that's
how the gnutls api treats them, even though the naming is
unfortunate).

> It's unnecessary from the Emacs side to have a separate
> list of digest algorithms if they are simply a subset of the MAC
> algorithms.

In the past MAC algorithms were mostly hash based but today this trend
is changing. My bet would be that HMAC will be used less and less as
it results to slow algorithms, so MAC being a subset of Digests will
no longer hold.

> The way I'm currently doing it is to get the MAC name and then try to
> get a digest ID with the same name. If it works, I associate that digest
> ID with the MAC, resulting in something like this plist:
>
> "SHA224" (:mac-algorithm-id 9 :type gnutls-mac-algorithm :mac-algorithm-keysize 28 :mac-algorithm-noncesize 0 :digest-algorithm-id 9)
>
> Another usage question: I can eliminate the numeric IDs and always get
> them from the name when the functions are called. The risk of keeping
> them in the plist is minimal, since the numbers won't change, but they
> are exposing low-level implementation details to users. What would you
> suggest? Is the overhead of getting the numeric ID from the name
> negligible?

Do you mean relying on gnutls_mac_get_id()? I guess it makes sense.
You can rely on names as printed by " gnutls-cli -l".

regards,
Nikos