Cleaning up usage of CMAC_xxx

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Cleaning up usage of CMAC_xxx

Hal Murray

CMAC_* have been DEPRECATED for 3.0.0

CHANGES.md suggests using EVP_MAC_xxx.  Mostly, that seems reasonable, but
there is one loose end.

CMAC_Init includes a key and cipher.  What's the equivalent in EVP_MAC_xxx?

-----------

I found the params stuff, but that's new in 3.0.0
How do I do it in 1.1.1 or earlier?



--
These are my opinions.  I hate spam.



Reply | Threaded
Open this post in threaded view
|

Re: Cleaning up usage of CMAC_xxx

Richard Levitte - VMS Whacker-2
On Thu, 11 Jun 2020 02:49:04 +0200,
Hal Murray wrote:

> CMAC_* have been DEPRECATED for 3.0.0
>
> CHANGES.md suggests using EVP_MAC_xxx.  Mostly, that seems reasonable, but
> there is one loose end.
>
> CMAC_Init includes a key and cipher.  What's the equivalent in EVP_MAC_xxx?
>
> -----------
>
> I found the params stuff, but that's new in 3.0.0
> How do I do it in 1.1.1 or earlier?

In 1.1.1 and earlier, there is a different idea, using EVP_PKEY
routines to "sign" with a MAC.  We have a EVP_PKEY to EVP_MAC bridge
in 3.0.0 to bridge the gap.

Cheers,
Richard

--
Richard Levitte         [hidden email]
OpenSSL Project         http://www.openssl.org/~levitte/
Reply | Threaded
Open this post in threaded view
|

Re: Cleaning up usage of CMAC_xxx

Hal Murray
In reply to this post by Hal Murray

[hidden email] said:
> In 1.1.1 and earlier, there is a different idea, using EVP_PKEY routines to
> "sign" with a MAC.  We have a EVP_PKEY to EVP_MAC bridge in 3.0.0 to bridge
> the gap.

Thanks, but...

The EVP_PKEY seems to assume a public/private key environment.  The man page
for EVP_PKEY_new() says:
       The structure returned by EVP_PKEY_new() is empty. To add a private or
       public key to this empty structure use the appropriate functions
       described in EVP_PKEY_set1_RSA(3), EVP_PKEY_set1_DSA, EVP_PKEY_set1_DH
       or EVP_PKEY_set1_EC_KEY.

We don't have public/private keys.  Perhaps it will help if I describe our
environment.

The context is NTP.  NTP is a classic client/server, request/response
protocol.  It uses UDP which is easily forged.  Basic packets are 48 bytes.

Shared-key authentication is optional.  Out of band, the client and server
agree on a key, algorithm, and key ID.  The ID is an index into a (hash?)
table of algorithm and key.  Authenticated packets have the ID and MAC
appended to the packet.  The length of the MAC depends on the algorithm.

Key info comes from the keyboard or a text file with 1 line per key.  NIST
uses USPS to distribute keys.

Busy servers process 10K-100K packets per second.  On the server, each packet
requires 2 passes through the MAC algorithm, one to verify the MAC when
receiving a request and another to compute the MAC when sending the response.  
The NTP protocol is simple.  The MAC calculations are a significant fraction
of the per packet CPU load.  I'd like a fast/clean API to the low level MAC
routines.  The CMAC API was good.

---------

I'm willing to do a reasonable amount of setup work during initialization, for
example turning "AES" from a file to a EVP_CIPHER* to feed to CMAC_Init()  
Clean is more important than fast.

I'm willing to have totally separate implementations for 3.0.0 and 1.x.x if
that's the cleanest way to go.

I'm slightly concerned that the params API will be slow.  It's moving string
lookups into the mainline.  I don't have any numbers yet.

---------

We also have a similar HMAC like digest mode using MD5 and SHA1 via
EVP_Digest.  Will that API be around long term?


--
These are my opinions.  I hate spam.



Reply | Threaded
Open this post in threaded view
|

Re: Cleaning up usage of CMAC_xxx

Matt Caswell-2


On 12/06/2020 00:27, Hal Murray wrote:

>
> [hidden email] said:
>> In 1.1.1 and earlier, there is a different idea, using EVP_PKEY routines to
>> "sign" with a MAC.  We have a EVP_PKEY to EVP_MAC bridge in 3.0.0 to bridge
>> the gap.
>
> Thanks, but...
>
> The EVP_PKEY seems to assume a public/private key environment.  The man page
> for EVP_PKEY_new() says:

Nonetheless, what Richard says is correct. You can still do MAC
operations using EVP_PKEY. Its a horrible hack, and that's why we
introduced the EVP_MAC interface instead.

There's is some content on the Wiki about how to do HMAC using the "old"
EVP_PKEY approach. The same thing should also apply to CMAC:

https://wiki.openssl.org/index.php/EVP_Signing_and_Verifying#HMAC

You can create an EVP_PKEY with an HMAC key using the function
EVP_PKEY_new_raw_private_key() and a CMAC key using the function
EVP_PKEY_new_CMAC_key():

https://www.openssl.org/docs/man1.1.1/man3/EVP_PKEY_new_CMAC_key.html

However, EVP_MAC is the way of the future and should be the preferred
approach for anything running in 3.0 or above.

> I'm willing to have totally separate implementations for 3.0.0 and 1.x.x if
> that's the cleanest way to go.

If you can afford the additional complexity, then I think it is worth it
- but its not strictly necessary (the old EVP_PKEY method does still
work in 3.0).

> I'm slightly concerned that the params API will be slow.  It's moving string
> lookups into the mainline.  I don't have any numbers yet.

We don't expect it to be significantly worse - but we'd be very
interested in any numbers that you are able to produce.

> We also have a similar HMAC like digest mode using MD5 and SHA1 via
> EVP_Digest.  Will that API be around long term?

We expect EVP_Digest* to be around for the long term.

Matt
Reply | Threaded
Open this post in threaded view
|

Re: Cleaning up usage of CMAC_xxx

Hal Murray
In reply to this post by Hal Murray
Thanks.

> and a CMAC key using the function EVP_PKEY_new_CMAC_key():

That's the step I was missing.  Right in front of my eyes.

I'm still missing something though.

Does this look reasonable:
    cipher = EVP_aes_128_cbc();
    pkey = EVP_PKEY_new_CMAC_key(NULL, key, keylength, cipher);
    ctx = EVP_PKEY_CTX_new(pkey, NULL);
    EVP_PKEY_sign_init(ctx);
The last step dies with:
  error:0608D096:digital envelope routines:EVP_PKEY_sign_init:operation not
supported for this keytype.

[It will probably be obvious after somebody points me in the right direction.]

That cipher work with CMAC.


--
These are my opinions.  I hate spam.