IPPCP Compressing ECDSA public key

[Kappa322]

Hi! I'm currently in the process of porting from another ecc library to ippcp and am having trouble with the size of the public keys. I'm using secp256r1. I know that the 6096 byte PointState for the public key can be reduced to 32+32 bytes with ECCPGetPoint, however standard practice is usually to compress this further into 33 bytes by only including the x coordinate and the sign of the y coordinate. Are there standardized ippcp functions for public key compression and decompression that I'm just missing or will I have to write these myself in c++ (with probably worse performance)? Cheers for any help!

[Sergey_K_Intel4]

Hi,

There is no is special function(s) transforming EC point to/from compressed representation in IPP.

Compressed representation is important for transmission purpose. IPP, in contrast, focused on processing.

Seems there is no problem in affine -> compresed representation.

t's possible to use ippsGFpSqrt() for inverse (compressed -> affine representtaion.) transformation.

I'm a confused and can't understand where did you get 6096 byte for PointState. Thus I see the following in IPP's headers:

typedef struct _cpGFpECPoint {
   IppCtxId     idCtx;  /* EC Point identifier     */
   int          flags;  /* flags: affine           */
   int    elementSize;  /* size of each coordinate */
   BNU_CHUNK_T* pData;  /* coordinatex X, Y, Z     */
} cpGFPECPoint;

So, size of point should be 32+32+32+4+4+4 = 108 bytes in case of 256-bit modulus

[Kappa322]

You're right about size, was using the wrong getSize function, correct context size is 120 using ippsECCPPointGetSize (probably alignment and 4byte vs 8byte ptr which is why it's not 108) I ended up going with ippsGFpECMakePoint to uncompress the key. This can't handle half of the keys since you can't choose if you want the positive or negative one, but in our use-case throwing away half of the keys isn't that big of an issue since we were already considering doing it to make compressed public keys 32 instead of 33 bytes. Would've probably gone with ippsGFpSqrt if I knew about it (sadly it isn't in the documentation :( ). I may sound negative but don't get me wrong, loving ippcp so far and I understand that this isn't precisely the normal use-case you're tailored towards. Can't complain too much using a free library :)