Cryptography: Signature generation with ECCP

[kdiamond]

Sorry for asking, but I need some clarification on IPP behavior during digital signature(DS) generation with ippsECCPSignDSA(). I'd greately appreciate any response on that matter 'coz it's really important to me.

The situation is following.

I'm using IPP to sign some data using ECDSA with SHA224. So, actual DS is being calculated over SHA224 hash of variable input data (that is a message digest).

1) ippsSHA224MessageDigest() is used to calculate hash value and that is Ok. No issues here.

2) Private key comes from PKCS#8 formatted file with the contents (Data Tag #n -data dump thatfollowed by parsed individual data fileds):

Data Tag #0 (version)
00

Data Tag #1 (privateKeyAlgorithm)
06 07 2A 86 48 CE 3D 02 01 30 81 C5 02 01 01 30
28 06 07 2A 86 48 CE 3D 01 01 02 1D 00 D7 C1 34
AA 26 43 66 86 2A 18 30 25 75 D1 D7 87 B0 9F 07
57 97 DA 89 F5 7E C8 C0 FF 30 3C 04 1C 68 A5 E6
2C A9 CE 6C 1C 29 98 03 A6 C1 53 0B 51 4E 18 2A
D8 B0 04 2A 59 CA D2 9F 43 04 1C 25 80 F6 3C CF
E4 41 38 87 07 13 B1 A9 23 69 E3 3E 21 35 D2 66
DB B3 72 38 6C 40 0B 04 39 04 0D 90 29 AD 2C 7E
5C F4 34 08 23 B2 A8 7D C6 8C 9E 4C E3 17 4C 1E
6E FD EE 12 C0 7D 58 AA 56 F7 72 C0 72 6F 24 C6
B8 9E 4E CD AC 24 35 4B 9E 99 CA A3 F6 D3 76 14
02 CD 02 1D 00 D7 C1 34 AA 26 43 66 86 2A 18 30
25 75 D0 FB 98 D1 16 BC 4B 6D DE BC A3 A5 A7 93
9F
Private Key Algorithm : ECDH-ECDSA Public/Private Key (1.2.840.10045.2.1)
Version : 1
Field ID : 1.2.840.10045.1.1
Prime-P :
00 D7 C1 34 AA 26 43 66 86 2A 18 30 25 75 D1 D7
87 B0 9F 07 57 97 DA 89 F5 7E C8 C0 FF
curve A :
68 A5 E6 2C A9 CE 6C 1C 29 98 03 A6 C1 53 0B 51
4E 18 2A D8 B0 04 2A 59 CA D2 9F 43
curve B :
25 80 F6 3C CF E4 41 38 87 07 13 B1 A9 23 69 E3
3E 21 35 D2 66 DB B3 72 38 6C 40 0B
Base :
04 0D 90 29 AD 2C 7E 5C F4 34 08 23 B2 A8 7D C6
8C 9E 4C E3 17 4C 1E 6E FD EE 12 C0 7D 58 AA 56
&n bsp; F7 72 C0 72 6F 24 C6 B8 9E 4E CD AC 24 35 4B 9E
99 CA A3 F6 D3 76 14 02 CD
Order :
00 D7 C1 34 AA 26 43 66 86 2A 18 30 25 75 D0 FB
98 D1 16 BC 4B 6D DE BC A3 A5 A7 93 9F
Cofactor : 00000001

Data Tag #2 (privateKey)
30 21 02 01 01 04 1C 20 38 D9 30 37 2E 80 25 7E
B7 A3 89 F2 12 EB 74 4F C2 13 CB 04 E5 F2 CE 74
37 34 BE
Version : 1
Key :
20 38 D9 30 37 2E 80 25 7E B7 A3 89 F2 12 EB 74
4F C2 13 CB 04 E5 F2 CE 74 37 34 BE

Public key comes from the corresponding certificate and has a value (dump with leading OCTET STRING tag):

Public point Y
04 37 98 0C 00 84 16 D4 E8 81 31 DC C6 DF DD 9E
5C 72 77 FA 5F 67 63 F7 ED 72 68 9D F2 34 9A B4
0D A1 51 1C 9D 20 8C BF C3 1A 58 41 E2 72 2A 75
40 3A BA A1 46 18 CA 56 E1

I'm setting EC scheme domain parameters by

ippsECCPSet(Prime, A, B, GX, GY, Order, cofactor, (IppsECCPState *)pECC);

Then Public Key is being set by

ippsECCPSetPoint(PublicKeyX, PublicKeyY, (IppsECCPPointState *)pKeyPoint, (IppsECCPState *)pECC);
ippsECCPSetKeyPair(0, (IppsECCPPointState *)pKeyPoint, ippTrue, (IppsECCPState *)pECC);

Next step - generation and setting of ephemeral keys:

