topic Re: Cryptography: Signature generation with ECCP in Intel® Integrated Performance Primitives

Cryptography: Signature generation with ECCP

kdiamond — Thu, 22 May 2008 13:43:19 GMT

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

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?

Re: Cryptography: Signature generation with ECCP

Vladimir_Dudnik — Tue, 27 May 2008 09:25:32 GMT

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

Re: Cryptography: Signature generation with ECCP

kdiamond — Tue, 06 Oct 2009 15:16:11 GMT

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.

Re: Cryptography: Signature generation with ECCP

achrzesz2 — Thu, 08 Oct 2009 07:50:38 GMT

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

Re: Cryptography: Signature generation with ECCP

achrzesz2 — Thu, 08 Oct 2009 08:17:19 GMT

I haven't mentioned one more possibility:

4) use 224bit curve with larger order than yours

Andrzej Chrzeszczyk

Re: Cryptography: Signature generation with ECCP

kdiamond — Thu, 08 Oct 2009 08:50:19 GMT

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.

Re: Cryptography: Signature generation with ECCP

kdiamond — Thu, 08 Oct 2009 08:53:07 GMT

Quoting - kdiamond

Dear Andrzej,

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

Thanx once again.

Re: Cryptography: Signature generation with ECCP

achrzesz2 — Thu, 08 Oct 2009 09:30:04 GMT

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