I'm trying to use the IPP-ECC functionality (for the first time), and I have a 'weird' issue.
Doing a very simple example in C on Linux, heavily inspired by https://software.intel.com/en-us/node/503782:
static IppsECCPState* newStd_256_ECP(void)
IppsECCPState *pCtx = NULL;
if (ippStsNoErr != ippsECCPGetSize(256, &ctxSize))
pCtx = malloc(ctxSize);
if (NULL == pCtx)
if (ippStsNoErr != ippsECCPInit(256, pCtx))
if (ippStsNoErr != ippsECCPSetStd(IppECCPStd256r1, pCtx))
If I comment in the outcommented section (with the call to the ippsECCPSetStd(), but not even calling the overall newStd_256_ECP function at all), it seems as my program hangs, and after some time times out.
Is this something that has been observed before somehow, and do we have 'a solution' for this ?
Can you provide some more information for your problem?
1> IPP version used in your application? 32 bit code or 64 bit code?, how is IPP linked in the application, used in kernel mode, or user mode, etc.
2> Do you have a standalone code that can help to reproduce this issue?
3> You mentioned " not even calling the overall newStd_256_ECP function at all), it seems as my program hangs"
Does it mean even the code do not call Intel IPP function, it just links with IPP? the program will hang?
I can only recall one old issue that only linking with IPP may impact the code:
Will this impact your code?
I think I found the culprit.
On https://software.intel.com/en-us/node/502779, it is stated that AESInit() will return an error if the keylen is different from 16, 24 or 32.
Unfortunately, I had a selftest that actually tested this (that AES only supports 16, 24 or 32) on our old security-code, where I try to put in a key length of size 40.
This apparently results in an overwrite of internal structures or something somewhere, so that at a certain point later in time, IPP crashes big time (for example when I then call ippsECCPSetStd()).
Could I recommend a boundery check on incoming parameters in IPP, so that the ippsAesInit() function does NOT try to use data sizes, for which it has not allocated enough memory.
Putting the 'boundery check' in my own code before calling IPP-AES, saves the day for me (so far at least :-)