(9 replies, posted in wolfCrypt)

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.


(9 replies, posted in wolfCrypt)

Hello David

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


(9 replies, posted in wolfCrypt)

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).


(9 replies, posted in wolfCrypt)

thanks dgarske


(9 replies, posted in wolfCrypt)


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?