• Registered: 2021-03-12
  • Posts: 5

Topic: Crypto callback device context

Hello

I'm looking at using crypto callback and have questions about the use of the devCtx member placed in the structures (wc_Sha etc) where WOLF_CRYPTO_CB is used. This is not about the ctx member included in the CryptoCb structure.

Where the method consists of initialisation(), update(), finalise() such as sha, hmac I would like to use this member to point to a myContext loaded when crypto callback is first used with this structure and then freed when the structure use is completed. I assume this is one reason why the member is there? This does rely on the finalise() always being called which I believe is the case with hash and hmac.

The devCtx is initialised to NULL in wc_InitSha256_ex()  but not in wc_InitSha_ex(), I assume this is an omission and devCtx meant to be initialised to NULL. Also it would be useful for all crypto callback using structures that can be used more than once to have a devCtx member which is initialised to NULL, this is done for AES but not for RSA which doesn't have devCtx - not sure if RSA is ever called more than once for the same key structure, if not then clearly not needed.

I'm not sure what the wc_Sha256Copy() function called from wc_Sha256GetHash() does. My concern is that it may create a duplicate copy that exists at the same time as the first and I will end up with 2 sructues pointing to the same myContext, this would only be a problem if the original was in the middle of an active hash which probably isn't ever the case but I just want to be sure.

Can you add the devCtx=NULL initialise to wc_InitSha_Ex() and anywhere else it is not done for the next issue?

Share

  • Registered: 2015-10-07
  • Posts: 434

Re: Crypto callback device context

Hi Robert,

Thanks for the excellent feedback. I did the crypto callback implementation and the devCtx was added a bit later and possibly not consistent across all algorithms (as you have seen). I will work on a fix for and post a link. Also there is some work in progress to fix the HMAC devId's.

In the future feel free to send us a direct email to support@wolfssl.com, which goes into our ZenDesk system.

Thanks,
David Garske, wolfSSL

Share

  • Registered: 2021-03-12
  • Posts: 5

Re: Crypto callback device context

thanks dgarske

Share

  • Registered: 2015-10-07
  • Posts: 434

Re: Crypto callback device context

Hi Robert,

I've pushed fixes for this issue to a PR here:
https://github.com/wolfSSL/wolfssl/pull/3874

The `devCtx` is meant for symmetric algorithms. Do you have a need for it with asymmetric ones like ECC or RSA?

Thanks,
David Garske, wolfSSL

Share

  • Registered: 2021-03-12
  • Posts: 5

Re: Crypto callback device context

I don't think so as by their nature they are not regularly called like the symmetric algorithms, I haven't looked at the asymmetrics yet but it's hard to see how the devCtx can help much if at all.

I'm using this with Renesas TSIP for which I have to generate a "key-index" to use with the hardware crypto (the key-index is roughly an ECBC-MAC of the clear key) as the crypto does not work with clear keys. Having the devCtx gives me a shortcut to the key-index associated with the clear key which makes using the symmetric keys quicker.

The devCtx is most useful for the hash and hmac functions as it lets me easily save the individual messages from the update() functions to be calculated on the final() functions - the TSIP works with an init/update/final sequence and doesn't allow for one operation sequence to interrupt another. (There are ways around not being able to break the sequence, trivial for CBC harder for others but best to avoid if possible).

Share

  • Registered: 2015-10-07
  • Posts: 434

Re: Crypto callback device context

Hi Robert,

Thank you for that feedback. I agree with you that the devCtx only makes sense for symmetric algorithms.

Also thank you for the details about your platform (Renesas TSIP). Let me know if you have any other issues or questions.

Thanks,
David Garske, wolfSSL

Share

  • Registered: 2021-03-12
  • Posts: 5

Re: Crypto callback device context

Hello David

One further question. CCM is not currently supported by crypto callback, are there plans to add this?

Share

  • Registered: 2015-10-07
  • Posts: 434

Re: Crypto callback device context

Hi Robert,

There are not current plans to add CCM to the crypto callbacks, but the effort is fairly easy. I've put this on our feature request list.

If this is a blocker for your evaluation please reach out to Rylie and we can escalate it.

Thanks,
David Garske, wolfSSL

Share

  • Registered: 2021-03-12
  • Posts: 5

Re: Crypto callback device context

No, it won't affect the evaluation.

It will be the best part of a year before I'm likely to need CCM specifically and even if I did need it before you add the callback I can do a temporary add myself until you release the proper version - I can't see it differing very much from the GCM implementation so easy to make it so I wouldn't have to change much if anything for your version.

Share

  • Registered: 2015-10-07
  • Posts: 434

Re: Crypto callback device context

Hi Robert,

I agree, if you model it off AES GCM it should be easy. Feel free to put up a PR with your contribution and I can review/comment. To merge we would need a signed contributor agreement or once you have a license agreement.

Thanks,
David Garske, wolfSSL

Share