ippsECCPGenKeyPair(EphemeralPrivateKey, (IppsECCPPointState *)pEphemeralPublicKey, (IppsECCPState *)pECC, ippsPRNGen, pRND);
ippsECCPSetKeyPair(EphemeralPrivateKey, (IppsECCPPointState *)pEphemeralPublicKey, ippFalse, (IppsECCPState *)pECC);

Once again - everything is Ok until that point. No erroneous return codes or something...

3) Next step - DS calculation.

ippsECCPSignDSA(pMsgDigest, PrivateKey, NewSignX, NewSignY, (IppsECCPState *)pECC);

And THIS is a questionable one... From time to time I get ippStsMessageErr return code with a pretty clear description:

Indicates an error condition if the value of

msg pointed

by

pMsgDigest falls outside the range of [1, 1-n]

where

n is the order of the elliptic curve base point G.

So, to be more simple, as soon as Big Number in pMsgDigest becomes larger or equal to Order value (given a little bit earlier, in PrivateKey description)ippsECCPSignDSA() fails.

*** Note. I think that a correct text in the documentation should looks like "pMsgDigest falls outside the range of [1, n-1]"

Could you please give me a reason of such range check? I really don't understand that and can't find any trace of that in any EC signature related documents/standarts. May be I'm too stupid or blind, but please, guide me to a proper source of information...

How could SIGNING data prevent DS algorithm to do its job? That is really beyond me understanding....

Could it be just a bad selection of EC scheme parameters?

[Vladimir_Dudnik]

Hello,

there is comment from our expert:

Right, according to IPP implementationthe value (f) to be signed must be in 0<=f

This help us to provide more efficient code. We don't see any difference in result meaning between signing/verifying of 0<=f

Recommendationis touse f = F%r instead of F.

Regards,
Vladimir

[kdiamond]

Quoting - Vladimir Dudnik (Intel)

Hello,

there is comment from our expert:

Right, according to IPP implementationthe value (f) to be signed must be in 0<=f

This help us to provide more efficient code. We don't see any difference in result meaning between signing/verifying of 0<=f

Recommendationis touse f = F%r instead of F.

Regards,
Vladimir

Hi!

I have encountered described problem once again. This time with EC signature verification.
This time that issue became too urgent and important to ignore that.

Due to this fact I'm asking you to help me to use correct IPP crypto functions to overcome it.

I need to verifyEC digital signature. The signed data is constant in one of the cases, and its SHA256 message digest is always falls outside that range check, so ippsECCPVerifyDSA() always fails with

ippStsMessageErr.

You mentioned something like "f = F%r instead of F". I'm sorry, but it's not clear for me what additional operations should be used prior toippsECCPVerifyDSA() to make it work properly. I believe - some big number arithmetic. Could you be so kind to give me a code fragment with a necessary function calls to do that? Any help would be much appreciated.

Thank you in advance.

[achrzesz2]

Hi
To fulfill the requirements mentioned by the expert you can for example:

1) replace the value to be signed by its reduction mod order:
ippsMod_BN(hash,order,reducedhash);
and sign and verify the reduced one
(it works fine for me)

or

2) use >224bit curve (if hash has to be 224bit)

or

3) use <224bit hash (if curve has to be 224bit)

Andrzej Chrzeszczyk

[achrzesz2]

I haven't mentioned one more possibility:

4) use 224bit curve with larger order than yours


Andrzej Chrzeszczyk

[kdiamond]

Quoting - achrzesz2

I haven't mentioned one more possibility:

4) use 224bit curve with larger order than yours


Andrzej Chrzeszczyk

Thank you for an answer.

1st variant is a solution in my case. We have predefined signature scheme with fixed public key and message digest algorithm so we can't change or choose anything.

But taking a hashmodulus solves an issue.

Still I can't understand why that operation couldn't be hidden from the user and performed INSIDE ippsECCPVerifyDSA() if necessary. That step (hash value reduction)is a very confusing one and is noncompliant to any existing technicalspecification. I suggest you (IPP team)to think about that.

[kdiamond]

Quoting - kdiamond

Thank you for an answer.

1st variant is a solution in my case. We have predefined signature scheme with fixed public key and message digest algorithm so we can't change or choose anything.

But taking a hashmodulus solves an issue.

Still I can't understand why that operation couldn't be hidden from the user and performed INSIDE ippsECCPVerifyDSA() if necessary. That step (hash value reduction)is a very confusing one and is noncompliant to any existing technicalspecification. I suggest you (IPP team)to think about that.

Dear Andrzej,

It seems that are not related to Intel, so, of course, I directed my suggestion not to you personally... :)

Thanx once again.

[achrzesz2]

Glad to hear

I think that the issue is the performance.
If the curve has more bits than the hash, then the apriopriate reducing is superfluous

Andrzej Chrzeszczyk